> The first line of every document’s source code is perfect for this interview because how much a candidate knows about the DOCTYPE declaration closely resembles how many years of experience they have.

This just screams "I have some esoteric knowledge and I'm going to lord it over you", sure I remember vaguely when the html doctype first came out but knowing what that does doesn't make me a better programmer. I write that line 1 time max in a project and then never think about it again. Why would you ever harp on that? Especially when most frameworks your are going to be using handle that all for you or it's in the default header block/index.html?

Talk to me about how I'd solve a problem or how I'd architect something but don't quiz me stuff I rarely need to know. Even PHP argument order (a near-useless skill) is more useful than this list. Give me 5 minutes on google and I'll tell you what every single one of the tags mean/do (the ones I might not know off the top of my head), that's a way more important skill then being able to spout off what they are from memory.

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.

Now, whether or not that would be a good indicator for my viability as a front-end dev, I’m not sure. But at least it would show I have an understanding of what is going on and how to read and explain it. Which is better than a lot of leetcode exercises.

I actually like the idea of asking people to explain code to them — even if it isn’t something like the first ten lines. If I’m proficient in a language, I should hopefully have a good idea of what is going on, at least in a sample app. And that is a useful skill, especially if your job is to come into an already established codebase.

FWIW, I have yet to see any discussion about interviewing on HN that didn't attract a lot of pushback in the comments. It doesn't seem to matter what format the interview is in (technical questions like this, leetcode-style problems, take-home problems), it will attract angry comments on HN and Reddit.

I suspect a lot of this is exaggerated. In the real world I've only ever had a couple candidates decline to do take-home interviews, and that's only because they were 99% sure they were taking another offer at that point. Back when we did in-person technical interviews we never had anyone end the interview early because we asked questions that were too hard (as the top HN comment claims they would do).

Take interview-related commentary on HN and Reddit with a grain of salt.

It'd be like me asking what type of lock Postgres 12 awards when dropping an index concurrently. Or how long it takes for an AWS SQS message to time out. These things don't matter at all during an interview for the vast majority of positions. What matters is figuring out if someone understands how to build software. Do they think through realistic problems well. Do they know the difference between memory and disk.

For example, if there is a conditional index that is frequently accessed, but is small, the O runtime doesn't matter because it's for sure going to be in memory. That's the type of thing that can naturally come up during an interview when you ask someone to, say, plan out a social API endpoint. But the question shouldn't start with the hyper specific because at best that tests recall ability and only after many, many questions have been asked. It doesn't test inventiveness, pragmatism, thoroughness, and attention to detail all of which are far more important than random trivia.

That's it. Anyone claiming to be a senior full-stack engineer should be able to BS their way through this.

If you're shocked by what you see on a "view-source" screen, then you haven't been doing this for very long, and you're not really "full stack".

The main thing here is that a senior engineer could:

1. Know how to find out what each of those mean (junior engineer level work)

2. Most importantly, be able to come up with a good set of meta tags after some research (mid-to-senior level)

Being able to B.S. your way through reading the tags tells me nothing. It's like asking language API trivia questions.

It's weird to use "memorization" as basically a synonym for "remembered". Being a good developer is not just copy-and-pasting things from google, it involves actually understanding some technologies. Understanding technologies is not "memorization".

I could explain nearly every one of those ten lines (and again, I’d have to see to full origin-trials line to know for sure, but I’d say there is a 70% I could infer/BS the answer), not because I’ve memorized anything but because I’ve spent years writing and reading this sort of thing.

Now, if you asked me to write the first ten lines perfectly without any mistakes or use of code completions or boilerplate, I would almost assuredly fail. To me, that’s a stupid memorization test. But asking someone to explain why something is there and what it does, I don’t think that’s the same thing at all.

Knowing what these 2 tags are for is fundamental, the wording of the attributes are vaguely self-descriptive, and recognising CSS from HTML is instinctive.

You can't "get stuff done" without being able to at least bullshit the basics.

