23 ms·

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

• adreamingsoul 5y ago
  having a conversation about HTML semantics and browser features is great, but is it really different than live coding or white-boarding? Those too are “conversations” that are testing someone’s ability and knowledge.
• new_guy 5y ago
  That seems a pretty basic question for a senior position, it's weird the author says most candidates failed it.
  • kache_ 5y ago
    My expectations for people cratered after I began interviewing. It's.. incredible.. how untechnical people applying for highly technical positions can be.
    • lghh 5y ago
      How is not knowing something unethical? [EDIT] - they said "untechnical", not unethical.
      • hknapp 5y ago
        un - technical
    • InvaderFizz 5y ago
      Agreed. It's sad how many SRE candidates are positioning themselves as senior and end up being someone with basically nothing more than surface level knowledge of AWS manages services. I have a relatively similar approach as the article: 1. I have them walk me through a production dockerfile and explain what is going on (it is not a very complex dockerfile). 2. I have them troubleshoot a broken web server with the most basic scenario (public web server that we run, ec2 with apache2, public ip, no load balancers, no cdn, just a VM serving a static html page on xyz.actualdomain.com). Things that are broken: 1. NXDOMAIN (I make sure to unset the DNS before the interview) 2. Security group isn't allowing 80/443 3. NACL isn't allowing egress 4. iptables isn't allowing 80/443 5. Apache2 is stopped 6. Apache2 is bound to 127.0.0.1:80/443 7. Self signed TLS I don't require specific incantations, I know I can't write the iptables insert without looking up an example. But I do expect candidates to know where and what to look for to troubleshoot the entire chain. They are allowed to run any command they want (I'm running it on a screen share). If they get stuck on a portion, they get some hints, then finally they get given the answer to get past it. My goal is not a gotcha, my goal is to see how they attack the problem and if they are at least familiar with how things can break and have guesses at fixes. Fully a third of interviewees get stuck on NXDOMAIN, which is just shocking to me interviewing people that, on paper, have over a decade of deep Linux and cloud experience. To me, the scenario I present is basic troubleshooting and something that should be a breeze for most candidates.
      • tylerchurch 5y ago
        While I too have seen strange knowledge gaps in interviews (interviews for JS developers who can't write a function that adds two numbers), the NXDOMAIN issue doesn't surprise me too much. Maybe it's different for SREs, but as a fullstack web developer, unless you've got a greenfield project, usually someone else sorted out DNS a long time ago. And unless you're working on something that changes DNS a ton, nobody has touched DNS in a long time. Additionally, I've seen NXDOMAIN way more often as a local machine configuration problem, rather than as a production environment DNS problem. So if I'm going in to debug a server, but then I see an NXDOMAIN, I could see myself getting stuck wondering just what else in the world is broken. If I was doing the test on my own hardware, I might panic that my machine is in a bad state. If I was doing the test on hardware the interviewer provided, I might start wondering if this is some kind of trick, and I have to debug a broken client and a broken server. Then again, maybe if I went back to those people who couldn't add two numbers in JS, they'd have a great explanation too :)
        • InvaderFizz 5y ago
          For SRE, DNS is a relatively common issue to troubleshoot. Something silently fails in a deploy, someone went mucking around with DNS by hand when they shouldn't have, your local resolver might just be borked. Specifically for us, since we are a SaaS provider with new customer environments in their own VPCs every week, DNS is something we touch regularly. We touch it waaay more by hand than we should, but that is one of many processes I am fixing and automating to remove the cognitive load and human errors. You are right that it could be a client issue, but when candidates start down that path and won't let it go, I tell them to pretend they're on a residential internet connection, no corporate shenanigans of any type. I also expect them to know how to rule out their local machine quickly (they can always run nslookup xyz.actualdomain.com 8.8.8.8). I intentionally use real problems I have encountered so that the scenario is something they can expect to fix(not usually all at once). I'll probably do a revision on the process next week with a terraform deployment to build the scenario out automatically for each interview. I'll be asking candidates to send me a ssh pubkey before the interview. I need to get another AWS sub-account too so I can issue credentials for the candidate and literally give them the keys and let them drive instead of me.
  • jaywalk 5y ago
    So many people have the idea that "senior" is just someone who's been doing it for a long enough time.
  • dgritsko 5y ago
    It feels kinda reminiscent of a "FizzBuzz" type of question, serving as a litmus test or catalyst for an informal conversation rather than anything strictly defined.
    • AlwaysRock 5y ago
      Ah. FizzBuzz the destroyer.
  • sontek 5y ago
    I saw a tweet yesterday where someone with 4 years of experience was looking for a Staff Engineer position. One thing the engineering community doesn't lack is confidence in our abilities, even if we aren't there yet.
    • sockpuppet69 5y ago
    • kache_ 5y ago
      I've seen interns perform better than "Staff Engineers" at some companies. Leveling is purely a function of leverage and nothing else. I'm ~4yoe and I find myself in meetings pretty much entirely populated by staff engineers. I've seen kids come right out of waterloo with more skills & knowledge than I think I'll ever manage to get. I've seen people get to Staff at FANG before 27 Anything is possible, just get good :)
  • leftnode 5y ago
    "Senior" developers tend to waaaaaay overestimate their abilities, unfortunately.
• jdrc 5y ago
  I like that now we have "apple" tags, and "twitter" tags everywhere. Maybe cocacola and mcdonalds should buy a tag too , because, why not. At least facebook had the decency to call their tags "open graph"
  • jeroenhd 5y ago
    I'm not so sure about this one. There's not much open about opengraph other than that Facebook published the for wat they want to use. Everybody else copied it, but Facebook decides what does and doesn't make it into the standard. At least Twitter has the decency to mark their proprietary standards as proprietary.
    • jdrc 5y ago
      why didnt twitter just use og: ? it 's the exact same content. they create tag pollution without thinking
      • hombre_fatal 5y ago
        FWIW, Twitter does fall back to OpenGraph tags: https://developer.twitter.com/en/docs/twitter-for-websites/cards/guides/getting-started https://developer.twitter.com/en/docs/twitter-for-websites/c... (scroll to bottom) For example, maybe you want to specify a Twitter username for your Twitter card but for all other OpenGraph consumers you want different attribution. You may also want to serve a specialized crop of the image to Twitter vs other consumers since they all display differently (Facebook doesn't crop the preview iirc but Twitter does, so you may want to specialize the image for Twitter). It's not completely braindead that they let you specialize for Twitter.
• dvtrn 5y ago
  Hi! I'm not a front-end person, I'm an ops guy, I live in the world of bash terminals and thread dumps. My knowledge of HTML and CSS is enough to make some headings and paragraphs. So pardon what might be to you folks who look at this daily-seem like a "duh" question. 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?
  • jaywalk 5y ago
    It's not that there's any "difficulty" in figuring it out, but it's literally part of the standard. An HTML 5 page will not render correctly without <!DOCTYPE html> even in modern browsers.
    • dvtrn 5y ago
      Ok, that's fair, it's in the standard. I suppose my real question is (and maybe this is a discussion that's been beaten to death and I'm merely ignorant of it): why does the standard require it, if modern technology seems to have obviated the need for it? Am I too far off the mark with "backwards compatibility" as a scientific wild-ass guess or is it more complicated than that? And if so, with what kind of devices/browsers that would still be in use today?
      • jaywalk 5y ago
        It is for backwards compatibility, but you're thinking about it in reverse. It's so that modern browsers can also render pages written to older standards correctly as well. They will not use "HTML 5 mode" unless the page explicitly declares that it's HTML 5. Nor should they, because you can't have a valid HTML 5 page without it.
• brimble 5y ago
  Expecting people to know meta tags is ridiculous for all but very specialized roles. It's the kind of thing you rarely touch once it's set up. I'd expect most developers to be able to guess correct or near-correct answers just from context, which I guess is a test of a certain kind of reading ability. So I suppose that's some kind of signal. But this stuff changes often enough and there's enough subtlety, and very few people touch it very often, that you should be consulting a guide or reference most every time anyway. 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.
  • Alex3917 5y ago
    > It's the kind of thing you rarely touch once it's set up. Exactly. Surely being able to actually configure the metadata tags on a webpage correctly must be more valuable than being able to remember what the different configuration options do years later, no?
  • umvi 5y ago
    The author says he doesn't expect perfect answers > Note that since our technical discussion is a conversation. I don’t expect a perfect answer from anyone. If I hear some right keywords, I know that the candidate knows the concept, and I try to push them in the right direction. If I were being interviewed, I would probably say "yeah all those meta tags are metadata for various consumers. The apple related ones are probably for tailoring the page for display on apple devices" Hopefully that's good enough, if I were doing the interview I wouldn't expect more than that.
    • brimble 5y ago
      Yeah, the post indicates that the author might be Doing It Right, but then there's stuff like: > Surprisingly, only a few people knew about the dir attribute in my interviews No. Most of those few people who "knew" it are decent-to-good readers with enough context to figure it out, and in this particular case they probably recognized "ltr", then worked backward to get what "dir" means, and were confident enough about that guess to state it as fact. They did all this in less than a second, because, again, they're decent-to-good readers who had the right context for this particular task. If this had been a made-up attribute you'd have gotten nearly as many people who "knew" it, I guarantee. This is closer to a web dev reading test than a direct test of knowledge. Which, again, might not actually be a crazy thing to administer.
• dark-star 5y ago
  I wonder why people keep calling HTML "source code"
  • sockpuppet69 5y ago
  • xiekomb 5y ago
    Ahah this! When reading the post title I was wondering if Twitter backend end (or even front end) source code had leaked. As a candidate I would give minus 1 point to the interviewer ;)
  • leephillips 5y ago
    I don’t, for one. From the title I thought this was about the code that runs the Twitter back end. I would call this “markup” or “HTML”.
  • brimble 5y ago
    It screams "non-technical manager" (or journalist, or politician, et c) to me (though that doesn't seem to actually be the case, here?)
• sockpuppet69 5y ago
• kabes 5y ago
  So his way to test a full-stack javascript developer is to let someone explain 10 lines of which none is javascript.
  • ZeroGravitas 5y ago
    I thought "full-stack" implied you understood the front-end web environment?
    • Viliam1234 5y ago
      > A full-stack developer should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for junior developers. -- Robert A. Heinlein
      • jlcoff 5y ago
  • y42 5y ago
    I'd say that's legit, considering what he is looking for - full stack. JavaScript is strongly connected to the term WebDevelopment and thus to HTML. That's just basic knowledge.
    • kabes 5y ago
      Sure, but it also means being skilled in writing Node backends and I'm doubtful if knowing what some meta tags mean is a good indicator for that. This is the equivalent of interviewing for a C developer by letting him explain a Makefile.
      • jbki1121 5y ago
• missblit 5y ago
  So... how did I do? ;) --- <!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?!)
