How to Answer "Tell Me About a Time You Made a Mistake"
Pick a clear mistake you owned, explain how you caught and contained it quickly, took accountability without blaming others, fixed it, and put a safeguard in place so it can't recur. Interviewers test accountability and judgment. Distinguish this from 'failure': a mistake is a specific error, usually recoverable.
What the Interviewer Is Really Assessing
This question tests accountability and how you respond under pressure when something goes wrong — Amazon's "Earn Trust." Unlike 'tell me about a failure' (which is often about a larger missed outcome or wrong bet), a 'mistake' is typically a specific, discrete error — a bad deploy, a wrong estimate, a missed edge case.
The interviewer wants to see fast ownership, clean containment, no finger-pointing, and a durable safeguard. How quickly and honestly you respond to your own error predicts how you'll behave during a real incident.
The STAR Structure
The safeguard at the end is what separates a strong answer from a confession. A mistake with a durable fix that prevents recurrence reads as engineering maturity.
- Situation: The context and the specific mistake.
- Task: What was at stake when it surfaced.
- Action: How you owned it immediately, contained the damage, communicated transparently, and fixed the root cause.
- Result: The recovery, plus the guardrail (test, alert, process) that prevents recurrence.
Sample Answer Outline
This outline shows proactive disclosure ('I think my change caused this') and a concrete preventive guardrail — the two moves that turn an incident into a trust-building story.
- S: "I pushed a config change that accidentally disabled caching on a high-traffic endpoint, spiking database load."
- T: "Latency climbed and we were minutes from cascading failures."
- A: "I saw the alert, immediately recognized my change, and proactively flagged it in the incident channel rather than waiting to confirm — 'I think my config push caused this, rolling back now.' I reverted within ~5 minutes and the system recovered. I wrote the postmortem owning the gap."
- R: "No customer-facing outage. Root cause was that config changes skipped the staging canary, so I added config to the canary pipeline and a caching-hit-rate alert. Neither failure mode has recurred."
Mistakes to Avoid
Shifting blame is the cardinal sin here — the entire question is about whether you own things. Even partially shared mistakes should center your accountability.
- Shifting blame to a teammate, a process, or 'the system' — own it.
- Hiding or delaying disclosure of the mistake in the story.
- A mistake with no preventive safeguard added afterward.
- Choosing something so minor it shows no real stakes or accountability.
- Choosing something that suggests negligence or recklessness with no learning.
ResuMax tailors your resume to each role, scores it like a recruiter, and preps you for interviews.
Practice with the interview coachFrequently asked questions
How is this different from 'tell me about a failure'?
A mistake is usually a specific, discrete error you can fully own and fix; a failure is often a larger missed outcome or wrong strategic bet. You can reuse a story but emphasize accountability and containment here.
Should I admit I caused a production incident?
Yes — a contained incident you caught, owned, and safeguarded against is one of the strongest mistake stories for engineers. It mirrors a real on-call situation.
What if no one else knew about the mistake?
Disclosing it proactively is itself a strong signal of 'earn trust.' Emphasize that you surfaced it rather than hiding it.
How much should I dwell on the mistake itself?
Briefly. Spend most of the answer on ownership, containment, and the durable safeguard — that's what's being graded.