I don't want people who tell me "it's all under control" and "I know this" and then the result is a disaster. I want people who tell me "I know X and Y but I'll have to look up Z". Tell me that you don't know but are assuming, then show me your reasoning skills by "BS-ing your way through it".

Also, if I have the least bit of doubt about what I'm going to say, I always start with "not really sure about that, but ...". Might seem weird at first sight to be a candidate who is not sure about anything, but it shows you can recognize your own lacks(and look it up if needed), shows you're humble, and usually scores some extra points when you still get most answers right even if you were not so sure.

It’s also really stupid. An interviewer wouldn’t ask a question like this unless they knew what every line of code shown does. By all means say “I think this does X, but I’m not sure”. But if you boldly tell me it does X when I know for a fact you’re wrong, that will go badly for you.

This is probably a test of some useful ability for developers to have, but it's not knowledge of these things in particular.

Also:

> <meta name="theme-color" [...]

> This is the proper web standards-esque equivalent of the Apple status bar color meta tag. It tells the browser to theme the surrounding UI.

Oh, so this is the horrible thing that's infecting my desktop Safari and making it hideous and weird and inconsistent? Interesting.

Devil's advocate - is it? You're right, this stuff rarely gets touched, and (aside from changing the colours in the bit you hate!) it's the kind of stuff I'd normally boilerplate between projects.

But if you're interviewing for a role and you're not giving them a coding test (yet?) but looking to see how curious they are, how disparate their knowledge is, or just (as you say) how good someone is at guessing from context - isn't this a fun experiment?

I'd imagine just seeing how people deal with the answers gives you a good idea as to how they'd approach something when you're working together. Are they guessing? Confidently wrong? Seen it before but don't know what it is? Can roughly talk around it and what it does without exactly knowing? Proficient in it all (and how that relates to what they have or haven't said on their CV - have they under or over sold themselves?!)?

I assume you could apply the same sort of test to any domain - test someone on something closely related you don't necessarily need to know and see how they react.

Of course you can then ask a different question, follow-ups, and so on, but you're so far off baseline compared to most candidates that the question starts to become useless.

The point is to ask a few randomly sampled knowledge questions to measure how well rounded the candidate is. Taking the "first 10 lines of Twitter" is just one way to sample such questions.

I am not sure this is well grounded in the studies of human psychology.

A lot of companies are far too hesitant to trust employees, but blind trust is unwise - you can end up with an employee that either wastes three months salary or actively causes damage.

There is a ton of well researched psychology work on self deception, confirmation bias, it goes on and on.

Asking about the things that the OP was mentioning are deep psychological traps. Perhaps the OP has deep self awareness, but that does not apply to the general candidate or human.

Our blind spots of our own actions and behaviors are profound.

If you have specific pieces of technology you're working with and want to interview about then take an afternoon and just code up some bizarre snippets to go through with them - add a few mistakes they should be able to catch and just talk through their process.

I honestly don't think opening up a random website and asking about some of the source code is a terrible approach... if you're interviewing someone for writing HTML in the 90's - in the modern world all the JS is minified (and likely generated by a framework), the CSS is absolutely atrocious to read (usually also generated) and the HTML is pretty much irrelevant. Use something that's going to be applicable to candidates to judge their understanding - I've always been fond of short puzzles very much unlike this one (it's way too arcane) in PHP `0x5 &$var=['cow' => 6]['cow']`[1] - just blerbs where you can step through some syntax understanding and problem solving at the same time.

An actually good suggestion is to check out a random (ideally mostly self-contained) file from your codebase from a decade ago and step through what's awful about it - all code bases have these, and they're usually still kicking around as active code in production. At one of my more recent interviews they sent me login.php (the one actually in production, which they knew was broken - they had two developers before me which were really overworked) and just asked me to mark up wrong stuff - I found SQL injections, unbound variables, conditions that would result in invalid HTML and broken forms and some terrible decisions from a readability perspective. I spent... maybe an hour on it.

