My expectations for people cratered after I began interviewing. It's.. incredible.. how untechnical people applying for highly technical positions can be.
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.
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 :)
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.
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.
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.
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
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"
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.
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.
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?
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.
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?
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.
The loud noise you're hearing is the sound of a bunch of old, rusty mechanical gears clanking into place. This explanation makes perfect sense to me now. I hadn't done much serious front-end things since high school in the early 2000's and even then I had no idea what "web standards" were. I just knew how to make pages and display images for a counter-strike 1.6 clan haha.
Browsers include a lot of crazy backwards compatability stuff. You can basically trigger a whole different experience with the right/wrong doctype line.
I guess it'll disappear eventually and become an opt out rather than an opt-in, but not sure if we're there yet, IE11 has been a major drag on progress.
It can never disappear and become an “opt out” without breaking backwards compatibility. This has nothing to do with old browsers, but rather, old content. You can’t go back in time and rewrite every HTML file ever published in order to have them “opt in” to quirks mode.
Most browsers have quirks modes for different types of HTML standards. Certain errors are renderered in certain ways because that's what web devs used to expect, even if they weren't following the standard. If you strictly enforce XHTML1.1 or HTML4 because the website says that's the standard it follows, you end up with tons of broken websites. It's a consequence of websites historically being lenient with front end developers.
The HTML5 string basically says "I promise to be good, please turn off your weird workarounds". Of course, HTML5 has been around long enough that some browsers still have certain quirks, but they're not as extensive as the ones before HTML5.
Compared to the `<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">` monstrosity from before, I'll happily take the modern standard. There's no version number anymore, just a simple HTML identifier.
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.
> 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?
> 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.
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.
But don't underestimate the importance of reading as a skill! It's incredibly frustrating to see devs make stupid mistakes and spend time trying to get something to work when the answer is right in front of their nose.
I see this too often. A developer (usually more towards the junior end) who think they can just chug through any problem. Trying this, then that, then google, then that again. When, if they would just stop and think through the problem - and use their eyes - they would see the solution was there all along.
Totally agree. I’ve definitely made this mistake myself (we all have) and the lesson is definitely to stop, think, read the code and that usually helps with the solution (or at least makes it easier to hone in on what to google)
I sometimes see this with C++ compiler errors. People don't even try to understand them. They just change some random things and copy/paste some snippets from Stack Overflow, and finally request help instead of just investing a few minutes to actually understand what the compiler has problems with. Yes, g++ compiler errors are heard to read, but often the needed information is right there.
And this is for a furniture rental business...? I think there is a easier way to determine if a candidate has the minimum technical skills required for the job besides a diminutive interrogation about Twitter.
They don't expect candidates to be able to write the "right" set of tags, but they use them as a basis for discussing different topics and recognizing things and maybe doing educated guesses in the meaning are quite useful skills.
> Expecting people to know meta tags is ridiculous for all but very specialized roles.
Devil's advocate - is it? You're right, this stuff rarely gets touched, and (aside from changing the colours in the bit you hate!) it's the kind of stuff I'd normally boilerplate between projects.
But if you're interviewing for a role and you're not giving them a coding test (yet?) but looking to see how curious they are, how disparate their knowledge is, or just (as you say) how good someone is at guessing from context - isn't this a fun experiment?
I'd imagine just seeing how people deal with the answers gives you a good idea as to how they'd approach something when you're working together. Are they guessing? Confidently wrong? Seen it before but don't know what it is? Can roughly talk around it and what it does without exactly knowing? Proficient in it all (and how that relates to what they have or haven't said on their CV - have they under or over sold themselves?!)?
I assume you could apply the same sort of test to any domain - test someone on something closely related you don't necessarily need to know and see how they react.
The problem with these "present a tangental question / loosely unfamiliar but similar" questions is that they become useless when a candidate does know the answer as memorized trivia. At that point you're looking for a signal about "what does the candidate do when presented with something familiar but unknown" but receiving "can the candidate regurgitate an answer."
Of course you can then ask a different question, follow-ups, and so on, but you're so far off baseline compared to most candidates that the question starts to become useless.
I don't think the point is that every interviewer should ask about Twitters source code, and every interviewee should memorize it.
The point is to ask a few randomly sampled knowledge questions to measure how well rounded the candidate is. Taking the "first 10 lines of Twitter" is just one way to sample such questions.
If you want to know how curious I am, ask me. If you want to know how disparate my knowledge is, ask me. If you want to know how good I am at guessing from context, ask me. If you're asking about meta-tag trivia, all you're going to find out is if I know meta-tag trivia. I know myself way better than any interviewer possibly can. If you don't trust me to evaluate myself, then you shouldn't be hiring me into a creative, professional, self-directed position.
In my experience, lots of people apply for jobs they aren't qualified for.
How does I as the interviewer know which candidates I can trust to assess themselves and which I can't?
I mean, a fair number will walk in the door talking about C-pound. A number of them will exclaim "What wizardry is that!" when you open up the developer console (or accuse you of hacking). Just do your best to sus out obvious lemons and fix the rest in post (i.e. figure out if they're full of crap during their probationary period).
If you have specific pieces of technology you're working with and want to interview about then take an afternoon and just code up some bizarre snippets to go through with them - add a few mistakes they should be able to catch and just talk through their process.
I honestly don't think opening up a random website and asking about some of the source code is a terrible approach... if you're interviewing someone for writing HTML in the 90's - in the modern world all the JS is minified (and likely generated by a framework), the CSS is absolutely atrocious to read (usually also generated) and the HTML is pretty much irrelevant. Use something that's going to be applicable to candidates to judge their understanding - I've always been fond of short puzzles very much unlike this one (it's way too arcane) in PHP `0x5 &$var=['cow' => 6]['cow']`[1] - just blerbs where you can step through some syntax understanding and problem solving at the same time.
An actually good suggestion is to check out a random (ideally mostly self-contained) file from your codebase from a decade ago and step through what's awful about it - all code bases have these, and they're usually still kicking around as active code in production. At one of my more recent interviews they sent me login.php (the one actually in production, which they knew was broken - they had two developers before me which were really overworked) and just asked me to mark up wrong stuff - I found SQL injections, unbound variables, conditions that would result in invalid HTML and broken forms and some terrible decisions from a readability perspective. I spent... maybe an hour on it.
My point was that you can have a conversation with a candidate instead of using arbitrary trivia that is irrelevant to the job and potentially irrelevant to the human you’re interviewing. If you want to find out about someone’s diversity of knowledge, I think “what’s the most esoteric tech you’ve worked with” or “tell me about a project that taught you the most” are vastly superior conversation starters than meta-tag trivia.
“ I know myself way better than any interviewer possibly can. If you don't trust me to evaluate myself, then you shouldn't be hiring me into a creative, professional, self-directed position.”
I am not sure this is well grounded in the studies of human psychology.
I think it's extremely fair to not trust people to evaluate themselves when doing open hiring - for networked candidates you can usually relax some assumptions and for very senior/niche positions there's usually ample street knowledge available... but in these cases you're relying on a third party for some level of vetting. I would never solely trust a second party during hiring unless I had some method to confirm at least some of what they're saying.
A lot of companies are far too hesitant to trust employees, but blind trust is unwise - you can end up with an employee that either wastes three months salary or actively causes damage.
I think we may be talking about slightly different things.
There is a ton of well researched psychology work on self deception, confirmation bias, it goes on and on.
Asking about the things that the OP was mentioning are deep psychological traps. Perhaps the OP has deep self awareness, but that does not apply to the general candidate or human.
Our blind spots of our own actions and behaviors are profound.
It's really just the same kinda thing that fills most coding interviews (that aren't just pure live coding challenges): the interviewer is testing for something that isn't directly relevant to the role, because of course in the real role you'd be able to (and should!) research all the appropriate meta tags you should have on your web site, but since the interviewer deems it too difficult to actually directly test for the ability to do the job, they instead test for things that surely the candidate must have ran into before and has a good enough memory to at least have a conversation so that I can subjectively judge how skilled the candidate is.
I've not been a frontend dev for well over a decade but I knew the meaning of all these meta tags. Back then I think it'd be pretty rare to find a good frontend developer who couldn't say what these were.
Have things changed so much that knowledge of meta tags is specialist now?
Assuming this interview was for a front end role that is.
>Have things changed so much that knowledge of meta tags is specialist now?
Yes. More or less all web development now involves generating HTML with a language that compiles to javascript and a framework. No one even looks at, much less directly interacts with, fundamental web code anymore, and HTML has become esoteric "low level" knowledge like assembly language.
But we've always generated the html using other languages, still needed to have a pretty decent idea of how it works. I find it hard to believe that's all redundant now in quite the same way knowledge of assembly is when your a python dev for example.
Like take the open graph meta tags for example, for certain websites it'd be a big oversight to leave them out because you never bothered to learn what they were.
I don't know if all this makes for a decent interview. Just blows my mind that people deem it too low level to have to care about, but what do I know anymore, it's been a real long time since I made a web page.
It's not a test of their meta tag knowledge, it's a test of how well they can speak to concepts with some context. (For instance, I don't really do anything with Open Graph, and I don't know the meta tag off the top of my head, but I spotted it in this example)
I think expecting people to know things they really shouldn't, and seeing how they react to that lack of knowledge is a very important part of interviewing.
I assume this isn't the only question OP asks in their interviews, but I think it's got a couple of good outcomes and returns a lot for the length of time it takes to go through.
I am not a developer, never was, but I know most of the stuff in these lines. If I know about it, I expect a front-end developer to know a lot more - the developer is not a monkey pushing buttons in a framework to get a banana and web development frameworks should not be black boxes that nobody using it understands how it works and why. That is a level of superficiality that is terrifying.
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 ;)
> 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.
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.
It's that the signal you're gonna get out of such an interview is gonna be so low that whoever you end up hiring is mostly going to be due to chance + how much you "liked" them.
Pretty much the same thing that would be wrong with asking a javascript dev to explain grunt.
What if that C++ dev primarily uses visual C++ and Visual studios projects? What if the C++ dev primarily used Cmake, ninja, or scion (or any of the other thousands of C++ build tools).
What if that C++ dev never really needed to start a project from scratch?
The issue is testing someone on minutia doesn't tell you anything about how capable they are. In particular, testing them on minutia that they very likely rarely interact with is beyond pointless.
> What if that C++ dev primarily uses visual C++ and Visual studios projects? What if the C++ dev primarily used Cmake, ninja, or scion (or any of the other thousands of C++ build tools).
Then it's an opportunity for the candidate to explain the tools they do use.
There are certainly bad interviewers out there who misuse these kinds of questions, but I think they're fine if used as conversation starters.
if it makes any difference, I was referring to C, for which Make is the majority, I think - could be wrong, though, since I'm not a c developer.
But to the point, I'm not sure if the code at issue would be considered minutiae or not, but I believe that the more curious you are, the more you tend to dig into the details, and a person doing this over many years would attain a rich knowledge-base spanning depth and breadth. I know as a java developer that I've referred innumerable times the docs for the POM and settings structure in order to explore the limits of customizing my build, which would include the rather obscure features. Not saying this is technically comparable to meta tags in html, but maybe that's what the author was going for.
Surely you don't think this would be the _only_ tech-oriented conversation starter / interview question in a full-stack interview. This is for testing the front-end "half" of a full-stack dev's skills. A separate conversation in the same interview would be had for node, SQL, etc.
If you position yourself as a full stack JavaScript developer and you think talking to 10 lines of non-JS front end code is too much out of a 1 hour long interview I'd be extremely suspicious of how much time you've spent on the front end half of JavaScript integration.
The issue I have with this test is it tells you nothing about the person you are interviewing.
When would you actually create such tags as a fullstack dev? Almost never. 90% of the time, those tags are auto generated by some boiler plate app.
A person that can answer correctly MIGHT be someone that's looked into those tags and done things the hard way, but is that really someone you need to hire? A person that answers incorrectly doesn't necessarily seem like someone I wouldn't hire. After all, what do I care about someone knowing the intricate details of the "html" tag and how it interacts with various browsers? That's write once and forget sort of code.
If you wanted this test to mean anything, why are you picking worthless trivia. Why not, instead, pick something like a function out of jquery or your own code base and ask the same question "Tell me what this function is doing".
"Explain the first ten or so lines of the Twitter source code to me." doesn't read to me like a test, it reads like an opener. Sure, it's possible to show off you know 100% of the trivia for the tags that show up... but more so it's an opener for you to talk to about how much background you know, how much you can relate what you didn't know to things you did or have worked on, and how much you've bothered to go beyond "that boilerplate is generated for me" and look into what the first few lines of the webpages you work on do.
The point does not at all seem to be "Aha, gotcha! You didn't know about the syntax for Apple's limited PWA like functionality offhand in an interview. 5 demerits, next question!".
A person that can hold a good discussion around these tags is both likely to be one that has truly been developing pages for a couple of years and has an interest in learning more than how to make their framework work rather how to make any framework work in a browser. If you're not able to say something cursory about language attributes I'm going to have a hard time believing you've full-stacked a multi-language website (not that I wouldn't but it'd lead to a lot of different questions later). If your response about the doctype line is "it's boilerplate put in by my IDE" my first thought isn't going to be "oh they just spend a lot of time writing code in the rest of the page" it's going to be "they either don't care what the first line of the page is about or it's been so long since they've touch the front end directly they can't say anything about the first tag. I wonder how well they can deal with integrating the front end JS with the page" and steer to towards more about that.
Also the interview was mentioned to be an hour long, if 10 lines of HTML boilerplate, most of which should be on every page, is too far into the weeds of front end time wise then I'd have severe concerns the candidate would be too back-end heavy. Yes, other things should be talked about too, that's why the interview is an hour and this singular question is only about 10 lines.
> 90% of the time, those tags are auto generated by some boiler plate app.
Well, that's a problem. If you don't know how to create a web page with out having to fall back to using "some boiler plate app", I question if you really are a fullstack developer (I would also question if you really can consider yourself a web developer at all, but I know that will just upset people, so I won't go there).
<!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 parse...
> People even used to use * { margin: 0 } which is totally overkill and not great for performance.
Wait why would that be bad for performance? Zero margins should be just as fast as 8px margins, and if you have this style in the head section it's not like the browser will have to relayout a bunch of stuff.
The argument on performance comes from the idea that theoretically the rules are applied in order. So the browser has built in stylesheet of 8px, and after that a margin of 0 is calculated. (And after that, some more specific margin in the stylesheet is recalculated)
Basically * { margin: anything } adds one extra calculation to each element in the page.
Not sure if the performace hit is measurable tough, knowing how much optimization goes into browser engines.
The universal selector has the potential to be slower than other selectors in naïve CSS engines because CSS works by matching selectors from the right to the left. A rule like `.baz *` matches every element on the page (vs something like `.baz .foo` which only matches elements with `.foo`). The match is only rejected after walking up the DOM tree to the root node to see if any parent elements have the `.baz` class or not.
In the case of a single universal selector, there is no performance issue, the selector just matches every element, which is fine.
In modern engines, there is also no performance issue, they JIT compile selectors[0] and do other stuff to be fast. Even old engines wouldn’t really have a performance issue in practice unless you were doing something else bad, like having extremely deep DOM trees with extremely large numbers of elements.
> 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?
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?
> 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)
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.
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.
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.
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.
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.
Calling it "Twitter's HTML Source" or "Twitter's HTML Source Code" would be reasonably clear. But just saying "Twitter's Source Code" does imply something other than that, probably non-public backend code, you're right
That would make me wonder about the interviewer's experience. That's not a feeling you want to have at the start of an interview
I mean, right clicking my browser shows "View source code".
Are we going to giggle about how those dumb browser developers don't know that it's not actually the application server source code, or can we admit it's the source code of the rendered page, a different layer of the stack?
Is it really that much of a mistake to shorten "Twitter's [html] source code"?
Frankly, I think a bigger pedant could come in here and correct you.
At least one major researcher studying programming (and how people learn to program) would agree with you!
Check out Alan Blackwell's "What is programming" paper from 2002. In it, he argues that we should not be asking "is writing html programming", because that question comes from an older (past overdue for revision) mental model of what programming is all about.
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.
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.
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...).
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.
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.
"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.
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.
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.
> 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:
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.
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.
> HTML is supposed to be <html><head>head stuff</head><body>body stuff</body></html>.
It’s not. Every single part of what you quoted is optional, and you didn’t include the parts that are actually required.
This is a complete, valid, correct HTML document:
<!DOCTYPE html>
<title>…</title>
…
> But in practice you see […] missing HEAD sections […] missing BODY sections
You never see this, ever. It’s not possible to have an HTML document without a <head> or <body> element. The document I listed above has one <head> element and one <body> element. Both the opening and closing tags for these elements are optional. When an HTML parser parses that document, it will construct a DOM with those elements in it.
> If you omit all those tags, it still works, mostly.
Omitting these tags works completely. This is valid HTML that follows the HTML specification correctly without any need for error handling. All browsers follow these parsing rules without any problems.
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.
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.
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.
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.
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.
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.
Knowing what a <html> tag is is very far from trivia. If someone fails to answer at least ~7 of 10 questions in this interview, there's really no point in continuing on. I'd call it an excellent filter.
315 comments
[ 3.9 ms ] story [ 132 ms ] thread[EDIT] - they said "untechnical", not unethical.
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.
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 :)
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.
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 :)
At least Twitter has the decency to mark their proprietary standards as proprietary.
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.
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?
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?
Thanks for taking me to school.
I guess it'll disappear eventually and become an opt out rather than an opt-in, but not sure if we're there yet, IE11 has been a major drag on progress.
The HTML5 string basically says "I promise to be good, please turn off your weird workarounds". Of course, HTML5 has been around long enough that some browsers still have certain quirks, but they're not as extensive as the ones before HTML5.
Compared to the `<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">` monstrosity from before, I'll happily take the modern standard. There's no version number anymore, just a simple HTML identifier.
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.
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?
> 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.
> 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.
I see this too often. A developer (usually more towards the junior end) who think they can just chug through any problem. Trying this, then that, then google, then that again. When, if they would just stop and think through the problem - and use their eyes - they would see the solution was there all along.
Devil's advocate - is it? You're right, this stuff rarely gets touched, and (aside from changing the colours in the bit you hate!) it's the kind of stuff I'd normally boilerplate between projects.
But if you're interviewing for a role and you're not giving them a coding test (yet?) but looking to see how curious they are, how disparate their knowledge is, or just (as you say) how good someone is at guessing from context - isn't this a fun experiment?
I'd imagine just seeing how people deal with the answers gives you a good idea as to how they'd approach something when you're working together. Are they guessing? Confidently wrong? Seen it before but don't know what it is? Can roughly talk around it and what it does without exactly knowing? Proficient in it all (and how that relates to what they have or haven't said on their CV - have they under or over sold themselves?!)?
I assume you could apply the same sort of test to any domain - test someone on something closely related you don't necessarily need to know and see how they react.
Of course you can then ask a different question, follow-ups, and so on, but you're so far off baseline compared to most candidates that the question starts to become useless.
The point is to ask a few randomly sampled knowledge questions to measure how well rounded the candidate is. Taking the "first 10 lines of Twitter" is just one way to sample such questions.
If you have specific pieces of technology you're working with and want to interview about then take an afternoon and just code up some bizarre snippets to go through with them - add a few mistakes they should be able to catch and just talk through their process.
I honestly don't think opening up a random website and asking about some of the source code is a terrible approach... if you're interviewing someone for writing HTML in the 90's - in the modern world all the JS is minified (and likely generated by a framework), the CSS is absolutely atrocious to read (usually also generated) and the HTML is pretty much irrelevant. Use something that's going to be applicable to candidates to judge their understanding - I've always been fond of short puzzles very much unlike this one (it's way too arcane) in PHP `0x5 &$var=['cow' => 6]['cow']`[1] - just blerbs where you can step through some syntax understanding and problem solving at the same time.
An actually good suggestion is to check out a random (ideally mostly self-contained) file from your codebase from a decade ago and step through what's awful about it - all code bases have these, and they're usually still kicking around as active code in production. At one of my more recent interviews they sent me login.php (the one actually in production, which they knew was broken - they had two developers before me which were really overworked) and just asked me to mark up wrong stuff - I found SQL injections, unbound variables, conditions that would result in invalid HTML and broken forms and some terrible decisions from a readability perspective. I spent... maybe an hour on it.
1. https://3v4l.org/85MV3
I am not sure this is well grounded in the studies of human psychology.
A lot of companies are far too hesitant to trust employees, but blind trust is unwise - you can end up with an employee that either wastes three months salary or actively causes damage.
There is a ton of well researched psychology work on self deception, confirmation bias, it goes on and on.
Asking about the things that the OP was mentioning are deep psychological traps. Perhaps the OP has deep self awareness, but that does not apply to the general candidate or human.
Our blind spots of our own actions and behaviors are profound.
Have things changed so much that knowledge of meta tags is specialist now?
Assuming this interview was for a front end role that is.
Yes. More or less all web development now involves generating HTML with a language that compiles to javascript and a framework. No one even looks at, much less directly interacts with, fundamental web code anymore, and HTML has become esoteric "low level" knowledge like assembly language.
Like take the open graph meta tags for example, for certain websites it'd be a big oversight to leave them out because you never bothered to learn what they were.
I don't know if all this makes for a decent interview. Just blows my mind that people deem it too low level to have to care about, but what do I know anymore, it's been a real long time since I made a web page.
FYI you can disable the coloring as well as the "compact" layout that mushes the URL bar into the active tab and hides its <title>
https://www.macrumors.com/how-to/safari-macos-turn-off-websi...
Much better. No more wild recoloring of my browser chrome because I switched tabs.
> FYI you can disable the coloring as well as the "compact" layout that mushes the URL bar into the active tab and hides its <title>
Did that day-1 with the new Safari. That part was wholly intolerable, not just ugly and annoying.
I assume this isn't the only question OP asks in their interviews, but I think it's got a couple of good outcomes and returns a lot for the length of time it takes to go through.
- https://github.com/kevinSuttle/html-meta-tags
-- Robert A. Heinlein
This is the equivalent of interviewing for a C developer by letting him explain a Makefile.
It's that the signal you're gonna get out of such an interview is gonna be so low that whoever you end up hiring is mostly going to be due to chance + how much you "liked" them.
What if that C++ dev primarily uses visual C++ and Visual studios projects? What if the C++ dev primarily used Cmake, ninja, or scion (or any of the other thousands of C++ build tools).
What if that C++ dev never really needed to start a project from scratch?
The issue is testing someone on minutia doesn't tell you anything about how capable they are. In particular, testing them on minutia that they very likely rarely interact with is beyond pointless.
Then it's an opportunity for the candidate to explain the tools they do use.
There are certainly bad interviewers out there who misuse these kinds of questions, but I think they're fine if used as conversation starters.
But to the point, I'm not sure if the code at issue would be considered minutiae or not, but I believe that the more curious you are, the more you tend to dig into the details, and a person doing this over many years would attain a rich knowledge-base spanning depth and breadth. I know as a java developer that I've referred innumerable times the docs for the POM and settings structure in order to explore the limits of customizing my build, which would include the rather obscure features. Not saying this is technically comparable to meta tags in html, but maybe that's what the author was going for.
When would you actually create such tags as a fullstack dev? Almost never. 90% of the time, those tags are auto generated by some boiler plate app.
A person that can answer correctly MIGHT be someone that's looked into those tags and done things the hard way, but is that really someone you need to hire? A person that answers incorrectly doesn't necessarily seem like someone I wouldn't hire. After all, what do I care about someone knowing the intricate details of the "html" tag and how it interacts with various browsers? That's write once and forget sort of code.
If you wanted this test to mean anything, why are you picking worthless trivia. Why not, instead, pick something like a function out of jquery or your own code base and ask the same question "Tell me what this function is doing".
The point does not at all seem to be "Aha, gotcha! You didn't know about the syntax for Apple's limited PWA like functionality offhand in an interview. 5 demerits, next question!".
A person that can hold a good discussion around these tags is both likely to be one that has truly been developing pages for a couple of years and has an interest in learning more than how to make their framework work rather how to make any framework work in a browser. If you're not able to say something cursory about language attributes I'm going to have a hard time believing you've full-stacked a multi-language website (not that I wouldn't but it'd lead to a lot of different questions later). If your response about the doctype line is "it's boilerplate put in by my IDE" my first thought isn't going to be "oh they just spend a lot of time writing code in the rest of the page" it's going to be "they either don't care what the first line of the page is about or it's been so long since they've touch the front end directly they can't say anything about the first tag. I wonder how well they can deal with integrating the front end JS with the page" and steer to towards more about that.
Also the interview was mentioned to be an hour long, if 10 lines of HTML boilerplate, most of which should be on every page, is too far into the weeds of front end time wise then I'd have severe concerns the candidate would be too back-end heavy. Yes, other things should be talked about too, that's why the interview is an hour and this singular question is only about 10 lines.
Well, that's a problem. If you don't know how to create a web page with out having to fall back to using "some boiler plate app", I question if you really are a fullstack developer (I would also question if you really can consider yourself a web developer at all, but I know that will just upset people, so I won't go there).
---
<!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 parse...
> People even used to use * { margin: 0 } which is totally overkill and not great for performance.
Wait why would that be bad for performance? Zero margins should be just as fast as 8px margins, and if you have this style in the head section it's not like the browser will have to relayout a bunch of stuff.
Basically * { margin: anything } adds one extra calculation to each element in the page.
Not sure if the performace hit is measurable tough, knowing how much optimization goes into browser engines.
In the case of a single universal selector, there is no performance issue, the selector just matches every element, which is fine.
In modern engines, there is also no performance issue, they JIT compile selectors[0] and do other stuff to be fast. Even old engines wouldn’t really have a performance issue in practice unless you were doing something else bad, like having extremely deep DOM trees with extremely large numbers of elements.
[0] https://webkit.org/blog/3271/webkit-css-selector-jit-compile...
You can guess the encoding after reading a few bytes from the request. Checkout universalchardet from Mozilla or the equivalent Java port: https://github.com/albfernandez/juniversalchardet
By the time the meta tag is parsed, you almost always know the right encoding already.
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?
> 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)
> 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.
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.
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.
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.
That would make me wonder about the interviewer's experience. That's not a feeling you want to have at the start of an interview
Are we going to giggle about how those dumb browser developers don't know that it's not actually the application server source code, or can we admit it's the source code of the rendered page, a different layer of the stack?
Is it really that much of a mistake to shorten "Twitter's [html] source code"?
Frankly, I think a bigger pedant could come in here and correct you.
Check out Alan Blackwell's "What is programming" paper from 2002. In it, he argues that we should not be asking "is writing html programming", because that question comes from an older (past overdue for revision) mental model of what programming is all about.
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.
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.
But to have a discussion about quirky html history would be a fun (I think less stressful) way to spend the time.
(On the other hand, if the candidate had access to a computer, following their process of looking these up might be interesting...).
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.
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.
1. https://www.w3.org/Provider/Style/TITLE.html
2. 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/he...
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
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-ta...
The HTML specification literally gives this as an example of a valid document:
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.It’s not. Every single part of what you quoted is optional, and you didn’t include the parts that are actually required.
This is a complete, valid, correct HTML document:
> But in practice you see […] missing HEAD sections […] missing BODY sectionsYou never see this, ever. It’s not possible to have an HTML document without a <head> or <body> element. The document I listed above has one <head> element and one <body> element. Both the opening and closing tags for these elements are optional. When an HTML parser parses that document, it will construct a DOM with those elements in it.
> If you omit all those tags, it still works, mostly.
Omitting these tags works completely. This is valid HTML that follows the HTML specification correctly without any need for error handling. All browsers follow these parsing rules without any problems.
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.
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.
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.
And remembering the Netscape days and why of each meta “hacks” might be a little tricky even for very senior profiles.