A note on this archive: an earlier version of this site was lost in a migration, with no surviving backup. This piece is a good-faith recreation of our writing from this period, not a recovered original; its date reflects the period it represents. See about this archive.
I've read a lot of résumés over the years. After enough of them, I've landed on a conclusion that still feels a little heretical to say out loud: the résumé was never really the point.
That's an awkward thing to admit when so much of hiring is built around the document. But the longer we do this, the clearer it gets that a résumé tells you where someone has been — not how they think, and certainly not whether they'll be good to work with.
What the paper can't tell you
A résumé is a list of answers. The work is full of questions nobody has answered yet. Those are different skills.
Some of the most impressive résumés I've read belonged to people who came apart the first time they were wrong about something. And some of the best developers we've ever worked with would have been filtered out by a keyword search — wrong school, unfamiliar company names, a gap where life happened. If our process had trusted the paper, we'd have missed them.
What we look for instead
So we stopped treating the résumé as a verdict and started treating it as a footnote. What we actually try to learn is harder to scan for:
- How does someone reason through a problem they've never seen before?
- Do they ask good questions, or just wait for instructions?
- What do they do when they hit the edge of what they know?
- How do they talk about the people they've worked with?
The most useful interview question we ask isn't technical at all. It's some version of tell me about a time you were wrong about something technical, and what you did next. The answer reveals more about a person than a page of bullet points ever could — whether they're curious, whether they're honest, whether they grow.
The slower, more human way
None of this is efficient. It would be faster to scan for keywords and move on, and plenty of companies do exactly that. But I wrote a while back that the difference between wishing and doing is discipline — showing up for the unglamorous version of the work — and hiring is no exception. The disciplined version is slower and more human: actually learning how someone thinks instead of taking the shortcut the document offers.
We've laid out the practical mechanics of this elsewhere — the steps every company should take before bringing someone on. But underneath the mechanics is a simpler conviction: the best developer on your team might never have made it past an automated filter. If that sentence makes you a little uneasy about how you hire, good. It should.