1. https://3v4l.org/85MV3

> 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.

If I were being interviewed, I would probably say "yeah all those meta tags are metadata for various consumers. The apple related ones are probably for tailoring the page for display on apple devices"

Hopefully that's good enough, if I were doing the interview I wouldn't expect more than that.

> Surprisingly, only a few people knew about the dir attribute in my interviews

No. Most of those few people who "knew" it are decent-to-good readers with enough context to figure it out, and in this particular case they probably recognized "ltr", then worked backward to get what "dir" means, and were confident enough about that guess to state it as fact. They did all this in less than a second, because, again, they're decent-to-good readers who had the right context for this particular task. If this had been a made-up attribute you'd have gotten nearly as many people who "knew" it, I guarantee.

This is closer to a web dev reading test than a direct test of knowledge. Which, again, might not actually be a crazy thing to administer.

I see this too often. A developer (usually more towards the junior end) who think they can just chug through any problem. Trying this, then that, then google, then that again. When, if they would just stop and think through the problem - and use their eyes - they would see the solution was there all along.

Exactly. Surely being able to actually configure the metadata tags on a webpage correctly must be more valuable than being able to remember what the different configuration options do years later, no?

I assume this isn't the only question OP asks in their interviews, but I think it's got a couple of good outcomes and returns a lot for the length of time it takes to go through.

Have things changed so much that knowledge of meta tags is specialist now?

Assuming this interview was for a front end role that is.

Like take the open graph meta tags for example, for certain websites it'd be a big oversight to leave them out because you never bothered to learn what they were.

I don't know if all this makes for a decent interview. Just blows my mind that people deem it too low level to have to care about, but what do I know anymore, it's been a real long time since I made a web page.

FYI you can disable the coloring as well as the "compact" layout that mushes the URL bar into the active tab and hides its <title>

https://www.macrumors.com/how-to/safari-macos-turn-off-websi...

Much better. No more wild recoloring of my browser chrome because I switched tabs.

> FYI you can disable the coloring as well as the "compact" layout that mushes the URL bar into the active tab and hides its <title>

Did that day-1 with the new Safari. That part was wholly intolerable, not just ugly and annoying.

- https://github.com/kevinSuttle/html-meta-tags

The intention of questions like these aren’t to see if you know all the answers, it is to have a discussion and to learn about your experiences and see how you think.

Also if you’re applying for a web dev role and you’re not fairly familiar with what real world HTML looks like it’s may not be a great fit. You may not remember the exact syntax (because who care, you can google it), but you should have an idea of what you’re sending over the wire.

Also HN: complains about alternative conversation-style interview

I don't work on the front-end, but I have had a general curiosity for it for a while, and I think this would have been a great conversation starter! And I think a lot are missing the point that the interviewer isn't exactly using this to just "fail" people. Like you mentioned, these are the sort of out-of-the-box conversation starters that good interviewers try hard to come up with so they don't have to just give coding tests and ask the top 30 JS trick questions that are easily googleable.

Like web developers who couldn't make a reasonable guess at more than two of these lines.

I get that this might be the intention, but if you're being interviewed, and asked to explain the first 10 lines of some code, you'll rightfully feel nervous, and feel as if this is a pass or fail test. If the intention is to make this a discussion, perhaps change the question, and start the discussion yourself.

Source code implies it's a programming language. This is not. This is HTML, which is a Markup Language (hence the ML in HTML).

There is probably some Javascript code there further down but you didn't look at it.

In common parlance, Twitter's source code is the source code to their web services and backend systems, which is not public.

Are we going to giggle about how those dumb browser developers don't know that it's not actually the application server source code, or can we admit it's the source code of the rendered page, a different layer of the stack?

Is it really that much of a mistake to shorten "Twitter's [html] source code"?

Frankly, I think a bigger pedant could come in here and correct you.

Check out Alan Blackwell's "What is programming" paper from 2002. In it, he argues that we should not be asking "is writing html programming", because that question comes from an older (past overdue for revision) mental model of what programming is all about.

