8 ms·

I'm sorry but if a place I was interviewing for asked me this I'd end the interview and move on. This is about as useful as knowing how to write C boilerplate o

I'm sorry but if a place I was interviewing for asked me this I'd end the interview and move on. This is about as useful as knowing how to write C boilerplate on paper from memory (something a college professor had us do for an exam), which is to say it's completely useless. > 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.

chrismarlow9 5y ago
Yeah I'd only ask that question if I was interviewing people to work at w3.org. 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".
tinco 5y ago
I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not a senior frontend web developer. He's not asking you to recite them from the top of your head, he's asking you to have a simple conversation about them. 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.
- joshstrange 5y ago
  > I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not 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.
  - jenscow 5y ago
    This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, according to your job title, at least vaguely familiar with. 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.
    - gunapologist99 5y ago
      > 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.
jollybean 5y ago
It's not 'useless' and it doesn't scream 'knowledge signalling' - it's just not a very good question.
zitterbewegung 5y ago
IMHO instead of doing fancy tricks the first day for interviewing take something that could be completed in one day at the job you are interviewing for and if you can complete it or get it near enough I would think that would be a better criterion to hire. Also, this interview would be paid for the first day at the same rate that you would be hired for.
- smaddox 5y ago
  Wait... completed in one day? So an ~8 hour task? That's way too much of an ask for an interview, in my opinion.
- withinboredom 5y ago
  Not everyone does well in a high stakes environment, which is what this sounds like it would create.
forty 5y ago
It's not a very good question and it's not a very good answer either. Discussing the DOCTYPE without mentioning SGML or XML seems to be a bit weird to me.
- rjh29 5y ago
  That was more relevant 10 years ago. Nowadays the primary point of the html doctype declaration is to say 'I am HTML5'. I know this and I'm not even a frontend developer.
  - forty 5y ago
    Agreed it's not too relevant, but if you are going to ask a knowledge question, rather that a skill question, you might as well expect some theoritical knowledge :)
ASalazarMX 5y ago
I'll gladly admit that creating boilerplate from memory is a low-value skill, but you absolutely must know why it is there, and what does it do. 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.
- withinboredom 5y ago
  Their answer should include googling the latest accepted specification if they’re going to be making changes or creating new ones from scratch. If their answer is to go to stack overflow, you might have a problem.
- pythonaut_16 5y ago
  How to change meta tags: 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.
tgsovlerkhgsel 5y ago
I think it's a very good question. You're not just checking boxes and giving a score here, and if the interviewer is any good, it's not just about "how many correct answers". 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"?
- teaearlgraycold 5y ago
  I agree. If this is judged by how many you can answer then the interview isn't useful. But if the interviewer uses it as a launching point from which the candidate can talk about their experience with web technologies then it's a great addition to a longer interview.
rapind 5y ago
You’re not going to convince a technical hiring manager that their puzzles are demeaning or pointless. They believe they’ve beaten some sort of game. That they post / blog about it just reinforces this. 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.
n8cpdx 5y ago
jfc I work full time on .NET desktop and even I know this. This is fizzbuzz. 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.
- plandis 5y ago
  I lead a team running very large scale distributed systems with almost a decade of experience and I could take a guess about what these elements and attributes mean but I don’t claim to fully know them. 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.
  - mileza 5y ago
    You missed the entire point of the article. The point is now to know whether you know those 10 lines by heart, it's whether you can have a discussion starting from just this. 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.
    - deleted 5y ago
      [deleted]
    - plandis 5y ago
      I’m responding to someone who claimed this is a good fizzbuzz test which is different than the point of the article.
  - n8cpdx 5y ago
    Could you not also Google the answer to fizzbuzz in 15-30 minutes?
karaterobot 5y ago
> I'd end the interview and move on 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.
oldstrangers 5y ago
A lot of these things are also automated from whatever framework, CMS or plugins you're using. It's the kind of thing you usually aren't writing in by hand, and shouldn't need to. 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.
whakim 5y ago
> I write that line 1 time max in a project and then never think about it again. 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.
draw_down 5y ago
deleted 5y ago
[deleted]
afavour 5y ago
Very surprised to see this as the most upvoted answer. Stuff like doctype is HTML 101. “A framework is going to output this for you anyway” sets alarm bells ringing in my head, it shows that you don’t actually understand the underlying technology and you use frameworks as a crutch. 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.
- ipnon 5y ago
  It's pedantic. Firefox parses the doctype from the document itself,[a] and no one is using Netscape anymore anyway. Any web engineer could learn all of this in an hour if need be. If they don't know it already it's because it is simply miscellania tangential to building web applications today. [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>`.
  - chrismorgan 5y ago
    I’m really not sure what you’re trying to say here. 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 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.
mileza 5y ago
> 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. 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.
rob_c 5y ago
Well said
- rob_c 5y ago
  Such a polite community with opinions...
paradite 5y ago
I'm a senior frontend engineer and I would absolute use this question in my future interviews. 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.
underwater 5y ago
The interview is looking for one very specific type of engineer: a frontend specialist with demonstrated experience with a broad range of web technologies. 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.
it_does_follow 5y ago
I haven't done or even really touched front end work in a decade and I believe that this would have been an interesting interview. 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.
firecall 5y ago
None of that is 'esoteric knowledge' knowledge! 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 :-)

