How to Answer "Tell Me About a Time You Made a Mistake at Work" (With Sample Answers)

The instinct here is to find the smallest possible mistake and get past the question quickly. That instinct is wrong, and interviewers read it easily. A trivial mistake tells them either that you've never owned anything consequential or that you aren't willing to be honest with them.

The counterintuitive truth: candidates who describe a real, costly mistake and how they handled it consistently score better than candidates who describe a small one. What's being tested is your relationship with your own errors, not your error rate.

What the interviewer is actually testing

Do you notice and admit mistakes? The alternative — mistakes that surface weeks later from someone else — is genuinely expensive.
Do you tell people immediately? Almost every serious workplace failure is a small mistake plus a delay in reporting it.
Do you fix the cause or just the symptom? The difference between someone who corrects the spreadsheet and someone who asks why the spreadsheet was reachable.
Can you talk about failure without spiralling or deflecting? Both extremes are warning signs: the candidate who is still visibly ashamed, and the candidate who explains why it wasn't really their fault.

Choosing the mistake

You want the middle band. Aim for a mistake that was genuinely costly, clearly yours, and about judgement or process rather than character.

Safe territory: shipped a bug, misread a requirement, underestimated a timeline, made a call with insufficient information, went too far solo before checking in, over-promised to a client.

Off limits: anything touching honesty, discrimination or safety. Nothing you're currently in dispute over. And nothing where the honest telling requires you to blame a specific named colleague — even if true, it plays badly.

A structure that works

The mistake, stated flatly, first. Don't build up to it with three minutes of mitigating context. Leading with the admission is itself the signal.
The impact, honestly. Including the cost.
What you did in the first hour. Who you told and how fast. This is what interviewers are most listening for.
How you fixed it.
What you changed so it can't happen the same way again. The systemic fix separates good answers from adequate ones.

Sample answers

Sample 1 — engineer, production incident

"I dropped a database index in production thinking I was on staging. Two terminal tabs, wrong one. Search latency went from 200ms to about nine seconds and the site was effectively unusable for around twenty minutes.

I said it in the incident channel within about ninety seconds — 'I did this, here's exactly what I ran' — which I think mattered more than anything else I did, because it meant nobody spent time debugging a mystery.

Rebuilding the index took eighteen minutes and we were fine after that.

The fix I actually care about is what came after. In the postmortem I pushed against the conclusion that I should be more careful, because 'be more careful' is not a control. We made two changes: production shells got a bright red prompt with the environment name, and destructive schema operations required a typed confirmation of the environment. Two other engineers told me afterwards they'd nearly done the same thing.

I'd rather have not done it. But I'd rather that class of accident be impossible than rely on everyone being alert at 6pm."

Sample 2 — early career, client-facing

"I sent a report to a client with last quarter's figures in it. I'd duplicated the previous file to save time and updated the narrative but not two of the tables.

They noticed before I did, which is the part I still find uncomfortable. My manager forwarded me their email.

I called the client within ten minutes rather than emailing, told them exactly which two tables were wrong and what the right numbers were, and sent a corrected version that afternoon with the changes marked so they didn't have to hunt.

My own change was to stop duplicating old reports. I built a template that pulls the figures directly from the source, so the numbers can't be stale. That's been used by the whole team since.

What I learned is that the recovery is a bigger variable than the error. The client's confidence came back because the correction was fast and complete, not because the mistake was small — it wasn't."

Sample 3 — judgement error rather than an accident

"I committed our team to a delivery date in a meeting with the VP without checking with the engineers first. I'd done the estimate in my head based on a similar project and I was confident. I was wrong by about six weeks.

This is the mistake I'm least comfortable with because it wasn't a slip — it was arrogance, and it cost my team a bad quarter.

Once it was clear the date was wrong I raised it as early as I could rather than hoping for a recovery, which was about five weeks out. We re-planned and cut two features rather than moving the date, because by then the date had dependencies attached to it.

I now have a rule I don't break: I don't give a date in a meeting. I say I'll come back within twenty-four hours, and I ask the people doing the work. It has cost me nothing and I've not missed a committed date since."

Sample 4 — mistake caught before impact

"I misconfigured an email campaign so that a discount offer intended for a segment of about 2,000 lapsed users was queued to go to our entire list of 90,000, including active subscribers who were already paying full price.

I caught it during a final check about fifteen minutes before send, purely because I glanced at the recipient count and it looked wrong.

I want to be honest that this one is a near miss rather than a disaster, and the reason I raise it is that I treated it as though it had happened. I told my manager even though nothing went out, because the interesting thing wasn't the error, it was that our process had let it get to fifteen minutes before send.

We added a rule that any campaign over 10,000 recipients needs a second person to confirm the segment. Six months later that check caught someone else's mistake."

Common mistakes

Choosing something trivial. A typo doesn't answer the question and the evasion is obvious.
A "mistake" that's secretly a virtue. "I took on too much and burned out" is not what was asked.
Blame, however subtle. "The requirements weren't clear" moves the mistake off you and the interviewer notices.
Hiding the cost. Vagueness about impact reads as minimising.
No systemic fix. "I double-check now" is weak; a change to the process is strong.
Excessive self-flagellation. Still visibly upset about something from four years ago suggests a difficult reaction to future errors.
Claiming you can't think of one. Read as either dishonest or inexperienced.

Follow-up questions to expect

"How quickly did you tell someone?" — The core of the question. If the honest answer is "not fast enough", say so and say what you'd do now.
"How did your manager react?" — A measured account of a reasonable reaction is fine; if it was harsh, describe it without bitterness.
"Has anything similar happened since?" — The test of whether your fix worked.
"What's the biggest mistake you've made?" — Sometimes asked as an escalation if your first example seemed small. Have a second, larger one ready.