I can't recall ever seeing someone use the phrase "X's source code" to mean HTML. In my view it's data, not code. Just like you wouldn't call some XML file "source code" -- it's purely descriptive markup. When a browser's context menu says View Source, the word "code" isn't implied. It's the same usage of the word "source" meaning "origin" (as in "cite your sources").

Maybe I'm being overly pedantic, but the phrasing definitely read strangely to me regardless. Speaking as someone who's done a mixture of programming and web development for over two decades.

That would make me wonder about the interviewer's experience. That's not a feeling you want to have at the start of an interview

Yeah, right.

HTML is supposed to be <html><head>head stuff</head><body>body stuff</body></html>. But in practice you see multiple HEAD sections, missing HEAD sections, multiple BODY sections, missing BODY sections, and even multiple HTML sections. If you omit all those tags, it still works, mostly.

    The title tag SHOULD occur in the head of a document[1]

    The <title> element is always used within a page's <head> block.[2]

1. https://www.w3.org/Provider/Style/TITLE.html

2. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

3. "HTML5-compliant browsers automatically create a <head> element if its tags are omitted in the markup. This auto-creation is not guaranteed in ancient browsers." https://developer.mozilla.org/en-US/docs/Web/HTML/Element/he...

It is in a <head> element. You don’t understand how HTML is parsed. The opening and closing tags for the <head> element are optional. That doesn’t mean the element isn’t there, it means that the element is always there.

> They are leaning on browser compatibility mode to cover the fact that they aren't adhering to standards.

They aren’t. See this comment I made and go ahead and paste that HTML into a validator:

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

There is no error handling taking place, there is no browser compatibility mode involved. This is correct HTML that adheres to the standard being parsed normally.

> [1], [2], [3]

Why are you quoting a style guide written in 1992 and two unofficial sources when you could just as easily have referred to the actual HTML specification?

> § 13.1.2.4 Optional tags

> Certain tags can be omitted.

> Note: Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup.

— https://html.spec.whatwg.org/multipage/syntax.html#syntax-ta...

The HTML specification literally gives this as an example of a valid document:

    <!DOCTYPE HTML>
    <title>Hello</title>
    <p>Welcome to this example.</p>

It’s not. Every single part of what you quoted is optional, and you didn’t include the parts that are actually required.

This is a complete, valid, correct HTML document:

    <!DOCTYPE html>
    <title>…</title>
    …

You never see this, ever. It’s not possible to have an HTML document without a <head> or <body> element. The document I listed above has one <head> element and one <body> element. Both the opening and closing tags for these elements are optional. When an HTML parser parses that document, it will construct a DOM with those elements in it.

> If you omit all those tags, it still works, mostly.

Omitting these tags works completely. This is valid HTML that follows the HTML specification correctly without any need for error handling. All browsers follow these parsing rules without any problems.

When would you actually create such tags as a fullstack dev? Almost never. 90% of the time, those tags are auto generated by some boiler plate app.

A person that can answer correctly MIGHT be someone that's looked into those tags and done things the hard way, but is that really someone you need to hire? A person that answers incorrectly doesn't necessarily seem like someone I wouldn't hire. After all, what do I care about someone knowing the intricate details of the "html" tag and how it interacts with various browsers? That's write once and forget sort of code.

If you wanted this test to mean anything, why are you picking worthless trivia. Why not, instead, pick something like a function out of jquery or your own code base and ask the same question "Tell me what this function is doing".

The point does not at all seem to be "Aha, gotcha! You didn't know about the syntax for Apple's limited PWA like functionality offhand in an interview. 5 demerits, next question!".