chrismarlow9 5y ago

Yeah I'd only ask that question if I was interviewing people to work at w3.org. 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".

tinco 5y ago

I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not a senior frontend web developer. He's not asking you to recite them from the top of your head, he's asking you to have a simple conversation about them. 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.

joshstrange 5y ago
> I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not 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.
- jenscow 5y ago
  This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, according to your job title, at least vaguely familiar with. 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.
  - gunapologist99 5y ago
    > 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.

jollybean 5y ago

It's not 'useless' and it doesn't scream 'knowledge signalling' - it's just not a very good question.

zitterbewegung 5y ago

IMHO instead of doing fancy tricks the first day for interviewing take something that could be completed in one day at the job you are interviewing for and if you can complete it or get it near enough I would think that would be a better criterion to hire. Also, this interview would be paid for the first day at the same rate that you would be hired for.

smaddox 5y ago
Wait... completed in one day? So an ~8 hour task? That's way too much of an ask for an interview, in my opinion.
withinboredom 5y ago
Not everyone does well in a high stakes environment, which is what this sounds like it would create.

forty 5y ago

It's not a very good question and it's not a very good answer either. Discussing the DOCTYPE without mentioning SGML or XML seems to be a bit weird to me.

rjh29 5y ago
That was more relevant 10 years ago. Nowadays the primary point of the html doctype declaration is to say 'I am HTML5'. I know this and I'm not even a frontend developer.
- forty 5y ago
  Agreed it's not too relevant, but if you are going to ask a knowledge question, rather that a skill question, you might as well expect some theoritical knowledge :)

ASalazarMX 5y ago

I'll gladly admit that creating boilerplate from memory is a low-value skill, but you absolutely must know why it is there, and what does it do. 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.

withinboredom 5y ago
Their answer should include googling the latest accepted specification if they’re going to be making changes or creating new ones from scratch. If their answer is to go to stack overflow, you might have a problem.
pythonaut_16 5y ago
How to change meta tags: 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.

tgsovlerkhgsel 5y ago

I think it's a very good question. You're not just checking boxes and giving a score here, and if the interviewer is any good, it's not just about "how many correct answers". 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"?

teaearlgraycold 5y ago
I agree. If this is judged by how many you can answer then the interview isn't useful. But if the interviewer uses it as a launching point from which the candidate can talk about their experience with web technologies then it's a great addition to a longer interview.

rapind 5y ago

You’re not going to convince a technical hiring manager that their puzzles are demeaning or pointless. They believe they’ve beaten some sort of game. That they post / blog about it just reinforces this. 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.

n8cpdx 5y ago

jfc I work full time on .NET desktop and even I know this. This is fizzbuzz. 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.

plandis 5y ago
I lead a team running very large scale distributed systems with almost a decade of experience and I could take a guess about what these elements and attributes mean but I don’t claim to fully know them. 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.
- mileza 5y ago
  You missed the entire point of the article. The point is now to know whether you know those 10 lines by heart, it's whether you can have a discussion starting from just this. 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.
  - deleted 5y ago
    [deleted]
  - plandis 5y ago
    I’m responding to someone who claimed this is a good fizzbuzz test which is different than the point of the article.
- n8cpdx 5y ago
  Could you not also Google the answer to fizzbuzz in 15-30 minutes?

karaterobot 5y ago

> I'd end the interview and move on 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.

oldstrangers 5y ago

A lot of these things are also automated from whatever framework, CMS or plugins you're using. It's the kind of thing you usually aren't writing in by hand, and shouldn't need to. 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.

whakim 5y ago

> I write that line 1 time max in a project and then never think about it again. 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.

draw_down 5y ago

deleted 5y ago

[deleted]

afavour 5y ago

Very surprised to see this as the most upvoted answer. Stuff like doctype is HTML 101. “A framework is going to output this for you anyway” sets alarm bells ringing in my head, it shows that you don’t actually understand the underlying technology and you use frameworks as a crutch. 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.

ipnon 5y ago
It's pedantic. Firefox parses the doctype from the document itself,[a] and no one is using Netscape anymore anyway. Any web engineer could learn all of this in an hour if need be. If they don't know it already it's because it is simply miscellania tangential to building web applications today. [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>`.
- chrismorgan 5y ago
  I’m really not sure what you’re trying to say here. 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 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.

mileza 5y ago

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

rob_c 5y ago

Well said

rob_c 5y ago
Such a polite community with opinions...

paradite 5y ago

I'm a senior frontend engineer and I would absolute use this question in my future interviews. 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.

underwater 5y ago

The interview is looking for one very specific type of engineer: a frontend specialist with demonstrated experience with a broad range of web technologies. 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.

it_does_follow 5y ago

I haven't done or even really touched front end work in a decade and I believe that this would have been an interesting interview. 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.

firecall 5y ago

None of that is 'esoteric knowledge' knowledge! 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 :-)