Hiring engineers: notes from a hundred interviews
Algorithm puzzles predict puzzle practice. Watching someone debug a real bug out loud predicts the job — because it is the job.
Somewhere past the hundredth interview, patterns stop being anecdotes and start being data. I've hired engineers who aced the whiteboard and flamed out in a quarter, and engineers who fumbled a sorting question and became the backbone of the team. These are the signals I actually trust now.
What predicts nothing
Memorized algorithm puzzles predict whether someone practiced algorithm puzzles. Framework trivia predicts a subscription to the right newsletters. Neither tells you what happens when this person meets a bug that doesn't have a Stack Overflow answer — which is the actual job.
What predicts everything
- Debugging out loud. I give a real bug from our real codebase and watch the process, not the answer. Do they read the error? Form a hypothesis? Change one thing at a time? That loop is the job, and you can't fake it for forty minutes.
- The questions they ask. Candidates who interrogate the requirements before writing code become engineers who interrogate tickets before building the wrong thing.
- Slope over intercept. Especially for juniors: what did they learn in the last six months, unprompted? A steep learner overtakes a polished CV within a year, every time I've measured it.
Hire for the loop — hypothesis, test, revise — because that's the day job. Everything else is trainable.
The part nobody says at conferences
Your interview is also them interviewing you, and the best candidates have options. We show real code, admit real messes, and say out loud what's broken and what we're doing about it. Honesty filters both ways — the people it attracts are exactly the people you wanted.