Leetcode interviews don't find good engineers
The whiteboard puzzle is a bad filter. Here's what it misses, and what I'd do instead.
I’ve spent a lot of my career on both sides of the coding interview, and I’ve landed on a blunt opinion: the leetcode-style screen is a bad way to find good engineers.
It’s not that the people who pass are bad. Plenty are excellent. The problem is what the format actually measures, and how little that overlaps with the job.
What leetcode tests
A timed algorithm puzzle rewards a narrow bundle of skills. Matching a question to a known trick, recalling the trick quickly, and writing it cleanly while someone watches. That is a real skill. It is also, mostly, the skill of having done a lot of leetcode recently.
What the job actually is
Now think about a normal week of real work. I read far more code than I write. I spend time figuring out what a vague request really means. I debug something that only fails in production. I make a call with incomplete information and leave a note explaining why. I review someone else’s change and catch the thing they missed. I decide what not to build.
Almost none of that shows up in a 45-minute “invert a binary tree” session. The interview measures sprinting when the job is mostly navigation.
The part that made me lose faith
Here is what really did it for me. I got annoyed enough at the format that I spent a weekend building a proof of concept: a small desktop overlay that quietly reads the screen and suggests an answer. It worked. It took a weekend.
I am not releasing it, and I would tell you not to use it. The point is not the tool. The point is that if a hiring format can be defeated by a weekend hack, it was never really testing what it claimed to. It was testing whether you prepared for that exact format, which is a different thing from being good at the job. There is a whole cottage industry of these tools now. That should tell us something about the format, not about the candidates.
What I’d do instead
I don’t think interviewing is hopeless. I think it should look more like the actual work:
- Look at real code the person has written and talk through it. Why this way, what they would change now.
- Give a small, realistic task and let them use their normal tools, including the internet and an AI assistant, because that is how they will actually work.
- Debug something together. Hand them a failing repo and watch how they think, not whether they have memorised Dijkstra.
- Talk through an ambiguous problem and see if they ask good questions before writing anything.
None of this grades as neatly as a leetcode filter. That is the real reason we keep using leetcode. It is cheap and easy to score, not because it is good. I would rather spend more to get the signal right.
So
If you are hiring, please stop using the puzzle as the whole bar. If you are a candidate grinding leetcode, I am sorry, the game is real even though it is silly, so play it, but know it is not a measure of you.
I would rather work with someone who reads code carefully, asks good questions, and ships, than someone who can invert a binary tree from memory in four minutes. Most days, those are not the same person.