Hacker News Reader

Comment by weitzj | Hacker News Reader

I don’t don’t do this kind of questioning. I find it useful to give an open question like:

Design a website with a user login, a password reset feature. And then go on from there.

E.g. talk about how to build your infrastructure. How to protect against CSRF. What is your stance in tokens in the front end. What about sessions. How to do force logout. Which database, why? When to use caching. How would you store Information about a password in a database in a safe manner. Salting hashing.

Synchronous vs asynchronous api. Idempotency. Different database transaction mechanism. How to do monitoring. Why is cardinality important for prometheus. How to do api first design.

This gives the candidate time to shine and I can at least understand where they are. And you can dig deeper.

View on HN

I asked this a lot, and honestly loved these interviews and the conversations that stemmed from it. It turns out many candidates may work on either side of HTTP and be reasonably ok candidates who just happened to not be familiar with this part of the stack. Great candidates understood all this stuff, but not being good there didn't mean the candidate was bad, sometimes only that their strong suit was somewhere else. I think a good interviewer should be good at identifying that sort of "knowledge perimeter" where the candidate is strong.

A lot of this doesn't work with junior candidates, they just don't have the exposure to this stuff in school. Knowledge is really just one part of the equation too.

But what you can find out is that the candidate is honest and will tell you he/she does not know the answer.

In the end you want to work together on things and you want to know how the person ticks.

So a self reflected, honest candidate is good and at least I have the impression you can assess where you would need to provide support /trainings for the candidate, or how self learning would work

What do you change if it's clear that the candidate is completely incapable of doing any of those things? Do you cut it short? Talk them through it step-by-step? Unfortunately I've found that not all candidates who get through a recruiter can do what they say they can, so I keep a question at the very start that eats up maybe 5-15 minutes (sometimes less) for a good candidate, but some very bad candidates spend a full 45 minutes on it and don't finish.

The interview will be very short once you've gone through your questions, that's all. For your 5-15 minute question, I don't know the nature of it, but why don't you just move on with reference to time? I'm sure you have a lot of other questions you should ask. It is on the interviewer to be the timekeeper of the interview.

I was curious about the parent commenter's approach with the sorts of questions they ask as they are more open-ended, but also somewhat knowledge-gated. I was interested in any potentially unique techniques they employ. However, I was not looking to specifically fix anything with how I conduct my interviews.

My first question is a very specific coding question and it's a weed-out question. So if someone doesn't figure it out, they've been weeded out, simple as that. I ensure that candidates don't waste time figuring out nit-picky edge-cases and give appropriate hints when they're utterly stuck, but the question does its job very well.

Reply on news.ycombinator.com