Tell me about a time you made a mistake at work and how you handled it.
answer
- the mistake, one plain sentence
- say I, never we
- who you told, how fast
- containment you personally did
- cost owned, repair landed
basics
~10 sTests whether you own outcomes without hedging. Name one real mistake in I-language, say how it surfaced and how fast you disclosed it, what you did to contain it, and the cost you accepted.
how to answer
5 beats- the mistake, stated plainly in one sentenceOpen with what you did wrong, in the first person, before any context. Setup and framing together should take about fifteen to twenty percent of your airtime — enough for the listener to picture the system, not a tour of it.
- how it surfaced and who you toldSay who noticed, how long after, and the words you used to raise it. If you found it yourself, make that explicit; if you were told, say so without dressing it up. This is the single sentence interviewers weigh most.
- what you did to contain itThe bulk of the answer, roughly sixty percent, lives here. Give the ordered actions you personally took — stop the bleeding, verify, communicate, fix — and keep the verbs singular where the work was yours.
- the cost, owned out loudName the damage in concrete terms: affected users, hours of degradation, rework, or the number that moved. Refusing to quantify reads as refusing to feel it.
- the repair and what you accepted afterwardsClose with the fix landing and any constraint you took on yourself as a consequence. Result and reflection together are about a quarter of the answer; do not let it become the longest part.
your answer
5 story prompts- Pick a mistake you personally caused, ideally within the last two years, with a cost you can name.
- Choose the one you surfaced yourself rather than the one someone else caught.
- Draft the disclosure sentence first: who you told, how soon, in what words.
- Have one number ready — hours of impact, users affected, or the metric that moved.
- This can be the same incident as your biggest-failure answer, re-angled onto what you owned.
draft and rehearse your own answer in a learn session
go deeper
This probes accountability and self-awareness: whether you can hold responsibility for a bad outcome in the first person, disclose it before it is discovered, and act to repair it. A strong answer proves the interviewer can trust your status reports, because you volunteer bad news about your own work rather than manage it out of sight.
I was six weeks into contributing to an open-source checkout library — a backend package that storefronts embed to handle payment retries. My mentor had given me a small change: put a timeout on the retry wrapper. I set it on the wrapper but not on the inner idempotency lookup, so a slow response could fall through into a second attempt, and the shopper saw an error page instead of a confirmation. I found it myself the next morning on the reference storefront dashboard. Conversion had fallen 2.3 points overnight, from 61.8 to 59.5. My first instinct was to quietly push a fix and watch the number come back. I did not do that. I messaged my mentor inside twelve minutes, said in the first line that my change had caused it, and pasted the two lines I had got wrong. She asked me to open the issue in public, which was uncomfortable, and we reverted in under an hour. The dashboard was back to 61.6 by that afternoon. Then I wrote the fix properly, with a test that fails if the inner timeout is missing, and I asked her to review the test before the code. Twelve minutes is the number I would stand behind. I cost the project a bad night of numbers, and hiding it would only have added a second thing to admit.
The signal here is disclosure speed plus ownership language — my change caused it, self-reported, with a stated cost. Naming the instinct to hide it and rejecting it reads as honest rather than rehearsed. Blaming the reviewer, or stopping at the revert with no cost, would downlevel this.
By then I was one of the maintainers on that same checkout library, and a chunk of my week was coaching newer contributors through their first substantial patches. One of them brought a caching change for the tax-quote path. I had walked through the design with them, I liked it, and when the pull request arrived I approved it in about four minutes without running the adopter test matrix, because I had already reviewed the idea in my head. The cache keyed on cart total but not on shipping destination, so a returning shopper could be shown a quote from the wrong region. Two adopters reported their checkout conversion off by 1.4 points across a weekend before anyone traced it back to us. I posted in the project channel on Monday and put it in the first sentence: I approved this, I skipped the matrix, the defect is mine and not the contributor's. That mattered — they were new, and they were about to take the hit in public for a gate I did not run. We cut a patch release inside a day, and I wrote to the adopters directly with the exact key that was wrong so they could check their own exposure. The cost I named out loud was trust. I asked the other maintainers to hold my approvals to the matrix rule for the following cycle, and I told the contributor their patch was sound and my review was not.
Two moves carry this level: pulling the fault off a newer contributor's name publicly, and locating the mistake in a decision the speaker owned rather than in the code. Naming trust as the cost, with a concrete constraint accepted, keeps it from being a polished apology. Vague we-language in the disclosure paragraph would sink it.
Your scope is your own task, and that is enough. Show that you noticed, that you told your reviewer or mentor immediately in your own words, and that you can state what it cost without softening it.
Your mistake touched other people's work, so the story is about handling: the containment call you made, the message you sent and to whom, and the fix carried through to done by you rather than handed off.
Team and production scope. Own the decision that let it through — the review you waved on, the rollout you approved — and say in what order you told people, before it reached them another way.
Own it at organisational scope: the error was yours and so was the condition that allowed it. Show you said that in front of people senior to you and rebuilt confidence rather than defending your judgment.
saying these in an interview costs you the question
- Picking a mistake so trivial that admitting it costs nothing
- Sliding into we when the story turns bad and I when it turns good
- Blaming a reviewer, a vague process, or an upstream team for the outcome
- Waiting to be caught, then presenting the disclosure as courage
- Stopping at the apology with no containment, no fix, and no cost named
- Relitigating why the mistake was reasonable instead of saying what you did next
- Who found out first, you or someone else?The strongest version is that you found it and reported it before anyone asked. If you were caught, say so plainly and move fast to what you did in the next hour — a candid caught-it-late story beats a rewritten one, and interviewers probe here precisely because the flattering version is easy to invent.
- What did it actually cost?Have a real figure ready: hours of degraded service, affected users, rework, a metric that moved and by how much. If you truly cannot quantify it, say what you would measure and give the qualitative cost instead. Never answer that it worked out fine in the end — that reads as never having felt the weight of it.
- How did your manager react?Answer factually and without seeking sympathy or credit. If the reaction was tough, say what was fair in it. Avoid two traps: casting your manager as unreasonable, and implying you were praised for owning up, which turns a mistake story into a compliment you paid yourself.
- Could anything have caught it earlier?Answer for the specific gap, not with a generic call for more testing. Name the check that did not exist or that you skipped, and say whether it exists now and who put it there. Keep it to a sentence or two — the prompt is a probe on your judgment, not an invitation to redesign your process out loud.
## The wordings you will actually hear This prompt travels under several disguises: - what is the biggest mistake you have made professionally; - tell me about a time you had to admit you were wrong; - describe a time you let a teammate or a customer down; - walk me through something you got badly wrong. Prepare one incident that survives all of them, then adjust the emphasis. The interviewer is not collecting your worst moment as evidence; they are listening to the **grammar of your account** — the pronouns, the sequence, and where the story spends its time. ## Choosing the incident is most of the work Calibrate it: a mistake with no cost reads as evasion, and a catastrophic one you never recovered from leaves the interviewer with an unanswered risk. Aim for: - a real consequence you can name in one clause, - an action sequence that is genuinely yours, - and a resolution inside your reach. Recency helps — an incident from the last two years reads as current judgment. Avoid the story where the mistake is really someone else's and your role is noble cleanup; that is a different prompt, and using it here is heard as dodging. ## The pronoun test decides more loops than the incident does Weak answers drift: we did not catch it, the process allowed it, the requirements were unclear. Strong answers hold the first person exactly where it hurts — I misread the config, I approved it, I assumed the fallback path was covered — and then widen to we for the recovery, which is usually accurate because recovery is collaborative. Record yourself once and count the pronouns in the middle third of the story. If they turn plural precisely when the story turns bad, rewrite that section. ## Disclosure timing is the load-bearing detail Two candidates can describe an identical defect and land at opposite ends of the bar because one says the words I flagged it myself within the hour and the other quietly shipped a fix and hoped the number recovered. Interviewers ask this question partly to find out what you do in the gap between knowing and being asked. Put the timing early and explicitly — the sentence you said, to whom, and how long after you knew — rather than leaving it implied. ## Apology and remediation are a pair, and the second half is what is scored An articulate **apology with no containment** sounds like practice at being sorry. **Containment with no acknowledgement** of the harm sounds like someone who experiences their own errors as engineering puzzles. Say both, briefly: this hurt these people this much, and here is what I did in the next hour, the next day, and the following week. ## Weak versus strong, in one contrast **Weak:** I once pushed a change that caused an issue, we rolled it back, and the team learned to test more carefully. There is no first person in the failure, no cost, and no action anyone can picture. **Strong:** I set the wrong retention value in the export job, and I found it the next morning when the report came back empty; I told the owner before the standup, restored from the previous snapshot, and re-ran the job by early afternoon; the cost was a day of stale reporting to two teams, and I asked for the config change to require a second pair of eyes. ## How the bar shifts - **Early on**, the question is honesty and speed. - **In the middle**, it is handling — comms, containment, and finishing the fix yourself. - **Higher up**, interviewers stop caring about the defect at all and listen for whether you own the decision that permitted it, and whether you can say that out loud in front of people whose opinion of you matters.