Learn

Your story about a mistake should contain a mistake you made

23 October 2026 · Behavioral: your part of the story

"Tell me about a time you got something wrong." You have a story ready, and it is a real incident. Halfway through, you notice that in your version nobody actually made a mistake: the requirements changed, the reviewer missed it, and the lesson was that communication matters. The interviewer writes nothing down.

The situation

The mistake question is not a trap about whether you have ever failed. Everyone has. It checks three things a team needs to know before trusting you with production: whether you can name your own call without hiding it, whether you understand why it was wrong, and whether it changed what you do. A story that cannot answer all three sounds safe and scores badly.

There are three common ways to dodge it without meaning to. The humble brag, where the mistake is working too hard. The passive story, where the mistake happened to you. And the platitude ending, where the lesson is a value ("be careful", "communicate more") instead of a habit someone could watch you follow.

What goes wrong

Here is an invented story of the passive kind:

Last year we had an outage when a migration locked the orders table. The ticket said it was a small change, and it passed review. We rolled it back within the hour, and the lesson was that communication matters.

Put one follow-up to it: "What would you do differently?" The honest answer has to be something about you, and the story has given you nowhere to put it. The ticket and the reviewer carry the blame, and "communication" is not something anyone can check.

Now the same incident, told by the person who made the call:

I wrote a migration that added a column with a default to our orders table, and I ran it in the afternoon because it had taken seconds on staging. Staging had a few thousand rows. Production had tens of millions, and on the database version we ran, that statement rewrote the table under a lock. Checkout writes queued for about ten minutes before I cancelled it.

The mistake is now visible and specific: trusting a timing from a table a thousand times smaller. Nobody else is blamed, and nothing is dramatised.

What to say out loud

The shape is five short moves: what I did, what I missed, what it cost, what I changed, and when the change paid off. The last two carry the score.

Since then, before any migration on a large table, I check the production row count and I split the change into three steps: add the column without a default, backfill in batches, then set the default. Two months later I spotted the same pattern in a colleague's migration during review, and we batched it instead.

That ending is a habit, not a value. An interviewer can picture you doing it on their team. It also gives a second piece of evidence, a later occasion where the habit mattered, which is far stronger than saying you learnt your lesson.

Expect one more follow-up: "Could you have known at the time?" Have an honest answer. Here it is yes: the row count was one query away, and you did not run it. Saying so calmly is the point of the question.

Avoid inventing numbers you did not measure. "About ten minutes" is fine if that is what you remember. A precise figure you cannot defend will be the next question.

The exercise

1. Write down the mistake story you would tell today, unedited. Circle every sentence whose subject is not you: the ticket, the reviewer, the team, the deadline.
2. Find the one decision that was yours. If you cannot, the story is about someone else's mistake; choose another.
3. Write what you missed as a signal you could have checked at the time, in one sentence.
4. Replace the lesson with a habit: something you now do, on a trigger, that an observer could see. Then add one later occasion where you used it.
5. Retell the story aloud from memory in under two minutes. In three days, do it again without notes and check whether the habit sentence survived.

Where this fits in Gadfly

Gadfly has four rooms: algorithms, system design, behavioral and code review. The behavioral room keeps a bank of your stories, separates the competencies a story claims from the ones it actually earns, and asks you to retell a story later, as in the last step above. Its report is a set of observations made by rules over what you said, not a hiring prediction.