Who cares if you can architect Twitter. Any college graduate can make a half hearted attempt at architecting some bullshit. What needs to be tested is how well do you know your domain. If you claim to have ten years of experience as a web developer, how much did you actually learn in those ten years?

You can't be serious that you couldn't explain what UTF-8 is, or why text direction might matter, or why we put social media links in our headers if you claim to be a senior frontend web developer.

cough No true Scotsman cough

I'm loving the way you are putting words in my mouth about what I do/don't know from those headers. I can explain most all of them but that doesn't stop it from being a stupid exercise. If you start a potential working relationship with me by asking me to explain 10 lines of HTML head tags then that tells me you focus on all the wrong things. By the way, I am a senior frontend web developer and I've been quite successful at it, thank you very much.

I would think that if you would walk out of an interview if the interviewer asked you basic questions then those questions have done their job.

It’s not a quiz, if done right. But you can get to know a lot about someone even by how they respond to not knowing the answer.

Someone with experience knows it’s not a big deal to not know every bit of trivia, but they can talk intelligently about what the code might do. And they know how to find out.

For example, they may point out they know about charset=utf8 in the Content-Type header and admit they thought the meta tag was redundant, and you can have a conversation from there. Or how about "I know 'ltr' means left to right but I never thought about using it with lang=en, but now I want to see what 'rtl' does with English". I suppose it's not the best starter question, but I don't think it needs to be to suss out good candidates from bad ones.

Rage-quitting the interview or blurting out confidently wrong guesses, on the other hand, are bad signals.

I want to hire you, not someone who's never really thought about what's going on. These questions are just a trick to force someone to step out of the box and go deep into some fundamental web concepts. It's not about memorizing some HTML tags, it's about knowing why they exist.

edit: This is just in the hypothetical scenario I'd be hiring a senior frontend web developer. You generally only need maybe 30% of those, the rest I can get trained on developing features within 3 months after finishing a 10 week bootcamp. I wouldn't bother asking them how UTF-8 works, I just explained what the word "encoding" means to a junior who'se been outpacing me for the past 3 months. The person who reviews their merge request should definitely know what UTF-8 is.

The ground is beneath you too but you would fall to your roasty death in the center of the planet if it wasn't there, and if you have a gaping hole in your knowledge base then identifying and resolving it before some portion of the companies' success is resting on your too-narrow shoulders is a good idea.

If someone said that to me in an interview my next question would be "Why did you apply for a senior frontend dev role then?"

Nobody cares about text-size-adjust and other such nonsense.

Senuor frontend devs do care about that, because it affects the display quality, accessibility, and readability of a web app on a mobile device. If you get text size wrong on a site like Amazon or Twitter you could push tens of thousands of people to stop engaging with the site. Imagine if the "Buy Now" text on a button overflowed because the font was too big so it read "Buy no" instead. That would have an impact on revenue.

Don't take this type of exercise personally; it's not aimed at you - it's aimed at the many people who call themselves "full-stack engineers", but haven't ventured beyond the bounds of a particular framework.

That's a great point. Lots of people think that full-stack means knowing how to use npm to install tailwind and express. They just don't know what they don't know.

A "full-stack engineer" should be very familiar with standards like TCP/IP, HTTP headers, the OSI model, CSS things like flexbox, DOM, CORS, SQL, websockets/eventsource, unicode etc etc as well as probably multiple web frameworks in multiple languages, various backend and cloud platforms (at least enough to get around in) like AWS and GCP, and understand what proxies and TLS are and what they do, and probably also how to do things like Let's Encrypt and write secure code with XSS, CSRF, etc hardening.

Obviously, everything is a gradient, and nobody is perfect with everything (as well as the JS build tool of the week) but this stuff takes years and perhaps decades to really grok. There's nothing wrong with being a "junior dev", or just a "dev", or whatever -- it takes a lot of effort to master your craft, especially when you're crossing multiple domains from front-end to back-end to security to architecture. But it is important to know where you best fit in, at least at whatever your current career stage is.

> "at least enough to get around in"

Because, you're right -- cloud-based knowledge changes a lot faster (and gets wider) than standards-based, and it's actually a lot less useful because you don't know from year to year if the knowledge is even still relevant or if the product is still supported.

And, yes, you do need to keep standards-based knowledge top-of-mind, even if you perhaps are not currently building projects on them and even if you can't remember the specifics of syntax etc. Knowing every tool in your toolbox will make you a far better engineer, and, yes, it absolutely can be done.