A person that can hold a good discussion around these tags is both likely to be one that has truly been developing pages for a couple of years and has an interest in learning more than how to make their framework work rather how to make any framework work in a browser. If you're not able to say something cursory about language attributes I'm going to have a hard time believing you've full-stacked a multi-language website (not that I wouldn't but it'd lead to a lot of different questions later). If your response about the doctype line is "it's boilerplate put in by my IDE" my first thought isn't going to be "oh they just spend a lot of time writing code in the rest of the page" it's going to be "they either don't care what the first line of the page is about or it's been so long since they've touch the front end directly they can't say anything about the first tag. I wonder how well they can deal with integrating the front end JS with the page" and steer to towards more about that.

Also the interview was mentioned to be an hour long, if 10 lines of HTML boilerplate, most of which should be on every page, is too far into the weeds of front end time wise then I'd have severe concerns the candidate would be too back-end heavy. Yes, other things should be talked about too, that's why the interview is an hour and this singular question is only about 10 lines.

Well, that's a problem. If you don't know how to create a web page with out having to fall back to using "some boiler plate app", I question if you really are a fullstack developer (I would also question if you really can consider yourself a web developer at all, but I know that will just upset people, so I won't go there).

This is the equivalent of interviewing for a C developer by letting him explain a Makefile.

What if that C++ dev primarily uses visual C++ and Visual studios projects? What if the C++ dev primarily used Cmake, ninja, or scion (or any of the other thousands of C++ build tools).

What if that C++ dev never really needed to start a project from scratch?

The issue is testing someone on minutia doesn't tell you anything about how capable they are. In particular, testing them on minutia that they very likely rarely interact with is beyond pointless.

Then it's an opportunity for the candidate to explain the tools they do use.

There are certainly bad interviewers out there who misuse these kinds of questions, but I think they're fine if used as conversation starters.

But to the point, I'm not sure if the code at issue would be considered minutiae or not, but I believe that the more curious you are, the more you tend to dig into the details, and a person doing this over many years would attain a rich knowledge-base spanning depth and breadth. I know as a java developer that I've referred innumerable times the docs for the POM and settings structure in order to explore the limits of customizing my build, which would include the rather obscure features. Not saying this is technically comparable to meta tags in html, but maybe that's what the author was going for.

It's that the signal you're gonna get out of such an interview is gonna be so low that whoever you end up hiring is mostly going to be due to chance + how much you "liked" them.

-- Robert A. Heinlein

I'm definitely a "senior" web developer - been doing this since '97 - but I couldn't talk fluently about a number of these tags, particularly the exact meaning of each of their properties. However I have used most of them at one point or another and they at least ring a bell.

Most of them are tags you throw in at some point to solve some problem or other and forget about them. At least, that's the way my memory works.

They are, however, an interesting Rosetta Stone into many different browser quirks and technologies that I would expect a senior developer to know about.

If I were to show this list to a candidate, I might ask them to pick one of the tags and talk about a time they used it in a project, to keep it on a level that's comfortable for them and not risk "freezing them up". I would expect the discussion that ensued to give me a good sense of their depth of knowledge in one area. After a few minutes, I'd move on to another topic.

"So, instead, we have an hour-long technical discussion where I ask them questions about web vitals, accessibility, the browser wars, and other similar topics about the web. One of the questions I always like to ask is..."

It's ONE of the questions, so those concluding it's a terrible interview altogether are dramatizing.

As for the question being relevant or not, I think it actually does say a lot about a developer. Just those few lines of code show historic knowledge, internationalization, SEO and social networks, mobile optimization, CSS normalization, and bleeding edge features (origin-trial).

In that sense it's an effective question. You learn a lot about someone with little code, even if the understanding of some individual lines is not a showstopper.

Finally, saying that your framework usually generates this for you isn't the great answer you think it is.

I also find it strange to pick apart and quiz on the messy output of Twitter's frontend frameworks, compilers/transpilers, minifiers, bundlers, etc. It's akin to feeding a binary or some bytecode into a decompiler and quizzing on its output.

If they're applying for a web development role and say "I don't know" to all of them, it tells me enough about their skills and abilities to end the interview right there.

If they don't know half of the trivia but tell me "this looks like it probably controls browser feature X", and they're making a reasonable guess (regardless whether it is correct or not), that's a good sign.

If they don't know something but confidently pretend they know and spurt bullshit - red flag. I don't want to have to second-guess everything they say, and have them deliver something that looks right while being completely wrong.

If you don't know what that specific prefixed attribute does, I don't care. If you don't know what a vendor prefix is in CSS, you haven't written much CSS.

I want to revoke the keyboard from whoever decided this is a feature.

I understand removing features in order to clean up a UI, but this serves no such purpose. It's purely removing a feature because you think you know what the user wants, despite there being no negatives to leaving the feature enabled.

Providing it as a setting has the advantage that developers just set it (and you can tell your browser to ignore it), instead of finding some horrifying and harder-to-avoid way of preventing the browser from zooming.

A better approach is to drop into some code and ask the candidate to explain it. What's the code doing, why is it doing it. Maybe even show some code with a bug and have the candidate fix the bug. That's like 60% of most jobs right there. Reading code, understanding what it's doing, and figuring out how to make changes to it.

The article says this:

You might think that this information is redundant because the browser already knows that the MIME type of the response is text/html; but in the Netscape/Internet Explorer days, browsers had the difficult task of figuring out which HTML standard to use to render the page from multiple competing versions.

Are there still a lot of browsers in use that have difficulty figuring out the HTML standard, and if not, is the doctype declaration just an anachronism of markup?

Asked in a less roundabout way: If response data is sufficient for a browser to know what it needs to do, and modern browsers support such capability: why do we still declare document types?

I suppose my real question is (and maybe this is a discussion that's been beaten to death and I'm merely ignorant of it): why does the standard require it, if modern technology seems to have obviated the need for it?

Am I too far off the mark with "backwards compatibility" as a scientific wild-ass guess or is it more complicated than that? And if so, with what kind of devices/browsers that would still be in use today?

Thanks for taking me to school.

The HTML5 string basically says "I promise to be good, please turn off your weird workarounds". Of course, HTML5 has been around long enough that some browsers still have certain quirks, but they're not as extensive as the ones before HTML5.

Compared to the `<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">` monstrosity from before, I'll happily take the modern standard. There's no version number anymore, just a simple HTML identifier.

I guess it'll disappear eventually and become an opt out rather than an opt-in, but not sure if we're there yet, IE11 has been a major drag on progress.

At least Twitter has the decency to mark their proprietary standards as proprietary.

https://developer.twitter.com/en/docs/twitter-for-websites/c... (scroll to bottom)

For example, maybe you want to specify a Twitter username for your Twitter card but for all other OpenGraph consumers you want different attribution. You may also want to serve a specialized crop of the image to Twitter vs other consumers since they all display differently (Facebook doesn't crop the preview iirc but Twitter does, so you may want to specialize the image for Twitter).

It's not completely braindead that they let you specialize for Twitter.

The design was that HTML was HTML and the client managed all the implementation details. Over time that got ruined by wildly different implementations, introducing non standard tags and so on.

I'm glad I moved away from it before mobile versions of sites became a neccessity.

Having to do all this work to cater for members that have a mobile device made by a specific manufacturer just emphasises that the whole thing has gone totally off the rails and completely awry. The ratio of actual information you read vs the amount of cruft that comes with it to display it is insane. And it's been a major issue for a long time. It was painful enough in the 'if !ie6'...era.

At what point does the ongoing cost of presenting and maintaining the information exceed the value of the information itself?

However, this is the reality of the online world we live in today. It also makes you appreciate the simplicity, usability and maintenance-ease of HN itself. You're already into the actual content only 3 lines in.

I do find this an interesting question in some ways, it probably gives some insight into the breadth of knowledge and experience. But I would not spend too much time on it. Get the impression, move on.

What would potentially be more interesting is to ask them to look up some of the things they don't know.

But interviewing is hard, it's a strange dynamic by default, it's hard to not make it cringe. A conversation like described in the article is sort of nice compared to many other tactics.

Yes, but you need to have some foundation of quickly-accessible knowledge ready to go, so you can focus on looking up the hard things. Technically I could hire motivated college students and give them years and years to look everything up and study it as they go, but I could also ship the same software in a fraction of the time by finding someone who has experience doing something similar. That's the purpose of interviews: To gauge baseline experience.

The alternative interview format is a take-home problem. The candidate receives a small, arbitrary problem (not real work) that approximates a ticket they might work on at the job. They're free to solve it at home on their own time.

Unfortunately, take-home interview questions are also a contentious topic on HN. A lot of people on HN insist they refuse to do take-home problems or otherwise hate the idea of candidates having to put effort into the interview outside of the conversation.

I think the real take away is that engineers (and other professions) just don't like to interview. Nobody likes sitting in front of someone else and having their performance evaluated. Nobody likes potentially being rejected. Nobody likes being asked to do effort to interview for a job they might not get.

If you throw a Staff engineer into a new domain they're likely going to quickly become more effective than a mid level engineer with domain knowledge because they have better meta level skills.

Of course, this is very dependent on how specific the function of the person you're hiring is and how quickly things are moving. If you're hiring for a very specialist role then knowledge will be a lot more valuable. Same goes if the domain is not moving very quickly (I.e. historical knowledge is valuable).

Though in general, I think a lot of people would jump to hire a SWE who has been an expert in a different domain.

Well said! I very much agree.

Memory? It is not a test to write rare parameters correctly, the questions problem the knowledge about the most basic things in web development - html. It's like asking a surgeon in a hiring interview if he knows what a scalpel is; not the chemical composition or forging method, just what is used for. Imagine the guy saying "I don't know, I never memorize this stuff".

I really don’t care if someone memorized all the meta tags. What matters to me is that if I ask them to write a template they can find out what they need to include according to the latest best practices and our situation. I rather have them looking it up than relying on something they memorized years ago and might be outdated.

Looking things up is not the same as carelessly assembling as you describe it. It’s the ability to gather knowledge quickly, learn on the spot, so they can work on things they haven’t worked on before, and keep up with the latest best practices. Absolutely essential to FE development.

And some of it is assembling and relying on tools to work efficiently; for example I would highly recommend to generate Favicon and tile tags.

To be an effective fe dev require tons of learning on the job and doing your research as new things arrive constantly, best practices change, and you will encounter many things you haven’t before.

Like I said; experience and breadth of knowledge is an interesting indicator, but it doesn’t make much sense to me to have it as the main indicator.

> Imagine the guy saying "I don't know, I never memorize this stuff".

Then I would ask them to look it up and get an impression of their ability to gather quality knowledge and understanding. Not a problem to me, and I would appreciate the opportunity to gain insight in those skills.

That is perfect for a junior, not acceptable for a senior that is supposed to already have solid experience with that stuff; HTML tags should be something they worked before a lot.

It seems likely that someone applying for such a position would be interested in the fundamentals of the subject matter, and also that they would realize that the goal might be to start a conversation.

Let's move away from this particular topic for a moment. Were I hiring someone to teach English literature, I might ask the applicant to talk about their favourite novel, play, or poem. The idea is to learn, through indirect means, whether the person has a long-standing interest in the work at hand.

Prompts to have conversations that expose a candidate's depth of knowledge in real world cases are exactly what an interview should contain...

I firmly beleive that a good software engineer will never pass an opportunity to write code during the interview, being it a Leetcode, "explain this" or architectural flowchart. If I feel that the task is too easy - good for me, I can ace it and grab some extra points talking about how I would test or deploy that code.

Leetcode could be hard. Writing code on a paper could be even harder - I tried it myself. So, denying it you are showing that you are afraid of hard problems. I don't treat it as a strong downside, and I beleive that there are a lot of teams where this type of personality is totally acceptable. But I don't think those teams will ever be successful.

I think I'd have missed at least half what he's asking for because front-end work is not what I focus on primarily and I didn't get to see the entire line of code.

I spend most of my time designing logic flow and writing functions to perform it. Asking me to do front end work would be a waste of my skills. I'll never be as good as someone who specializes in that, and I don't know many who do that would be as good as I at what I do.

I'm sure there are many who are better than I at what I do. I learn from them everyday, but I doubt they spend a lot of time on front end stuff. They probably do what I do, copy and paste that stuff and get to work.

The author isn't looking for exact right answers and just wants a discussion about the technology to gauge your skill.

I enjoy interviews like this.

Because it's not. It's a step up from typesetting.

There is a small if very vocal minority of webdevs acting like their work is the most meaningful and complex work imaginable when the "source code" they work with is what you would get if a 2nd year CS student was asked to re-implement LaTeX in XML.

Gatekeeping is so much more prevalent in webdev because it's really not that complicated until you abstract your framework a couple levels up and then insist it's the industry standard.

The perfect answer calls these elements, not tags.

I think it's fine to have some ridiculous questions that you don't expect anyone to get perfectly, just to gauge, though it's important to communicate that to the candidate so their nerves aren't rattled when they feel out of their depth

[1] https://github.com/mdo

And manifest wasn't even in there. though does anyone actually 'install' pwa 'apps' (sorry double apps)?

IDK why anyone who's main job is not SEO or building static html pages should know this. Except maybe viewport for people writing css by hand. Hell even then.

You can just use a generator. I think the SEO one that generators most of this is the #1 wordpress plugin

I’m actually impressed there was quite a lot to discuss in just 10 lines. That said, i’m less convinced it’s worth spending precious interview time on it, but I could be persuaded.

I've interviewed lots of developers and that's much more important to me than whether they know the intricate details to see whether they are good to hire.

Also, why does the document not have a <head> tag? And, why does it not have a <title> tag?

It appears that many things that I thought were normal to put into an html page are not.

  ...haW4iOnRydWV9" /><style>html,body{height: 100%;}</style><style id="react-native-stylesheet">[stylesheet-group="0"]{}

<head> is optional in HTML5 syntax. It's implied by the first <meta> tag. There's still a <head> element, which you can see in the DOM inspector.

<title> is optional. But in Twitter's case, the <title> element appears to be added later by JavaScript, as it's not in the page source but it is in the DOM after loading.

Various people say <head> is omitted to save space because it's optional in the HTML5 syntax anyway, and that shaving off a few bytes is worth it. It is to save space, but it seems hardly worth it when you look at the full head section, which has a large number of <link> elements>, and the long content of the origin-trial <meta> elements. They suggest the page is not particularly optimised for size.

To see Twitter's head section properly, it's best to view source, copy to a text editor, then insert a newline before each "<" where there isn't one already.

Those are normal things, but some companies like to deviate, often just to be different. For example, Google uses a Unicode lightning bolt as its DOCTYPE for Amp pages.

However, saving 100 bytes on a page load can end up being actual money saved when you shove out as many pages as Twitter does in a month.

There is a <title> tag, but it's created by Javascript. You can see it with document.querySelector('title') once the page loads.

This one surprised me a bit. Are there browsers that are default Right-to-Left rendering and are going to put English language characters backwards if you don't specify the direction?

> The directionality of an element (any element, not just an HTML element) is either 'ltr' or 'rtl', and is determined as per the first appropriate set of steps from the following list:

> ... If the element is a document element and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value) ...

> ... The directionality of the element is 'ltr'.

It's not that common to see LTR explicitly specified for the document, but you could imagine some code that either outputs ltr or rtl based on the user's preferences. (Indeed I just checked and twitter puts a rtl there if you're using it in Arabic)

> echo('<html dir="$dir" lang="$lang">')

(or something similar), and they unconditionally include the `dir` attribute without checking if it's already set to the default value a browser would assume.

Unless you're hiring someone with indepth experience/PTSD of supporting IE6.

But to have a discussion about quirky html history would be a fun (I think less stressful) way to spend the time.