Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

> 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.

View on HN

Exactly. I think this question is fine. But every question ever asked here gets mocked as stupid by the subsection of people who think its stupid.

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.

Thats why it was posted... because it's a novel interviewing technique. It has nothing to do with how much you make.

Congrats, man. That's how much I made too and no one asked me either. Doesn't make it a bad question.

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.

Reply on news.ycombinator.com