That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so many different domains at the same time. By the time you gain familiarity with all the domains, the information you initially learned will be out of date or you will have forgotten.

Also, full-stack colloquially refers to someone who can work on frontend and backend.

It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist.

Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”

Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.

On my free time, I work on various things like building a cockpit for a flight sim, building my own Bluetooth door lock, learning new languages and frameworks, creating SDKs for my favorite language to popular services, etc.

Oh but I don’t know how to do SRE. No interest.

I also have no interest in an SRE role. I don’t like being on-call. I build systems to fail gracefully so I never work weekends, but most people don’t do that for some reason.

I currently work as a SWE. We don’t have explicit roles where I work, but my responsibilities are in-line with a principal or lead engineer.

I consider myself a mediocre senior web dev, and I am can humbly say that I'm very familiar with all of the listed, without intentional effort in that direction over the years, simply because I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know. It is natural that it tends to add up.

Over the years, I saw a strong correlation between that breadth and how "good" someone was - on the example of someone working on the fronted in a team, I see 3 basic categories:

1) Not very good: I can do only the most direct and specified things and if something doesn't go as implementation plan intended, or requires outside of what I see as my "formal scope" (e.g. "frontend developer", so React + CSS), I expect someone to solve it so I can continue

2) Ok, but limited: I do only the things inside my "formal scope", so if I'm building a frontend to a web app, it's someone else's responsibility to think about e.g. security - but when something doesn't go as planned along my line of work, I'll find why and unblock it

3) Good: We're building a web app, what are all the things it needs to consider and achieve? My part in the team is this UI / frontend, but if security is important for this use-case, how will my frontend be cognizant of the security goals? I should read up that OSI thing I heard about, cover the basics on my side, and start the discussion on it so we as a team ensure the frontend part is good security-wise

To me this is not equivalent to "very familiar". I think whakim's comment puts things well:

> I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then?

https://news.ycombinator.com/item?id=30474206

Just because you've never met one doesn't mean they don't exist.

However, often, people like this (sadly) move into management or into higher-level architecture types of roles, and let their tech skills go fallow.

Interviews should be focused on skills and experience because those take time and effort to develop. Not 5 minutes on the internet.

They will basically never ever in their entire career need to do this.

It’s like hiring a C++ developer by quizzing them on random gcc flags. These are things that make up 0.00001% of the total work produced by the dev.

If you read a thread on hiring, you'll learn that you can't ask a coding question, you can't do a take-home coding test, you can't talk through system design, you can't expect people to have a Github or portfolio, and you certainly can't rely on academic credentials. At that point, it sounds like you have to hire the first person that responds to your want ad, and I'm sure someone is against that too.

The only consensus is that people that care strongly one way or another will write a comment. Those that don't really care just go read some other article ;)

1. The author is focusing on the first 10 lines, not the whole document. 2. Their "perfect answers" have the candidate essentially reciting the reference docs verbatim.

That to me reads very differently from reading and discussing the whole HTML file. It reads much more like gotcha questions or an expectation that your candidate has extremely specific, arcane knowledge.

For example, the perfect answer for line 1 includes:

> This was especially annoying because each standard generated a different layout so this tag was adopted to make it easy for browsers. Previously, DOCTYPE tags were long and even included the specification link (kinda like SVGs have today), but luckily the simple <!doctype html> was standardized in HTML5 and still lives on.

So to the author, one should ideally not just know what "<!doctype html>" is for, but also be able to rattle off complaints against the previous revisions of HTML. The whole article just comes off as very verbose and stifling. (For that line he does allow for a more basic, but still verbose, answer)

Is it unreasonable for a senior frontend engineer to rely on references for some of these extremely specific details?

! then tab (emmet).

To me though most important is that viewport scale 1 and similar tangent, using offsetWidth for Mac's higher DPI screen.

Another definition I’ve seen is “a senior developer is a developer who can turns other developers into senior developers”

Whereas someone who can autonomously get shit done (and may or may not be good at the earlier definitions) is a “contractor”.

> Note that since our technical discussion is a conversation. I don’t expect a perfect answer from anyone. If I hear some right keywords, I know that the candidate knows the concept, and I try to push them in the right direction

I.e. if you don't know the concept you don't pass.

And in a comment:

> I would much rather hire an all-rounder with deep knowledge of HTML/CSS/JS rather than a particular framework. This “Twitter source code” test demonstrates just that.

He literally calls it a test.

Also, I'm not saying Seniors are lone wolfs. I'm saying that they should be able to work autonomously (I.e. without supervision). I'm not prescribing what that work entails.