• jandrese 5y ago
  > <html dir="ltr" lang="en"> 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?
  • selfmodruntime 5y ago
    No, but a screen reader that has set rtl as a default might.
  • missblit 5y ago
    Per https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute https://html.spec.whatwg.org/multipage/dom.html#the-dir-attr... it'll default to LTR > The directionality of an element (any element, not just an HTML element) is either 'ltr' or 'rtl', and is determined as per the first appropriate set of steps from the following list: > ... If the element is a document element and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value) ... > ... The directionality of the element is 'ltr'. It's not that common to see LTR explicitly specified for the document, but you could imagine some code that either outputs ltr or rtl based on the user's preferences. (Indeed I just checked and twitter puts a rtl there if you're using it in Arabic)
  • dymk 5y ago
    There's probably a line of code that looks like this: > echo('<html dir="$dir" lang="$lang">') (or something similar), and they unconditionally include the `dir` attribute without checking if it's already set to the default value a browser would assume.
  • hombre_fatal 5y ago
    What the nay-sayers in these comments seem to not understand is that your curiosity here is a great response to TFA's question.
• maxbaines 5y ago
  Why the first line of Twitter, why not Facebook.com or Google.com actually I just looked there all very different given meta tags for each company, i.e Facebook does not use twitter meta tags from what i could see neither does the google home page, although i guess there search does.
