Competencies
Owning a Failure
Naming a real failure specifically, containing it, and showing a change that outlived the incident.
The prompt
Tell me about a time you failed.
A near-default opener for the behavioral round at almost any company — often the very first question asked, since it's a fast filter for genuine ownership versus a rehearsed non-answer.
What the Interviewer Is Listening For
Whether you take real ownership of what went wrong instead of deflecting blame outward, whether you can name specifically what happened rather than a vague "it didn't go as planned," and whether something concrete actually changed as a result — not just an apology and a return to normal.
Situation
Shipped a caching change meant to cut database load on a high-traffic endpoint, rolled out during a normal deploy window.
Actions
The change introduced a race condition under concurrent writes that occasionally served a stale value for a few seconds — it wasn't caught in code review or staging, because staging traffic was too low to trigger the race reliably. It surfaced in production as a spike in a "stale data" support ticket category about two hours after deploy. I rolled the change back within twenty minutes of the alert firing, then wrote a targeted concurrency test that reproduced the race locally before shipping a real fix the next day.
Outcome
I also proposed load-testing concurrent writes as a standard step for any caching change on the team going forward — which caught a similar issue in a teammate's PR two months later before it ever reached production.
Why This Lands
The failure is named specifically — a race condition under concurrent writes, not "a bug" — which is the difference between a story an interviewer can actually evaluate and one they can't. Containment (the rollback) is shown as separate from the fix, which is the right order of operations under real incident pressure. The outcome section shows a durable process change that later caught an unrelated bug, which is the evidence that this wasn't a one-time apology.
Common Failure Modes
Variations of the Prompt
"Tell me about a mistake you made," "describe a time a project you led didn't go as planned," and "tell me about a time you had to deliver bad news about your own work" are all asking for the same underlying story — genuine ownership of something that went wrong, and what changed afterward.
Follow-Up Questions
Interviewer:You said the fix shipped 'the next day.' What was happening to the endpoint between the rollback and the fix — was it degraded that whole time?
No — the rollback specifically restored the known-safe state, so the endpoint was back to its pre-change behavior (higher database load, not broken) immediately. "The next day" describes time spent writing a correct fix, not time the endpoint spent degraded.
Interviewer:Whose decision was it to roll back within twenty minutes, rather than trying to hotfix forward under pressure?
Mine, and it's worth naming as a deliberate call rather than indecision. Under active incident pressure, returning to a known-good state is safer and faster than debugging a race condition live in production — a hotfix attempted under that same pressure risks shipping a second, worse bug.
Interviewer:The teammate whose PR the load-testing step caught two months later — did they know it was because of your incident?
Yes — attributing the process change explicitly when introducing it, rather than only mentioning it afterward, is part of what makes it read as an intentional system improvement rather than a coincidence.
Try It Yourself
Try it yourself
Write your own three-sentence Situation using a real failure from your experience, then check whether your Action section names the specific technical thing that went wrong — not "a bug" — the same way this example names "a race condition under concurrent writes."