One potential problem with this approach of trivia checkbox ticking is that you could be selecting for "mini me" candidates, meaning that you're overfitting for the skillset you already have. For example, maybe the candidate is "full stack" from a primarily backend background, but you're formulating questions like this because you have a frontend background. But then they might seem less qualified than a mid-level frontend-only person because the interview was focusing on frontend, even though stronger expertise on backend would complement your current skill pool better.

I pretty much never look for this in an interview, outside of specific claims from the candidate, specific needs for the position, or the bare minimum.

I try to evaluate candidates for their ability to think, reason and operate in a domain. Knowledge is easy to acquire and useless in the face of changing tech.

The depth of each answer gives you a lot of information about the depth and breadth of the candidate's knowledge. It immediately lets you tell the complete idiot who has always copy-pasted without any understanding from the person who lives and breathes web standards.

Since some of the questions are very esoteric, as you said, it lets you judge how the candidate deals with lack of knowledge. Do they make up some bullshit pretending to be confident (which could be a huge problem in a real project), or do they say "I don't know this one, but based on X I assume it's probably Y"?

Look, all of this clearly depends on what job you’re actually applying for. If it’s a junior role I wouldn’t sweat it a whole lot and wouldn’t ask a question like this. But if you’re interviewing to be a senior front end engineer I absolutely want to know that you can head an HTML source and know what the lines are doing.

[a] You can see this by navigating to `data:text/html,<div>Inspecting the source shows the "naive" HTML. Inspecting the DOM in Firefox shows the added doctype tag.</div>`.

Firefox parses the doctyp from the document. Of course it does. That’s why it’s there. That’s what everything does. What else would it do?

Your footnote is incorrect: `data:text/html,<!doctype html>…` will show a doctype in the dev tools and view source, `data:text/html,…` will not show a doctype in either place, and report the document to be in Quirks Mode. If you want more fun, try `data:application/xhtml+xml,<!DOCTYPE html SYSTEM "about:legacy-compat"><b xmlns="http://www.w3.org/1999/xhtml">Look at this!</b>`.

The history of the doctype is not particularly important any more, and I wouldn’t expect normal developers to know about specific doctypes beyond <!DOCTYPE html>, but its presence is important, and missing it or not knowing it’s necessary for sanity is a definite red flag.

And that’s the first line. Lang, charset, viewport… these are basic essentials that everyone who works in HTML should already know about, even if it’s as simple as “lang="en" means the document is English”, “there must be a <meta charset="utf-8"> right at the top, I dunno why, but it’s necessary like the doctype” and “this viewport tag is to tell mobile browsers that I know what I’m doing on small screens”. Some of the other things in the ten lines aren’t so important for many areas, but you should still be aware of most of them.

The starting point for basic competence is not knowing things, but rather knowing where and how to look: and that requires at least basic broad foundations of knowledge. I would have grave concerns about the foundations of any web engineer that didn’t recognise and know the purpose of at least most of these lines: the first four lines are basic web page functionality, then there’s OpenGraph which it’s important to know the purpose of and what can be achieved thereby, then three lines of mostly mobile browser chrome tweaks and it’s generally wise to be at least aware of this stuff—you get the idea?

I’ve spent too long suffering because of people that don’t know how to write a <title> tag (and writing user scripts to fix this), often because they’re using the Single Page App style and they don’t know how to get their router to change something in the <head>, and maybe don’t even notice it.

edit: I suppose what I'm trying to say is: I wouldn't hold it against an engineer with proven experience if they don't know what quirk mode is, but I would become suspicious of their capabilities if they couldn't imagine any justifications for it after giving them a quick rundown of what it is and how it works.

You seemed to have missed the most important point in this interview. I agree with you that rote memorization is useless, but the goal here is to have a technical discussion on topics like mobile design, accessibility and SEO. And if you're not willing to have this kind of discussion you're doing the interviewer a favor by walking away.

You also don't need to know how to code those by heart, but you need to view at a glance what their use is if you ever need to diagnose an issue, even if it's generated by a framework, because a framework may not generate the proper code for you.

Through the eyes of the interviewer, you googling those tags means you don't know what they do. If you were hired and for some reason had to change those tags, what is the chance that you'll just google and copy/paste? (again, through the eyes of the interviewer)

To be fair, not all people work the same way. Some are happy to swim through the mountain of knowledge that web development has become these days, others are happier specializing in a subset of web development, and others will prefer to diversify their knowledge outside of web development, which means wider breadth in exchange for lesser depth. The interviewed should make sure to clearly transmit how he works, so the interviewer doesn't have to make too many assumptions.