• DHPersonal 5y ago
  This test leaves me conflicted. I'm often surprised by what developers remember and more importantly forget; it seems that after a while the fundamental elements of what makes up a website are lost in the sea of new development languages or platforms. I've done front-end design and development for over a decade now but have largely leaned into the prototyping and design area of that career, so my knowledge of development is limited enough to not have forgotten HTML and the markup for building a page. I would've been able to ace this test while also failing to be suitable for a senior Javascript developer. Developers here on HN who would likely be able to outwit me in every way in development seem to have lost touch with simple HTML markup. Still, I wonder if something important is lost when development requires these basic elements of a page to be forgotten in service of a new framework or language.
• jeffalbertson 5y ago
  this is such a dumb, mediocre gotcha interview question. 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.
• fefe23 5y ago
  May I jump in to point out that this is not "Twitter's source code". It's their HTML. 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.
  • grenran 5y ago
    Author needs clickbaits to get clicks
  • jbki1121 5y ago
    I'd say it's fair enough to consider markup as code ("code" in the sense of morse code)
  • hoten 5y ago
    The browser ui to view this Html has been called View Source for decades.
  • booleandilemma 5y ago
    “Sorry, we don’t hire pedants here”
    • ninkendo 5y ago
      "Have fun with your bootcamp graduates then"
  • CPLX 5y ago
    It’s the code you see when you view source
  • tfvlrue 5y ago
    I tend to agree with this. My expectation from reading the headline was that it would be code from the backend (which admittedly seemed odd, since that's not public). I can't recall ever seeing someone use the phrase "X's source code" to mean HTML. In my view it's data, not code. Just like you wouldn't call some XML file "source code" -- it's purely descriptive markup. When a browser's context menu says View Source, the word "code" isn't implied. It's the same usage of the word "source" meaning "origin" (as in "cite your sources"). Maybe I'm being overly pedantic, but the phrasing definitely read strangely to me regardless. Speaking as someone who's done a mixture of programming and web development for over two decades.
• ejb999 5y ago
  Its interview questions like this that makes me never interview for a new job. I get jobs when I need them pretty easily, but usually just through someone who already knows me and/or worked with me before and skip the silly interview questions like this.
  • RandallBrown 5y ago
    What don't you like about this question? The author isn't looking for exact right answers and just wants a discussion about the technology to gauge your skill. I enjoy interviews like this.
• deleted 5y ago
  [deleted]
• partomniscient 5y ago
  If anything this illustrates how convulated and painful web development has become. 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.
• dpweb 5y ago
  I think I'd enjoy this interview, as I don't really like people watching me code. But to have a discussion about quirky html history would be a fun (I think less stressful) way to spend the time.
• shadowgovt 5y ago
  Great discussion of what these mean, but terrible idea for an interview question. As a rule, I really try to shy away from questions where the answer is "I don't konw, but I'd be happy to look it up if it were relevant to my job," and with modern frameworks direct knowledge of these tags is almost never relevant. (On the other hand, if the candidate had access to a computer, following their process of looking these up might be interesting...).
  • ripley12 5y ago
    I see this as similar to the "what happens when you visit google.com?" question - it's a starting point for conversation, not gotcha trivia. I certainly wouldn't expect anyone to know every answer off the top of their head, but talking through a candidate's educated guesses can be informative.
• buro9 5y ago
  I'm an old-timer and mostly backend now... I knew all but one of these lines. But the chances of me now being able to make a website based on modern frontend frameworks is near zero.
• MaxMoney 5y ago
• Animats 5y ago
  "As a side note, it looks like Twitter omits the HEAD tag for performance reasons" 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.
  • munk-a 5y ago
    It's an absolute necessity that they shave 13 bytes off the packet size... to make room for more advertisements. Their page size is 90KB for me, which isn't great nor terrible, but violating standards "just because" feels unnecessary.
    • JimDabell 5y ago
      Omitting the <head> tag doesn’t violate any standard. It’s valid HTML.
      • munk-a 5y ago
        The title tag SHOULD occur in the head of a document[1] The <title> element is always used within a page's <head> block.[2] Just because browsers are compatible[3] doesn't mean what you're doing is right. Twitter does set a title tag and thus that tag should be within a head block. They are leaning on browser compatibility mode to cover the fact that they aren't adhering to standards. 1. https://www.w3.org/Provider/Style/TITLE.html https://www.w3.org/Provider/Style/TITLE.html 2. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti... 3. "HTML5-compliant browsers automatically create a <head> element if its tags are omitted in the markup. This auto-creation is not guaranteed in ancient browsers." https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head#notes https://developer.mozilla.org/en-US/docs/Web/HTML/Element/he...
        • JimDabell 5y ago
          > Twitter does set a title tag and thus that tag should be within a head block. It is in a <head> element. You don’t understand how HTML is parsed. The opening and closing tags for the <head> element are optional. That doesn’t mean the element isn’t there, it means that the element is always there. > They are leaning on browser compatibility mode to cover the fact that they aren't adhering to standards. They aren’t. See this comment I made and go ahead and paste that HTML into a validator: https://news.ycombinator.com/item?id=30475015 https://news.ycombinator.com/item?id=30475015 There is no error handling taking place, there is no browser compatibility mode involved. This is correct HTML that adheres to the standard being parsed normally. > [1], [2], [3] Why are you quoting a style guide written in 1992 and two unofficial sources when you could just as easily have referred to the actual HTML specification? > § 13.1.2.4 Optional tags > Certain tags can be omitted. > Note: Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup. — https://html.spec.whatwg.org/multipage/syntax.html#syntax-tag-omission https://html.spec.whatwg.org/multipage/syntax.html#syntax-ta... The HTML specification literally gives this as an example of a valid document: <!DOCTYPE HTML> <title>Hello</title> <p>Welcome to this example.</p> There are a great many ways in which people write broken HTML and the browser repairs things. This is not one of them. Omitting the opening and closing tags for the <head> element is perfectly correct HTML that adheres to the standard.
• ramesh31 5y ago
  Count me as someone who loves this. I could turn this prompt into an enjoyable 30 minute discussion easily. I am a front end developer, not a computer programmer. I cannot reverse a linked list or invert a binary tree. But I can explain in depth to you about every single aspect of the browser, HTML, CSS, JS, and UI engineering in general. I have a decade of deep, specialized expertise in building software for web browsers, and an encyclopedic knowledge of web technologies. I can build anything, and my previous work speaks for itself. But I simply cannot pass the SV Leetcode/whiteboard style interviews. It's maddening.
• deckard1 5y ago
  This seems to be closer to the right approach to interviewing over the leetcode grind, but it's the wrong example. The head tags are trivia and have changed a lot over 5-10 years (not to mention Twitter doesn't include the head tag which is just wrong, IMO, though every browser since the '90s is flexible on this and everything else to do with HTML). Many front end devs haven't touched the head tags because that's a separate team. Or it's the lead devs that set that up. It's also the kind of thing you set once and never touch again and every site will use different head tags. 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.
• heavyset_go 5y ago
  Quizzing on trivia, especially minutia that can be looked up and fully understood in less than 2 minutes, seems like a waste of time to me on the interviewer's part. 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.
  • iratewizard 5y ago
    The best questions are the simple ones that start a conversation. That only works if the interviewer is confident in their ability to read people and competent at their job. These articles are written by and for people who don't meet those criteria.
    • heavyset_go 5y ago
      I just don't see the value in the questions from the OP. What if the person being interviewed genuinely doesn't know and says, "I don't know"? Asking them to then guess what the markup could mean doesn't really tell you much about their skills or abilities. It feels like a potential dead end to me. I think there is better material to review and ask questions about that actually pertains to the abilities of the interviewee or the skills needed for the job at hand.
      • tgsovlerkhgsel 5y ago
        There's 10 lines. If they're applying for a web development role and say "I don't know" to all of them, it tells me enough about their skills and abilities to end the interview right there. If they don't know half of the trivia but tell me "this looks like it probably controls browser feature X", and they're making a reasonable guess (regardless whether it is correct or not), that's a good sign. If they don't know something but confidently pretend they know and spurt bullshit - red flag. I don't want to have to second-guess everything they say, and have them deliver something that looks right while being completely wrong. If you don't know what that specific prefixed attribute does, I don't care. If you don't know what a vendor prefix is in CSS, you haven't written much CSS.
• hartator 5y ago
  I think this might weed out more junior but very promising profiles. And remembering the Netscape days and why of each meta “hacks” might be a little tricky even for very senior profiles.
• pwdisswordfish9 5y ago
  With that title, I would have expected an analysis of leaked backend code.
• joshstrange 5y ago
  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.
• dinkleberg 5y ago
  I’m imagining many of the people who are against this idea have never been on the interviewer side. Or aren’t web developers and feel they should be able to answer this regardless. 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.
  • noahjk 5y ago
    HN: complains about leetcode-esque interviews Also HN: complains about alternative conversation-style interview I don't work on the front-end, but I have had a general curiosity for it for a while, and I think this would have been a great conversation starter! And I think a lot are missing the point that the interviewer isn't exactly using this to just "fail" people. Like you mentioned, these are the sort of out-of-the-box conversation starters that good interviewers try hard to come up with so they don't have to just give coding tests and ask the top 30 JS trick questions that are easily googleable.
  • degenerate 5y ago
    Exactly -- it gets people talking so you hear how they communicate and solve problems.
  • tgsovlerkhgsel 5y ago
    Also, people who haven't been on the interviewer side have no idea what kind of idiots apply to jobs they're absolutely not qualified for. Like web developers who couldn't make a reasonable guess at more than two of these lines.
  • woutr_be 5y ago
    > 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. I get that this might be the intention, but if you're being interviewed, and asked to explain the first 10 lines of some code, you'll rightfully feel nervous, and feel as if this is a pass or fail test. If the intention is to make this a discussion, perhaps change the question, and start the discussion yourself.
• dillondoyle 5y ago
  I know these, because I build websites, often simple static sites. A bunch are social or just rendering on apple devices. 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
• jollybean 5y ago
  This isn't a very great interview question. 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'.
• paxys 5y ago
  I was going to say what's the point of asking such basic, obvious questions, but reading the replies in this thread – yikes! If you cannot answer at least 7-8 of the 10 questions in under a minute, you have no business being a web developer, forget calling yourself a "senior" one. If I was an interviewer in this situation, I'd be perfectly happy with a candidate who thinks they are too good for this walking away and taking their framework-of-the-month skills elsewhere.
  • jenscow 5y ago
    Such responses actually highlight the need for us to do basic checks like this.
  • deleted 5y ago
    [deleted]
  • markmark 5y ago
    I'd happily hire someone who can write clear, maintainable code in the framework-of-the-month over someone who can remember how to change the Apple status bar color without Googling it.
    • gunapologist99 5y ago
      Recognizing what it is is different from remembering the exact syntax.
• Sohcahtoa82 5y ago
  > Twitter also applies user-scalable=0 which, as the name suggests, disables the ability to zoom 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.
  • munk-a 5y ago
    Ditto for everyone who has ever written code to stop me from copying text - they're obnoxious anti-features.
  • savrajsingh 5y ago
    WebKit ignores this, I can resize Twitter no prob https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/ https://webkit.org/blog/7367/new-interaction-behaviors-in-io...
    • Forge36 5y ago
      I assumed my accessibility settings were overriding this. Enough websites had disabled zoom I turned it on.
  • tgsovlerkhgsel 5y ago
    Check your browser settings under accessibility. It makes sense for most users to allow sites to disable this, because users accidentally zoom (especially by double-tapping) making the web app feel non-native and broken. But I believe most browsers let you tell them that you always want to be able to zoom, and then they ignore this setting. Providing it as a setting has the advantage that developers just set it (and you can tell your browser to ignore it), instead of finding some horrifying and harder-to-avoid way of preventing the browser from zooming.
  • ninkendo 5y ago
    Related xkcd: https://xkcd.com/1174/ https://xkcd.com/1174/
• scrozier 5y ago
  I've been doing web development since the web began, literally. The percentage of my time that I've cared about the stuff in this header is approximately .000047%. And when I do care, I can look it up and reacquaint myself. A full stack developer has so many things to know. This is representative of the kinds of questions that make interviewing so awful these days. Oh, and I've interviewed hundreds of front end developers, so I've been on both sides of the table.
• RGamma 5y ago
  Self-description about the business that is mentioned in the first sentence: "Beautiful interior design for your home with the flexibility to /rent/ or buy the furniture you love" 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
• filmgirlcw 5y ago
  I actually really like this and I’m a bit surprised to see all the pushback. If someone asked me this in an interview, I would have no problem talking about all of the stuff (origin trials, I might have messed up, but I might have been able to BS my way through the answer depending on the full length of the line and what context I could glean from it) and even now standards and boilerplate and defaults have evolved over the years. 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.
  • jenscow 5y ago
    > able to BS my way through the answer That's it. Anyone claiming to be a senior full-stack engineer should be able to BS their way through this. If you're shocked by what you see on a "view-source" screen, then you haven't been doing this for very long, and you're not really "full stack".
    • filmgirlcw 5y ago
      Absolutely. And I’ll also say that as an interviewer, I appreciate someone who can BS though something like this. Because part of the job is BSing through a lot of stuff.
    • devoutsalsa 5y ago
      If someone can get stuff done on the front-end and back-end at a senior level, who cares what they've memorized? I used to memorize all sorts of stuff. The only advantage it gave me was occasionally sounding smart, which it came at the expense of learning actually interesting things, like how to pick a useful database schema.
      • 5y ago
• fleddr 5y ago
  The comments in this article are embarrassing. It shows none of you have even basic reading comprehension. Either you didn't read the article at all or not very carefully: "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.
• brundolf 5y ago
  I think this is fine as a fun litmus test, I don't think it's fine as a key criterion. If a person didn't know a single one of these, they should still be in the running (if marked down a little bit). Most senior front-end devs I would expect to have a decent grasp on maybe 1/3 of these. 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
• irrational 5y ago
  Why are lines 10+ not inside of a <style> tag? I wasn't aware you could put CSS into the document without being in a <style> tag. 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.
  • reaperducer 5y ago
    It appears that many things that I thought were normal to put into an html page are not. Those are normal things, but some companies like to deviate, often just to be different. For example, Google uses a Unicode lightning bolt as its DOCTYPE for Amp pages. However, saving 100 bytes on a page load can end up being actual money saved when you shove out as many pages as Twitter does in a month.
    • irrational 5y ago
      Saving bytes makes sense. But how does the rendering engine know that those lines are CSS instead of junk text? And without a head tag, how do those lines not end up as text in the body of the document? And isn't it strange that it doesn't have a title tag (though, if you aren't going to have a head section, maybe skipping the title tag makes sense too).
  • hombre_fatal 5y ago
    It's cropped out in the screenshot, but if you look at Twitter html source, you'll see that there is a <style> tag that opens at the end of the line before the CSS. There is a <title> tag, but it's created by Javascript. You can see it with document.querySelector('title') once the page loads.
  • jlokier 5y ago
    There is a <style> tag. It's at the end of very long line 9: ...haW4iOnRydWV9" /><style>html,body{height: 100%;}</style><style id="react-native-stylesheet">[stylesheet-group="0"]{} Several of the first 10 lines are extremely long and have a large number of elements per line. Because it's not meant to be human-readable, to save space, newlines are omitted where they are not required. <head> is optional in HTML5 syntax. It's implied by the first <meta> tag. There's still a <head> element, which you can see in the DOM inspector. <title> is optional. But in Twitter's case, the <title> element appears to be added later by JavaScript, as it's not in the page source but it is in the DOM after loading. Various people say <head> is omitted to save space because it's optional in the HTML5 syntax anyway, and that shaving off a few bytes is worth it. It is to save space, but it seems hardly worth it when you look at the full head section, which has a large number of <link> elements>, and the long content of the origin-trial <meta> elements. They suggest the page is not particularly optimised for size. To see Twitter's head section properly, it's best to view source, copy to a text editor, then insert a newline before each "<" where there isn't one already.
• ingvul 5y ago
  And this is why the tech interview process is (still) broken.
• picture_view 5y ago
  FWIW I have been building web applications with JavaScript for about 7 years - sometimes very complex applications with literally millions of MAU - and I couldn’t have told you with any depth what most of these LOC actually do. YMMV
  • jlcoff 5y ago
• codeptualize 5y ago
  I wonder why so many interview questions are focussed on knowledge and memory. For most technical roles, and especially in the ever-changing world of FE; your main skill is looking things up and applying what you find. 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.
  • AdrianB1 5y ago
    Why interview questions are focused on knowledge? Because you want to hire someone that knows how to do things, not how to Google it or ask on Stackoverflow and assemble bits and pieces of stuff wrote by others in a Frankenstein monster. Memory? It is not a test to write rare parameters correctly, the questions problem the knowledge about the most basic things in web development - html. It's like asking a surgeon in a hiring interview if he knows what a scalpel is; not the chemical composition or forging method, just what is used for. Imagine the guy saying "I don't know, I never memorize this stuff".
    • codeptualize 5y ago
      How often do you write the html params and meta tags? I really don’t care if someone memorized all the meta tags. What matters to me is that if I ask them to write a template they can find out what they need to include according to the latest best practices and our situation. I rather have them looking it up than relying on something they memorized years ago and might be outdated. Looking things up is not the same as carelessly assembling as you describe it. It’s the ability to gather knowledge quickly, learn on the spot, so they can work on things they haven’t worked on before, and keep up with the latest best practices. Absolutely essential to FE development. And some of it is assembling and relying on tools to work efficiently; for example I would highly recommend to generate Favicon and tile tags. To be an effective fe dev require tons of learning on the job and doing your research as new things arrive constantly, best practices change, and you will encounter many things you haven’t before. Like I said; experience and breadth of knowledge is an interesting indicator, but it doesn’t make much sense to me to have it as the main indicator. > Imagine the guy saying "I don't know, I never memorize this stuff". Then I would ask them to look it up and get an impression of their ability to gather quality knowledge and understanding. Not a problem to me, and I would appreciate the opportunity to gain insight in those skills.
• TAKEMYMONEY 5y ago
  > Perfect answer: This meta tag... The perfect answer calls these elements, not tags.
• bluenose69 5y ago
  I don't see a problem with this line of questioning. 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.
• sakopov 5y ago
  My only question is why does a furniture rental site interview candidates like they're trying to change the world. Dear lord, you're making a CRUD app. Get over yourself.
• spondyl 5y ago
  My first thought was that with minification in place, there might not even be 10 lines, but instead 1 extremely long line
• xd 5y ago
  It's the cross section of subjective vs objective .. I'd much rather you give me an actual problem you have and let me have a go at explaining a solution for you. All this tells me is you are recruiting generically and have no idea who you need on your team.
• andrewingram 5y ago
  The only one I didn’t know was origin trial; though curiously that line also used http-equiv, which is an interesting one, because those meta tags act can be used in place of response headers (and vice-versa). I was a little surprised that the “perfect answer” didn’t call that out. 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.
• marstall 5y ago
  I do like this interview question - but I would angle it a little differently. 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.
• oblib 5y ago
  I do my own front end work but most of what this bit is about is boilerplate stuff I just edit as needed. 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.
• andy_ppp 5y ago
  I thought the answer was going to be years of bad hiring and lack of care about their users, but I guess that’s probably a bit snarky :-)
• akomtu 5y ago
  Wow, html of the twitter's front page is called "twitter's source code" on hacker news. I guess, we can call this "popular programming for kids" to avoid harsher epitets.
• civilized 5y ago
  Most people's claims of interviewing brilliance are bullshit because they only know the performance of those they accepted, not those they rejected. 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.
• jupp0r 5y ago
  Reading the article, it sounds like the author is looking for a Senior Software Archeologist, not a full stack engineer. None of this is relevant or useful to any job somebody might be doing.
  • stevage 5y ago
    Who do you think wrote that code for Twitter?
    • jupp0r 5y ago
      My guess would be Mark Otto[1]. [1] https://github.com/mdo https://github.com/mdo
• KrishnaShripad 5y ago
  This is wrong set of questions to ask for a Frontend Developer position. This is perfectly fine for those who are building tools for Frontend. I knew most of these questions primarily because that is what I love doing. I, however, won't expect any frontend developer to focus on this as this is not the job of a frontend developer (more a job of tooling developer if that is even a thing). 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 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.
• stevage 5y ago
  I really like this as an interview task. I wouldn't do particularly well, as I'm more on the JavaScript side, but it would really expose the parts of web dev that I'm not familiar with. Prompts to have conversations that expose a candidate's depth of knowledge in real world cases are exactly what an interview should contain...
• EdwardDiego 5y ago
  The "perfect answer" for the doctype is odd, the "also accepted" is, IMO, the perfect answer. Unless you're hiring someone with indepth experience/PTSD of supporting IE6.
• SergeAx 5y ago
  I am a software engineer with about 35 years of experience. For the last 10 years I am working as an engineering manager, but I am taking an interview or two on engineering positions from time to time. 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.
• rswail 5y ago
  People here are arguing that having "esoteric" knowledge is pointless. But the point of the article was to use it as a "discussion point" and get the person talking about things. 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.
• 0xdeadb00f 5y ago
  If asked this I would ace it. And I'm not even a web dev :)
• steve76 5y ago
• npteljes 5y ago
  When I interviewed people I asked questions like this in their domain, and the responses were quite valuable. The answers immediately highlighted how experienced the person was, how long have they been in the domain, and what kind of approach they used in their work.
• uoaei 5y ago
  Is this a trick question, and "HTML isn't technically code" the correct answer? 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.