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:
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: <!DOCTYPE html>
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 <!doctype html> 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: <html dir="ltr" lang="en">
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: <meta charset="utf-8">
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 <head>.
As a side note, it looks like Twitter omits the <head> 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: <meta name="viewport" content="width=device-...
Perfect answer: This meta tag in the source code is for properly sizing the webpage on small screens, like smartphones. If you remember the original iPhone keynote, Steve Jobs showed the entire New York Times website on that tiny 4.5-inch screen; back then it was an amazing feature that you had to pinch to zoom to actually be able to read.
Now that websites are responsive by design, width=device-width tells the browser to use 100% of the device’s width as the viewport so there’s no horizontal scrolling, but you can even specify specific pixel values for width. The standard best practice is to set the initial scale to 1 and the width to device-width so people can still zoom around if they wish.
The screenshot of the source code doesn’t show these values but it’s good to know: Twitter also applies user-scalable=0 which, as the name suggests, disables the ability to zoom. This is not good for accessibility but makes the webpage feel more like a native app. It also sets maximum-scale=1 for the same reason (you can use minimum and maximum scale to clamp the zoom-ablity between these values). In general, setting the full width and initial scale is enough.
Line 5: <meta property="og:site_name" content="Twitt...
About 50% of all candidates knew about Open Graph tags, and a good answer to this question shows that they know about SEO.
Perfect answer: This tag is an Open Graph (OG) meta tag for the site name, Twitter. The Open Graph protocol was made by Facebook to make it easier to unfurl links and show their previews in a nice card layout; developers can add all sorts of authorship details and cover images for fancy sharing. In fact, these days it’s even common to auto-generate the open graph image using something like Puppeteer. (CSS-Tricks uses a WordPress plugin that does it.)
Another interesting side note is that meta tags usually have the name attribute, but OG uses the non-standard property attribute. I guess that’s just Facebook being Facebook? The title, URL, and description Open Graph tags are kinda redundant because we already have regular meta tags for these, but people add them just to be safe. Most sites these days use a combination of Open Graph and other metatags and the content on a page to generate rich previews.
Line 6: <meta name="apple-mobile-web-app-title" cont...
Most candidates didn’t know about this one, but experienced developers can talk about how to optimize a website for Apple devices, like apple-touch-icons and Safari pinned tab SVGs.
Perfect answer: You can pin a website on an iPhone’s homescreen to make it feel like a native app. Safari doesn’t support progressive web apps and you can’t really use other browser engines on iOS, so you don’t really have other options if you want that native-like experience, which Twitter, of course, likes. So they add this to tell Safari that the title of this app is Twitter. The next line is similar and controls how the status bar should look like when the app has launched.
Line 8: <meta name="theme-color" content="#ffffff"...
Perfect answer: 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. Chrome on Android and Brave on desktop both do a pretty good job with that. You can put any CSS color in the content, and can even use the media attribute to only show this color for a specific media query like, for example, to support a dark theme. You can also define this and additional properties in the web app manifest.
Line 9: <meta http-equiv="origin-trial" content="...
Nobody I interviewed knew about this one. I would assume that you’d know this only if you have in-depth knowledge about all the new things that are happening on the standards track.
Perfect answer: Origin trials let us use new and experimental features on our site and the feedback is tracked by the user agent and reported to the web standards community without users having to opt-in to a feature flag. For example, Edge has an origin trial for dual-screen and foldable device primitives, which is pretty cool as you can make interesting layouts based on whether a foldable phone is opened or closed.
Also accepted: I don’t know about this one.
Line 10: html{-ms-text-size-adjust:100%;-webkit-text...
Almost nobody knew about this one too; only if you know about CSS edge cases and optimizations, you’d be able to figure this line out.
Perfect answer: Imagine that you don’t have a mobile responsive site and you open it on a small screen, so the browser might resize the text to make it bigger so it’s easier to read. The CSS text-size-adjust property can either disable this feature with the value none or specify a percentage up to which the browser is allowed to make the text bigger.
In this case, Twitter says the maximum is 100%, so the text should be no bigger than the actual size; they just do that because their site is already responsive and they don’t want to risk a browser breaking the layout with a larger font size. This is applied to the root HTML tag so it applies to everything inside it. Since this is an experimental CSS property, vendor prefixes are required. Also, there’s a missing <style> before this CSS, but I’m guessing that’s minified in the previous line and we don’t see it.
Also accepted: I don’t know about this property in specific but the -ms and -webkit- are vendor prefixes needed by Internet Explorer and WebKit-based browsers, respectively, for non-standard properties. We used to require these prefixes when CSS3 came out, but as properties go from experimental to stable or are adopted to a standards track, these prefixes go away in favor of a standardized property.
Bonus — Line 11: body{margin:0;}
This line from Twitter’s source code is particularly fun because you can follow-up with a question about the difference between resetting and normalizing a webpage. Almost everyone knew a version of the right answer.
Perfect answer: Because different browsers have different default styles (user agent stylesheet), you want to overwrite them by resetting properties so your site looks the same across devices. In this case, Twitter is telling the browser to remove the body tag’s default margin. This is just to reduce browser inconsistencies, but I prefer normalizing the styles instead of resetting them, i.e., applying the same defaults across browsers rather than removing them altogether. People even used to use * { margin: 0 } which is totally overkill and not great for performance, but now it’s common to import something like normalize.css or reset.css (or even something newer) and start from there.
More lines!
I always enjoy playing with the browser Inspector tool to see how sites are made, which is how I came up with this idea. Even though I consider myself sort of an expert on semantic HTML, I learn something new every time I do this exercise.
Since Twitter is mostly a client-side React app, there’s only a few dozen lines in the source code. Even with that, there’s so much to learn! There are a few more interesting lines in the Twitter source code that I leave as an exercise for you, the reader. How many of them could you explain in an interview?
<link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="Twitter">…tells browsers that users can add Twitter as a search engine.
<link rel="preload" as="script" crossorigin="anonymous" href="https://abs.twimg.com/responsive-web/client-web/polyfills.cad508b5.js" nonce="MGUyZTIyN2ItMDM1ZC00MzE5LWE2YmMtYTU5NTg2MDU0OTM1" />…has many interesting attributes that can be discussed, especially nonce.
<link rel="alternate" hreflang="x-default" href="https://twitter.com/" />…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).
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.
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. :)
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.
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…
@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.
I’m with you, @anand.
1) This stuff is not wildly complex and should be known by anyone who’s working with the DOM.
2) If someone doesn’t know a component, at least they know now that the expectation is that they understand how everything fits together, at least at a high level.
Now I have to go learn what nonce is…
I’m thrown here by how the inline css just begins without a tag surrounding it. Have people mentioned this before?
The opening
<style>is just off-screen, but it’s there at the end of the previous line.Ya that’s new to me too. Plus omitting the head tag altogether.
Yep, Chris is right — it’s zoomed in so it’s at the end of the previous line. I wrote:
Not to mention, no
<head>, or is it not required by the spec as I thought?Some top- or block-level HTML elements have optional end-tags because they have unambiguous rules about where they go and/or what they can contain: html, head, body, p, dt, dd, li, option, thead, th, tbody, tr, td, tfoot and colgroup. And html, head and body have an optional start tag as well because again their position and contents are unambigious.
https://html.spec.whatwg.org/multipage/syntax.html#optional-tags
There’s no way you knew the ‘perfect answers’ for everything yourself without researching. And if you did, and you have perfect knowledge, why don’t you just do the job yourself?
Maybe because two (or more) people can do more work than just one, and everyone gets a day off eventually?
Hi Emmy, absolutely I had to research to write this article :)
But to be honest, I would rate myself 8/10 because I’d be able to answer all of these myself pretty decently from memory, since I’ve been writing HTML for 10+ years and have become pretty deep into this! Of course, I don’t have “perfect knowledge” and I would have failed this test in any other field!
As to why I won’t do the job myself, I think most people hire for two reasons: (i) you need someone who can do things you can’t, or (ii) you don’t have enough hours in the day so you need more hands. At the current stage in my company, we’re at (ii) so the primary motivation to hire is that I have many things to do as a founder, and the business needs someone dedicated to writing code every day. :)
I’m just a web dev myself, but I’m super surprised by the reactions here. I’d expect every web dev I hire (at least front enders)what these lines mean. I don’t understand how you can not and still claim to know your job.
We can never know that someone is perfect. We only use this with respect to what we know ☺️.
I understand that this a way as good as any to select candidates, but I don’t think this is going to tell you much about a candidate.
Some of this are rather obscure pieces of knowledge, not saying they are worthless (they are important) but how this is going to tell you if someone knows how to work with promises? Or how to to lazy load an image? Or how to make a responsive grid? Or what aria role to use to get an accessible customized drop-down? Or if that candidate is capable of turning a mockup into an actual page?
I’ve worked of web development for more than 12 years, in several companies, countries and projects and I’ve probably written those lines maybe once or twice. If I would have to write them I would just Google them, I know what they are but I would not remember them on the spot.
I agree 100%! As I wrote in the article, “…I ask them questions about web vitals, accessibility, the browser wars, and other similar topics about the web.”
This “Twitter quiz” takes about 10 minutes in a 60-minute interview call, and the other 50 minutes are Q&A about these other topics. In fact, I ask specific questions on two topics you mentioned — instead of lazy loading an image, I ask about designing a responsive image component; and instead of aria for dropdowns, I ask about aria for notifications.
This is just a small part of the entire process, but to me it provides a lot of information in a short amount of time. I don’t expect people to remember all of them on the spot, but not knowing any of them but having copy-pasted them in the past is sort-of a red flag for me because you should know the “why” behind what you’re doing.
Spot on. This feels like a softer version of whiteboarding, but still shows what’s wrong with hiring in the tech industry
@ShirG I think you may have missed the point?
Someone who is able to explain these items would be someone who has demonstrated they do “learn stuff themselves” as these items aren’t standard knowledge to all, and would require deeper research. It most certainly separates juniors from mid / senior candidates.
Asking someone for a conversation about their technical knowledge, instead of putting them through live coding challenges is ultimately more human imo.
OP didn’t say they should KNOW to explain the lines, merely having a conversation to see if they understand what is infront of them in a human friendly way.
@ShirG out of curiosity, are you in a management position? How do you conduct your interviews. Would be great to hear your thoughts and the company you hire for?
Thanks Aaron, the intention was indeed to showcase deeper knowledge without having to do a live coding challenge.
You’re also right that candidates are not expected to know each line, but have a conversation which usually leads to interesting questions, e.g., I always go to the difference between normalizing and resetting in CSS after the “margin: 0” line.
And interestingly — the engineer we ended up hiring had a decent answer for all lines except for
http-equiv="origin-trial", but of course that’s not the only reason we’d hire someone (this is just a small part of the full process).Agree with the author as most of these are quite basic and essential, especially with new things emerging rapidly web Devs are expected to know the new tags for instance the add to home screen configurations. Especially this one as almost everyone has experienced some formats of add to home screen or install as an app notifications no matter which browser are used. It is necessary to keep learning new things in all domains not only web. Smart and unlazy guys will be able to answer some of the top 10. Presumably the author was not expecting all of them to be understood by interviewees.
Surprised to see all the pushback here. As someone who has been both a hirer and a hiree in this space I think this is fantastic.
#9 – Acceptable Answer:
This is an OG reference to where computers all began… On the Oregon Trail.
Can we stop calling HTML and CSS coding? It is markup and styling. No programming language, next thing would be json developer .
How you test with this seniority? honestly this is 100% specific question and ppl who didn’t worked with this will have 0 correct answers, or start do a guessing game. I would expect a junior to know more about this that a senior developer, because knowing only to code like a guru, makes you not a senior developer.
I don’t think I used the word “coding” anywhere, but writing markup and styling is, by definition, coding. HTML may indeed not fit into the traditional definition of “programming language”, I think the way you’re phrasing it is essentially gatekeeping. I think it doesn’t matter if HTML or CSS are classified as programming languages or not (https://css-tricks.com/html-is-not-a-programming-language/).
As to your second point, I agree that these are very specific to the role, but that’s the point — I wanted to hire full-stack developers who will be writing HTML and CSS (along with JavaScript), so this is necessary knowledge for them.
Looks like a good idea for the technical part of an interview, even if this could take from 10 minutes to 4 hours.
Just explaining what a doctype or a charset is (so that people don’t get those funky question marks in DB records) can lead to a very long answer.
In the last interview I did, ages ago, they asked me to implement a copy of the Google calculator in javascript.
Makes sense! We usually take about 10 minutes for this part of the interview, because I can point candidates in the right direction if they’re unsure of the answer, and I can very quickly tell if they do indeed know the answer, so I don’t require them to speak for very long about each topic.
Unless I missed something in the article, I’m assuming none of the candidates pointed out that Twitter are making use of
headtag omission, which while a totally valid practice given that certain conditions are met, is also remarkable enough that I would certainly point this out if being quizzed on the source lines presentedYou missed this :)
curious to know why you would care that someone knows this piece of historical information that has little relevance today, except as a trivia question:
“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. ”
PS- not challenging you, just want to hear your thinking on it.
I’ve been writing HTML for 10+ years, back when we wrote (much) more than <!doctype html> as the first line. I’ve really come to appreciate how we got here, hence the focus on the history. I don’t think it’s necessary to know all the history behind this line, but knowing it tells me that you’re either very curious or very experienced.
Excellent article. But I think the reason you might be having trouble hiring for your position is that you label it as Senior Full-Stack JavaScript Engineer.
This question/discussion would weed out a lot of people who use JavaScript to write Node since this question is all front-end based. If you change the hiring title to Senior Front-End Engineer, I would guess you get better candidates who align with the skillset you are looking for.
Agreed!
So your test to see if someone would be a good full-stack javascript developer is to let him explain 10 lines of which non is javascript?
That’s exactly right ;)
Jokes apart, this is one of the questions that we talk about for ten minutes (from an hour-long call), the others being more specific to the role (e.g., designing a component in a frontend framework, designing a RESTful API in Node, accessibility, etc.). I think a full-stack JS developer should still know enough HTML to answer these questions!
I mean, those JS codes will be interacting and mutating HTML & CSS codes anyway. Is it good if you’re fluent in JS but can’t make sure your code does the right thing to the DOM, or can’t make sure it outputs the right SEO tags?
Even though some meta tags included at this test sounds vintage, with bonus I’m about to get 100 points out of 100
Haha hired! ;)
A lot of these comments are, I think, missing the point. I think the author is trying to get “under the skin” of the candidate, to have a conversation to see if the person fits. When I’ve interviewed in the past I used to prefer a conversation and looked (in order) for
1. Aptitude (does the candidate “get” software development). If you can’t program then I don’t want you; I don’t have the time to teach this to you.
Attitude. Are they keen, competent; the “right stuff”. If someone is lazy I don’t want them. I’m looking for passion, interest in more than churning out more crap for a pay cheque. I want to know what interests them.
Knowledge. Technical Knowledge can be easily learned from Google or a book so it really is bottom of the list. I’m looking for a long term relationship (time to train), not a short term fling!
This is a really nice post, and as a Senior Frontend Engineer myself, I’m glad that I can pull some of those answers out of my head!
However, I think the perfect answer for those shouldn’t be as detailed as the examples you’ve mentioned. Part of the development process includes searching, reading, and not necessarily copy-pasting, but actually understanding how things work, and even if you haven’t memorized it, you can still guarantee quality and scalability through such a process. However, I really like the idea of asking candidates to explain those 10 lines of code. Definitely something that ends up being discussion-worthy material for interviews!
Hey Anand.. Your answer for doctype is a little incomplete.
In the Netscape/IE days, there was SO MUCH browser behavior that was unspecified. So there wasn’t a question of “which HTML standard to use”, but instead a problem of “the HTML spec doesn’t cover this”. That plus the two camps were innovating ahead of standardizing, which led to all sorts of differences. The doctype served as a mechanism to say “I want the strictest browser behavior” rather than “give me compatibility mode”. (That plus it was useful for that whole XHTML fad ;)
The ‘compatibility mode’ was codified as quirks mode and eventually that, too, was standardized: https://quirks.spec.whatwg.org/ That means browsers not only tightened up their ‘standard’ behavior, but in the past decade they’ve also done a bunch of work to be consistent in quirks mode. No longer is it a wild west of unpredictable behavior, but it’s a nice list of ~13 little “bugs” that we’ve kept in the web platform (primarily so that pages created in the 90s still render the same).
Anyhow, I’d say the perfect answer is: “The doctype declaration ensures we don’t get quirks mode behavior” or ~”avoids weird bugs”.
I can tell you confidently that if Chris removed the doctype within Codepen for a day, we’d have thousands of people scratching their heads for hours because this ‘just doesn’t make any sense’. It’s a very painful omission. :)
Also, for the HTML nerds… if the quirks mode spec isn’t enough for you, enjoy this masterpiece: https://hsivonen.fi/doctype/
Beautiful. As always, thanks Paul for sharing the knowledge!
Very nicely written, I’ve learned so much man. Thanks!
The
lang="en"is by far the most important thing in all the code, and is barely addressed in your perfect answer. You’re not hired! :)The property attribute is from the RDFa Core 1.1 spec. The “og” part is a prefix, used to not repeat a longer URI representing the full value. If a parent element (html in this case) declared the “og” prefix then the parser could map og:site_name to the full URI.
A parser sees the property with the prefix, knows it can’t map to a reference URI, and these days just assumes it’s an Open Graph protocol value used primarily by Facebook.
https://ogp.me/
https://www.w3.org/TR/rdfa-core/#h-s_curies
I really think this post is very well written. I think that this interview test is very relative. It isn’t just a test on how well the candidate knows how to write Html. As someone who has been writing html for 8+ years, the interviewer would gather more information about me than just my ability to write html.
For example, some of these tags have been around since the beginning and some are relatively new – if I’m able to explain both – this shows that, 1. I have as much experience as I claim to have and 2. I make a point of always improving or ‘updating’ the knowledge that I claim to have.
Another example is if I noticed there is no head tag but was unable to explain WHY, the interviewer would be able to tell if I just copy and paste from the net or if I am intrigued by WHY there is no head tag. Which would show how interested or ‘driven’ I am in learning and understanding more.
This is pretty good, Anand. Very satisfying to read.
I wonder- Some people can list out web standards one by one and can speak to each one and maybe even some history and the current state of browser support for each feature, even if it’s uncommon or deprecated.
For example, the ommited head tag on Twitter. It’s uncommon, but is nothing to write home about. The behavior in this case is well documented and there will be cross browser consistency. It’s not an unknown. It’s just uncommon.
People who can do that will be very quick to solve a new problem because they know why previous solutions are used, why some features aren’t used, and rather than using boilerplate or just copying what they see they can write it from scratch each time.
Now you have the flip side. There are people that don’t store the information this way. They have the importance of each feature scaled proportially in their mind – in proportion to their familiarity and the statistic rate of encountering it so far in the wild.
This makes them very good at making a website with all of the common features but they don’t exactly always know why it’s being done and things stand out to them for different reasons. Like the ommited head tag – even though omitting the head tag is no different to having it there (except for a handful of saved characters) but it just might surprise people. Because they always see the head tag they might (mistakenly) conclude only sloppy people omit tags because all the pro sites have a head tag. They may trip on features outside the bell curve of common knowledge and even if the standards are very clear about how those features are treated, they may have very strange underlying theories about why they see x more than y.
Eventually I think everybody progresses from the statistical approach to the mastery approach where they can list out the features etc. And this article shows a great way two find out which side of that journey your candidate is closer to
DOCTYPE is not necessary, meta charset is not necessary, how do I know this? Because I’ve built pages without needing to use them. If I ran into a situation where I needed to use them I would simply look it up, and learn how to use it. “copy pasting code” – So you’re telling me you’d rather have someone that’s memorized a bunch of obscure information rather than someone that knows how to put things together? This kind of mentality shouldn’t really be tolerated in any space. You seem to be claiming to be more “human” or accommodating by using this approach, but this isn’t so at all – Whether they are competent matters not to you, you just care about what they’ve memorized. They’re like walking boxes of knowledge to you, and if they happen to not know this specific information, they’re useless to you.
Really dreadful read. I couldn’t even read the “perfect answer” segments, because they were so romantic and idealist that whoever wrote it must’ve come straight out of fairy-land. Should’ve just explained them like a normal person.
Whoa! That’s quite the take on an article that starts off with:
But I guess that’s part of the “dreadful” stuff that isn’t worth reading, eh?
The joke here is minification always puts an entirety of code in a single line, so explaining 10 lines means explaining the entirety of javasript and css of the whole site.
He is pretty lucky twitter doesn’t minify its html templates.
All of this reads… off.
Most of your perfect answers raise more questions than they answer. Answers which would be fascinating to read about in an article precisely like this one.
Take for example #3.
You would expect anyone senior in anything related to computers to surmise or know the meaning of “meta”, “charset” and “utf-8”. But what about alternatives to utf-8? What’s the difference between utf-8 and unicode? What if the page uses a different, absurdly obscure encoding? How does the browser know how to decode the tag that tells it the encoding without already knowing the encoding? Could that mean the charset only governs the encoding of user-readable plain text, or user readable and attribute values, but not html tags and attributes, which need to be in a set encoding? Can you mix encodings in a document? What happens if it’s omitted, like what can break?/What problem does it solve?
So many interesting things to explore. Meanwhile the answer you provide is bland and uninformative. Ironically the “perfect answer” to your own question makes it seem like you’re bumbling your way through your own interview. Were I the interviewer, I’d consider that answer a fail. But even if the candidate didn’t know anything, starting down the line of questions above would show that they know how to break down problems and seek knowledge and follow a thread of logic – you know, problem solve, which is what any engineering task is.
You’re absolutely right, the point of this exercise it to start from the question and head to the discussion. All of your questions for #3 are very similar to the questions I ask during the discussion… perhaps I did a poor job explaining, but the idea is precisely this — start from the line and discuss followups. The “perfect answers” are really the keywords I look for as a proxy for whether they’re on the right track.
As others have said, you are asking things that devs who are capable of crafting all aspects of a web app will only need to deal with occasionally and can easily google if/when they do need to.
At the same time as holding this level of detailed knowledge up as essential, you show some evidence of missing the big picture – you know why I think twitter leaves off the html tag? Probably just an omission, a mistake. It certainly has no real-world influence on site performance (if anything it will be mildly negative and is certainly a hostage to fortune as regards any future browsers that may, quite reasonably, be designed to rely on there being an opening head tag). Lastly, Twitter’s user interface really is one of the worst I know of, so I wouldn’t look to their site as a model for anything.
I learned quite a lot from this article. Thanks for sharing. I gotta say I still don’t understand the
http-equivproperty even after you explained it. HahahaIt’s basic info that everyone should know who does web dev. However it’s sometimes not so easy in an interview when your head goes blank.
As others have stated there are numerous and complex ways to answer these questions. As for Paul Irish and quirks mode, I was working as a web dev in 2001 when NN4 was still a browser with a decent usage.
Many people might over rely on copy and paste or frameworks and I agree having no in-depth knowledge isn’t particularly encouraging.
One other point is this, some people have the time to read and learn loads, for others time is constrained with family responsibilities and even caring after work for a loved one or family member.
What you are looking for is someone with a passion for this, someone who learns this as a hobby too, not just for work.
It’s also slightly unfair on those who have not bothered to read and learn about stuff they rarely write due to frameworks but are experts in other specific areas, maybe database design, UI/UX, PHP or Python.
I would be asking questioning about using webp on the terminal and automating bash scripts etc plus understanding Lighthouse etc