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.
> I actually really like this and I’m a bit surprised to see all the pushback.
FWIW, I have yet to see any discussion about interviewing on HN that didn't attract a lot of pushback in the comments. It doesn't seem to matter what format the interview is in (technical questions like this, leetcode-style problems, take-home problems), it will attract angry comments on HN and Reddit.
I suspect a lot of this is exaggerated. In the real world I've only ever had a couple candidates decline to do take-home interviews, and that's only because they were 99% sure they were taking another offer at that point. Back when we did in-person technical interviews we never had anyone end the interview early because we asked questions that were too hard (as the top HN comment claims they would do).
Take interview-related commentary on HN and Reddit with a grain of salt.
Probably because interviewing is highly subjective. The advice in this article could be used as part of a great interview or part of a terrible one. It depends on how the interviewer uses it.
No. This is nonsense. Nobody has ever, ever asked me about text-size-adjust or <doctype html> in an interview and I've been working in software since 1999 and I make mid six digits in total comp.
Yes it does. It's these ridiculous hyper-specific questions that make tech interviewing generally awful.
It'd be like me asking what type of lock Postgres 12 awards when dropping an index concurrently. Or how long it takes for an AWS SQS message to time out. These things don't matter at all during an interview for the vast majority of positions. What matters is figuring out if someone understands how to build software. Do they think through realistic problems well. Do they know the difference between memory and disk.
For example, if there is a conditional index that is frequently accessed, but is small, the O runtime doesn't matter because it's for sure going to be in memory. That's the type of thing that can naturally come up during an interview when you ask someone to, say, plan out a social API endpoint. But the question shouldn't start with the hyper specific because at best that tests recall ability and only after many, many questions have been asked. It doesn't test inventiveness, pragmatism, thoroughness, and attention to detail all of which are far more important than random trivia.
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.
You don't know this stuff because you have "memorized" it, like with flash cards or something as some kind of memorization exersize. You know it because you know web technologies.
It's weird to use "memorization" as basically a synonym for "remembered". Being a good developer is not just copy-and-pasting things from google, it involves actually understanding some technologies. Understanding technologies is not "memorization".
I don’t think of this as rote memorization tho. This is about, can you read, identify, and explain the different parts. Now, you might not think that is a good test to see if someone is competent or not — and I’m not going to pretend it is perfect. But as these things go, I don’t think it’s a bad starting point.
I could explain nearly every one of those ten lines (and again, I’d have to see to full origin-trials line to know for sure, but I’d say there is a 70% I could infer/BS the answer), not because I’ve memorized anything but because I’ve spent years writing and reading this sort of thing.
Now, if you asked me to write the first ten lines perfectly without any mistakes or use of code completions or boilerplate, I would almost assuredly fail. To me, that’s a stupid memorization test. But asking someone to explain why something is there and what it does, I don’t think that’s the same thing at all.
But for the job in question, this kind of stuff isn't memorisable factoids.
Knowing what these 2 tags are for is fundamental, the wording of the attributes are vaguely self-descriptive, and recognising CSS from HTML is instinctive.
You can't "get stuff done" without being able to at least bullshit the basics.
And BS-ing through it is exactly one of the red flags I'd be looking for as an interviewer.
I don't want people who tell me "it's all under control" and "I know this" and then the result is a disaster. I want people who tell me "I know X and Y but I'll have to look up Z". Tell me that you don't know but are assuming, then show me your reasoning skills by "BS-ing your way through it".
Yeah, I had some great results in the past with "I'm not familiar with that, but if I were to take a guess I'd say ...".
Shows you're not a bullshitter and is capable of reasoning about stuff. Good qualities for people I want to work with.
Also, if I have the least bit of doubt about what I'm going to say, I always start with "not really sure about that, but ...". Might seem weird at first sight to be a candidate who is not sure about anything, but it shows you can recognize your own lacks(and look it up if needed), shows you're humble, and usually scores some extra points when you still get most answers right even if you were not so sure.
Absolutely. I think about this as, one of the things we communicate with our speech is our confidence. (Likelihood that some claim we make is correct). Speaking confidently about something you don’t know is epistemic lying. And seeing a candidate lie to me is a red flag in an interview.
It’s also really stupid. An interviewer wouldn’t ask a question like this unless they knew what every line of code shown does. By all means say “I think this does X, but I’m not sure”. But if you boldly tell me it does X when I know for a fact you’re wrong, that will go badly for you.
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.
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.