https://css-tricks.com/explain-the-first-10-lines-of-twitter-source-code/ Skip to main content CSS-Tricks * Articles * Videos * Almanac * Newsletter * Guides * Books Search view source Explain the First 10 Lines of Twitter's Source Code to Me Avatar of Anand ChowdharyAvatar of Anand Chowdhary Anand Chowdhary on Feb 24, 2022 Take your JavaScript to the next level at Frontend Masters. For the past few weeks, I've been hiring for a senior full-stack JavaScript engineer at my rental furniture company, Pabio. Since we're a remote team, we conduct our interviews on Zoom, and I've observed that some developers are not great at live-coding or whiteboard interviews, even if they're good at the job. 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: "Explain the first ten or so lines of the Twitter source code to me." I think it's a simple test that tells me a lot about the depth of fundamental front-end knowledge they have, and this article lists the best answers. For context, I share my screen, open Twitter.com and click View source. Then I ask them to go line-by-line to help me understand the HTML, and they can say as much or as little as they like. I also zoom in to make the text more legible, so you don't see the full line but you get an idea. Here's what it looks like: Screenshot of source code from Twitter.Screenshot of source code from Twitter. 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. Line 1: 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. I still remember my Dreamweaver days with the long XHTML DOCTYPE line, like Chris listed in his article "The Common DOCTYPES" from 2009. Perfect answer: This is the document type (doc-type) declaration that we always put as the first line in HTML files. 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. 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 was standardized in HTML5 and still lives on. Also accepted: This is the DOCTYPE tag to let the browser know that this is an HTML5 page and should be rendered as such. Line 2: This line in the source code tells me if the candidate knows about accessibility and localization. Surprisingly, only a few people knew about the dir attribute in my interviews, but it's a great segue into a discussion about screen readers. Almost everyone was able to figure out the lang="en" attribute, even if they hadn't used it before. Perfect answer: This is the root element of an HTML document and all other elements are inside this one. Here, it has two attributes, direction and language. The direction attribute has the value left-to-right to tell user agents which direction the content is in; other values are right-to-left for languages like Arabic, or just auto which leaves it to the browser to figure out. The language attribute tells us that all content inside this tag is in English; you can set this value to any language tag, even to differentiate en-us and en-gb, for example. This is also useful for screen readers to know which language to announce in. Line 3: Perfect answer: The meta tag in the source code is for supplying metadata about this document. The character set (char-set) attribute tells the browser which character encoding to use, and Twitter uses the standard UTF-8 encoding. UTF-8 is great because it has many character points so you can use all sorts of symbols and emoji in your source code. It's important to put this tag near the beginning of your code so the browser hasn't already started parsing too much text when it comes across this line; I think the rule is to put it in the first kilobyte of the document, but I'd say the best practice is to put it right at the top of . As a side note, it looks like Twitter omits the tag for performance reasons (less code to load), but I still like to make it explicit as it's a clear home for all metadata, styles, etc. Line 4: ...tells browsers that users can add Twitter as a search engine. ...has many interesting attributes that can be discussed, especially nonce. ...for international landing pages. :focus:not([data-focusvisible-polyfill]){outline: none;} ...for removing the focus outline when not using keyboard navigation (the CSS :focus-visible selector is polyfilled here). Our Learning Partner Frontend Masters logo Frontend Masters Need front-end development training? Frontend Masters is the best place to get it. They have courses on all the most important front-end technologies, from React to CSS, from Vue to D3, and beyond with Node.js and Full Stack. Frontend Masters logo Need front-end development training? Frontend Masters is the best place to get it. They have courses on all the most important front-end technologies, from React to CSS, from Vue to D3, and beyond with Node.js and Full Stack. Comments 1. Shir G. Permalink to comment# February 24, 2022 Sorry, but I will never hire someone who KNOWS to explain the first 10 lines. I prefer humans. I prefer workers that focus on what's important, knows how to learn new stuff themselves. Reply + Anand Chowdhary Permalink to comment# February 24, 2022 Totally respect your opinion! In my mind, "focusing on what's important" definitely means understanding what you're doing and not merely copy-pasting stuff. I'd argue that almost everyone has come across the doctype, charset, viewport, etc., tags when doing web development, so not being able to explain them is a red flag for me. This is why I think this quick quiz is a good proxy into someone's knowledge. :) + David Mulder Permalink to comment# February 24, 2022 But this is all pretty common stuff, I didn't study this to know it, I know these things because I have used them (except origin trials, but even those I am familiar with). These are things a senior web application developer should have encountered at some point and be capable of having a decent conversation about. Only criticism I would have is exactly that: application developers, not web site developers. These are things that web application developers are familiar with (except open graphs maybe, which was the only one I wouldn't have been able to give a perfect answer for). If I would be hiring for a fancy cross platform SPA web application I could imagine using this approach. Anything simpler than that and I would fear that those who would do well on the question are not those who will be happy with the position I could give them. + scott Permalink to comment# February 25, 2022 Yeah, I have a hard time understanding why most of this would matter in an interview- it'll all mostly be boilerplate handled by modern development frameworks. It's the sort of thing that one developer on your project might have to look up once, but everyone else is going to be more concerned with feature implementation. I mean, I have have several years experience as an Angular developer and I'd probably bomb this interview... + Anand Chowdhary Permalink to comment# February 25, 2022 @scott, you're right, if you bomb this interview after several years as an Angular developer, I probably wouldn't hire you (here's why!). When you say that most frameworks handle boilerplate, I understand where you're coming from; it's easy and makes us fast and efficient. But to me, it's very important to understand what the frameworks do. In fact, one of the questions in the interview is "How would you re-implement React from scratch", and it's to make candidates think about the how concepts like the virtual DOM and state updates work. For me, not knowing this is a deal breaker. I think as we scale and have much more specialized people on the job, it may make sense to hire you, i.e., someone who's probably very very good at Angular but probably not "the web in general" (not judging, please let me know if you disagree!) but since we're super early stage, 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. 2. Rs Permalink to comment# February 24, 2022 I'm thrown here by how the inline css just begins without a tag surrounding it. Have people mentioned this before? Reply + Chris Coyier Permalink to comment# February 24, 2022 The opening