Explain the first 10 lines of Twitter's source code to me

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

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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

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.

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?

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.

And remembering the Netscape days and why of each meta “hacks” might be a little tricky even for very senior profiles.

(On the other hand, if the candidate had access to a computer, following their process of looking these up might be interesting...).

I prefer take homes to live coding questions but ffs, ask me questions that will pertain to my day to day responsibilities and have me explain my code sample. No FE dev in 2022 is creating a bunch of HTML pages.

Trivia quizzes like this will get you people who know the trivia, which is probably better than hiring completely at random but not necessarily the best strategy.

Those too are “conversations” that are testing someone’s ability and knowledge.

YMMV

The reason you have CSS style tags at the top is because it is an optimization technique for having critical CSS added to the <head> tag to ensure that styles of top of the page are rendered immediately (so no flash of content). I can bet anything that "-ms-text-size-adjust" is not something any Twitter Frontend Developer would be aware of unless they are building the tooling for the Frontend. This actually comes from normalize.css which every Frontend developer just blindly imports: https://necolas.github.io/normalize.css/8.0.1/normalize.css

This normalize.css is critical style as it resets the browser styles. Hence it is added above the fold (in the <head> tag) to ensure that the initial page load won't have any flash of content.

Honestly, this is a very bad way of judging Frontend Developers. My biggest critique of hiring process for Frontend Developers is precisely this. Either interviewers ask questions related to solving data structures and algorithms (which honestly you never use in majority Frontend Development anyways) or such esoteric questions that won't be useful anywhere else except for clearing the interview process.

Want to hire a Frontend Developer? Just ask them to code a sample project: possibly a Todo list. And focus more on how they organize code, how they structure components, what libraries they choose, how they test the components, are they aware of the latest standards (are they still using React createClass or using functional components with hooks)?. This is the only correct way to judge a candidate for the position of Frontend Development. For Senior Frontend Development roles, you can ask them about how they would work with tooling that connects with the backend. Probably give them a GraphQL endpoint and see how they approach it. Do they use a mock adaptor? How do they integrate Authentication? How do they put guards around pages and how do they handle role management within the app? How do they handle internationalization? Would they resort to by default picking Redux (just because it is popular) or is there a better alternative for the specific project/task at hand? These are much much better questions that gauge the experience of the Developer.

All these other methods of interviewing are basically admitting that you have no idea of how to filter correct candidates or you want to show off your esoteric skills. This also sends a very wrong message to the Frontend Developer community that the requirement to get a job is to learn all these hidden features and edge cases. It will sidetrack them from becoming the best at their job as they spend countless hours read/learning things that in no way contribute to business outcome.

Honestly, seeing all this, I have a strong urge to do something about the hiring process. Maybe a startup along these lines. The hiring scene in Frontend Development sucks.

---

<!DOCTYPE html> is a magic string that indicates the document should be parsed as an HTML5 document (possibly avoiding quirks mode too? I don't remember what triggers that).

"Doctype" comes from the XML concept, and XHTML documents may have a different doctype.

<html> is the document's root element. It's supposed to be there but the browser will create it if you leave it off.

ltr means the document direction is left to right. direction here refers to the direction of lines (e.g. in English lines go left to right, in Arabic lines go right to left). There's another value that influences writing mode too below the document level, but I forget what it's called.

Browser implementers and webmasters have to be careful with a non RTL direction; as it changes the scrolling element origin, the browser will have to deal with logical vs physical coordinates, and scrollX may go negative. I believe scrollX was reconciled across the different browsers fairly recently.

The meta tags tell you metadata about the document. I believe they're supposed to go in the head section, but again the browser will create that for you if you don't.

lang just tells you the language of the page. I'm not familiar with what this is used for, but you could imagine a search engine using it for one thing (e.g. Google's "display only results in English").

The two letter country code comes from some standard I don't remember the name of. Also used in TLDs. Watch out for easy to confuse countries like cn, ca. Some websites like to use the trendy .io TLD, but I heard rumors it wasn't run very well.

charset="utf-8" means the document's bytes should be treated as unicode. Note that this meta tag should occur in the first 1024 bytes of the document or browsers may not notice it. Without specifying the charset the browser will likely fall back to... I think latin1?

Anyway I read once that browsers don't get too fancy with the encoding detection on purpose, to avoid people relying on unreliable heuristics.

Another interesting point is that Chrome can load utf-8 documents as utf-8 without a metatag if it's a file:// URL. I guess conceptually this is because local files can't specify the encoding in HTTP headers or something?

Viewport specifies the responsive sizing behavior. This is described in the CSS Device Adaptation Level 3 spec; but the section on actually parsing this tag is pretty gnarly. If I remember right it was a non-normative section and had a few weird corners that were likely left over from matching browser implementation quirks.

Anyway you need the viewport for responsive viewport sizing. 99% of the time you can just copy-paste the usual string and don't need to get fancy with custom values or anything. There's also a newer way to specify the viewport behavior through CSS (and indeed Chrome basically converts the meta tag to this internally), but it didn't really work right last time I tried it.

"og:" is from some semantic web standard. I never learned the details, but basically it tells crawlers some basic information about the page's contents.

For the remaining lines; presumably Safari recognize some custom meta tags to change Apple device theming. The "origin-trial" may refer to Chrome (or Safari?) origin-trials, where webpages can opt into (or sometimes out of) experimental browser behavior.

Line 10 is CSS. Presumably there was a <style> tag off the right end of the screenshot on line 9.

Interesting point about CSS or JS embedded in HTML:

This actually changes the parser's language from HTML parsing to CSS or JS parsing on the fly. But with a special rule to look for the end tag and switch back to HTML. This is why you'll see people break up the string "<script/>" if they have to embed it in JS embedded in HTML.

But my favorite is the <plaintext> tag which switches the parser to... plaintext. Unlike CSS or JS there is no special escape-hatch and it's just plaintext for the rest of the document.

Speaking of embedded languages: SVGs have a title element but it isn't the document's title element. Poorly written browsers or crawlers could confuse the SVG title with the document title if they don't have an understanding of tag namespaces (another relic from XML perhaps?!)

Renting furniture... Isn't it weird* how the right to own drives capitalism which spawns businesses that thrive on you not owning the things they sell you?

* read: perverse

Testing detailed arcane knowledge is one thing, and it should be impressive if people know everything.

But the web is a giant mess of technologies that nobody can really fully keep up with and I'd rather people spent that extra minute learning about another language or subject, than say the details of 'doctype'.

Oh, and I've interviewed hundreds of front end developers, so I've been on both sides of the table.