The worst error of your career

There is one question I ask in every interview. People have called it silly. It has never failed me.

“Tell me about the worst error of your career.”

And because it is not a fair question, I go first.

Why I go first

The interview is already asymmetric. One person has the job; the other one wants it. Asking someone to expose their worst professional moment from inside that power gap, without offering anything in return, is an extraction — not a conversation.

So I open with mine.

“In my early years, I deleted a production database.”

I stop there. No rescue story. Not yet. Just the failure, sitting in the room.

This does two things. It lowers the cost of honesty — if the interviewer just admitted to nuking prod, the candidate’s “I deployed the wrong branch on a Friday” is not going to shock anyone. And it reframes the exercise: this is not a test of whether you have failed. Everyone has failed. This is a conversation about what failure taught you.

But there is a third thing it does, and this is the part I designed deliberately: holding the rescue back changes what the candidate feels they need to deliver. If I open with the full arc — disaster, long night, heroic recovery — it becomes a hero story, and the candidate will feel they need one too. They will optimise for drama and resolution. The interesting part disappears.

Failure first is what makes real failure tellable.

What I am actually listening for

I am not listening to the size of the disaster. Dropping a database is not more interesting than shipping a bad default. Bringing down production for an hour is not more interesting than slowly eroding a team’s trust over six months with decisions you refused to revisit.

I am listening to the pronouns.

“I pushed without checking” is one kind of person.

“The junior had merged without telling anyone” is another. So is “the process failed us” and “the tooling wasn’t there yet” and “we were under-resourced.”

Accountability has a grammar. Blame has one too. Ten minutes of storytelling reveals which one someone writes in — it reaches places a reference call rarely can.

But there is a third pronoun, and it matters just as much: we.

“I broke it, and we stayed until it was fixed.” “I missed the edge case, and the team figured out how to recover the data.” That shift — from I in the failure to we in the response — is not a dilution of accountability. It is a sign that someone knows what they owe and what they are grateful for. The error was mine. The save was ours. Not every story has that shape — some failures are solo all the way through, and that is fine. But when the we appears in the right place, it tells me something no other pronoun can: this person belongs to a team, and knows it.

The we that worries me is the one that shows up too early. “We had a miscommunication” when they were the one who didn’t check. “We underestimated the scope” when they were the one who set the deadline. A we that covers the error is not generosity — it is diffusion.

This is not about finding people who flagellate themselves. Self-blame without insight is its own kind of performance — and sometimes the error genuinely came from outside, from an impossible deadline or a scope that was fantasy from day one. I am not looking for someone who will claim ownership of a hurricane. But even then, the circumstances may not be theirs while the choices inside those circumstances always are. What I want to hear is an accurate first person where it belongs, an honest we where it belongs, and the judgment to know which is which. I made this decision, here is what I understood at the time, here is what I missed — and here is what we did about it. The person who can say that is the person who actually learned something. The person who can’t may have had the same experience and extracted nothing from it.

The stories that aren’t theirs

Sometimes the grammar is fine — first person, active voice — and the story still doesn’t land. It takes a few interviews to learn to hear this, but once you do, it is unmistakable: the candidate is telling someone else’s story.

They were in the room when it happened. They remember the details. But as the story stretches past the five-minute mark, the verbs start to drift. “I discovered” becomes “someone pointed out.” “I fixed it” becomes “it got fixed.” “I decided to stay” becomes “we were told to stay.” The pronouns stay in first person, but the verbs go passive — because the candidate was nearby, not responsible.

This is not a gotcha. People borrow war stories without realising it, especially early in their career when they haven’t had time to accumulate their own. But it is a signal. Lived experience sounds different from observed experience, and the difference is hard to sustain for ten straight minutes. The person who was actually holding the keyboard when the data disappeared does not need to reconstruct the sequence — they remember it the way you remember a car accident: every detail, in order, without trying.

What this question replaces

I used to use this question as a tiebreaker. Two strong candidates, similar skills, similar experience — the error question would show me something the rest of the interview couldn’t reach.

That was when the interview was mostly about technical ability.

Now that the machine writes the code, this question is most of the interview.

A coding exercise used to reveal real things: whether someone could debug under pressure, whether they wrote clean code or fought the language, whether they could hold a system in their head. The machine does all of that now, fluently and fast. What it cannot do is decide what to build, know when to stop, or take responsibility when the decision was wrong. Those are judgment calls, and judgment does not show up in a function signature.

You cannot test judgment with a coding exercise. You cannot test accountability with a system design whiteboard. You cannot test how someone behaves when the system is down and the client is on the phone and the fix is not obvious — not by asking them to reverse a linked list.

What you can do is ask them to tell you about a time all of that happened, and listen to how they tell it.

The people I want to work with are the ones whose worst-error story has three qualities: they were clearly there, they clearly own it, and they clearly changed something afterwards. Not a process. Not a policy. Something in how they think or decide or check.

The people I pass on are the ones whose story, no matter how dramatic, has no first person in it. Everything happened. Nothing was decided.

The ending I hold back

At the end, after the candidate has told their story, I finish mine.

I found a way to completely rebuild the data from what survived. Long night. It worked.

The ending matters — but only after the conversation has already happened without it. If I give the ending up front, the candidate hears: your story needs a save. If I give it at the end, they hear: the save exists, but it is not the point.

The point was always the moment before the save. And what I have noticed, across years of asking this question, is that the best answers share something: the candidate gets quieter as they reach it. Not rehearsed-quiet. Just — present. They stop performing the story and start remembering it. The room changes. For a few seconds, they are back at that desk, that terminal, that phone call, and they are telling me what it was actually like to be the person who broke it and had to decide what to do next.

That is what no reference, no exercise, and no résumé has ever shown me.