1. What is the current general standard. 2. Does our site do what we want it to do? -> Yes? Then we don't need more meta tags. -> No? Go to 3. 3. Are meta tags part of how to accomplish what we want? -> Yes? Look up the docs and tags needed and implement. -> No? Implement without touching the meta tags of the doc.

That's why focusing on the first 10 lines isn't very helpful IMO. Most of these are things that are trivial to look up and read the docs on when they become necessary.

If you want to interview around a site's source you'd be better served to have a discussion around the whole document.

I see lots of full-stack and generalist engineers screw up frontend development because they don't understand the choices they need to make or understand the consequences of those choices. They lack domain knowledge. Sure, you can Google a meta tag, but if you never knew it existed in the first place you're going to walk into a performance, security, accessibility, or SEO edge case. It's a domain where a good developer with experience is going to outperform a great developer working from first principles.

I usually dislike interviews that focus on trivia. But I also see a lot of people who wouldn't dare disparage other engineering specialisations belittling frontend as trivial. Yes, everyone can and should do frontend engineering, but it is also a domain full of gotchas where esoteric and hard-won knowledge can be valuable.

These are really important details to know to become an effective frontend engineer.

Personally I have encountered several bugs related to wrong or incomplete meta tags on html (css units don't work properly if you fail to declare correct doctype).

Not knowing them will either slow you down in solving a problem (SEO, performance, browser compatibility), or introduce a variety of bugs sooner or later.

IMHO, if you like the company, just answer the question and add 20% to your ask (fee to deal with person X). The hiring process is usually irrelevant to the company culture in my experience.

When I was hiring for my startup it was really just a conversation and reviewing some of their code / ask them to explain what they were doing in a very casual way. Get people relaxed so it’s not some dreaded test. Worked really well for me, but that’s anecdotal. The idea that there’s one true test / formulae is asinine.

Are you really suggesting that actual qualified web developers don’t know this stuff?

This isn’t even fizzbuzz. I was inclined to think these questions were too obvious to ask but I think these comments are completely validating the interview question.

I also believe I’m fully capable of googling the specification and understanding this in like 15-30 minutes, but by your definition I guess I’m a fizzbuzz failure.

Do you know why the document starts with a doctype declaration? What accessibility tags are and why they are important? What is OpenGraph and why SEO is important? What are CSS resets and why do we use them?

If you can take a guess you're already halfway there. If you can explain what you know about them you've aced it. It's not about knowing all of the meta tags or the OpenGraph attributes, it's whether you can have a discussion about mobile design, accessibility and SEO.

I see fizzbuzz as a basic test to see if one can synthesize basic programming concepts and implement something that works. Explaining the first few elements on an html5 document is more like asking if you have definitions memorized in my opinion.

When you hire people you need to check for basic competence.

I've hired plenty of FEDs and it's a nightmare, let me tell you!

It's not about answering the questions as such; it's about how you answer them and your ability to reason.

The lack of basic knowledge is appalling across the board. The industry is full of copy and paste developers with Computing degrees that essentially have zero useful skills. I'm speaking as an Australia BTW. So YMMV :-)

Interviews are as much about what it would be like to work with somebody as they are about this supposedly esoteric knowledge. If your reaction to a question you didn't see the value of would be to end the interview immediately, I think they'd be glad to have found that out so early.

The years of experience line is nonsense. I learned html 25 years ago and can only describe what that line does in pretty generic terms. It's like asking a journalist candidate to give you the Webster definition of "amalgamation".

Given his perfect answers I probably would have been able to come pretty close to passing.

If you know anything at all about the details of html, all of these can be easily understood by looking at what they're claiming to do. None of these are esoteric even if your front end knowledge predates wide spread use of mobile devices.

Take line 5 for example. I have never heard of Open Graph, but I know that og: is declaring a namespace for a pretty self describing tag. It's clear from this take with no other information that it is providing a site name for a specific service.

I don't think it's a big ask at all for a senior front-end dev, who is fresh in the field, to know what the first 10 lines of one of the most popular websites out there is doing.

In my experience, wanting to know why things work the way they do (instead of just accepting that things work a certain way) is a very desirable quality in candidates. Sure, the candidate might have figured out why it worked a certain way and then forgotten about it (which I think is totally fine in this context), but then the interviewer gets to see how candidates approach unknowns.

It's the equivalent of asking someone to multiply numbers together by hand instead of just using a calculator. Ok I can do it, what have be proven here? Not a lot really.