To answer “Tell me about a time you failed,” pick a real work failure where your own decision caused a meaningful miss, own it in one plain sentence without blaming anyone, and spend most of the answer on what you learned and the specific habit you changed afterward. Interviewers are not grading the failure itself; they are grading your ownership, how you recovered, and whether the lesson stuck. Keep it to about two to three minutes and finish with a later moment where the new habit paid off.
What the interviewer is actually checking
Every engineer has shipped a bug, blown an estimate or built the wrong thing. The question assumes that; what it measures is how you behave when it happens. Amazon's recruiters put it plainly: “It's okay to talk about failure.” They suggest preparing examples that show how you have taken risks, succeeded, failed and grown.
| Signal | A strong answer shows | What sinks it |
|---|---|---|
| Ownership | You name your own decision as the cause | “The requirements changed” or “QA missed it” |
| Self-awareness | Why the call made sense at the time, and where your judgment slipped | A vague lesson such as “communication matters” |
| Recovery | You limited the damage, told the right people quickly and fixed the root cause | The story ends the moment things broke |
| Growth | A concrete habit you adopted, and a later time it worked | “I learned a lot” with nothing that changed |
| Candor | A failure with real stakes | A humble-brag like “I care too much about quality” |
Amazon's interview advice tells candidates to think about their successes and failures in relation to its Leadership Principles. A failure story maps naturally to three of them: Ownership (no deflecting responsibility), Learn and Be Curious (always improving) and Earn Trust, which asks leaders to be openly self-critical even when it is uncomfortable. Our Amazon behavioral interview guide covers how stories get mapped to principles.
How to choose the right failure
The story you pick does most of the work. Run each candidate through five filters:
- It was really a failure. A missed deadline, launch, requirement or uptime target, or a design you had to throw away. A project getting deprioritized is a disappointment, not a failure.
- Your decision caused it. You need a specific action or omission that was yours, not a team failure you watched from the side.
- The stakes were real but recoverable. A typo in a pull request is too small; a security lapse you kept quiet about is too big.
- It is resolved, and you changed something. If it is still unfolding, or nothing changed afterward, pick another story.
- It fits your level. Use the table below.
| Level | Failures that fit | Typical scope |
|---|---|---|
| Intern / new grad | Misread requirements, a blown estimate, waiting too long to ask for help | Your own task or feature |
| Mid-level | A production bug or incident you caused, a missed sprint commitment, an untested assumption | A feature or a service |
| Senior | A design or technology choice that did not hold up, a launch you led that slipped, a risk you did not flag | A system or a multi-engineer project |
| Staff / tech lead | A cross-team initiative that stalled, stakeholders you failed to align, a strategy call you had to reverse | Several teams or an org-wide decision |
Level expectations vary by company, so treat the table as a starting point. Calibration cuts both ways: a staff candidate whose biggest failure is a missing unit test sounds like they have never worked at that scope. Avoid stories involving dishonesty or a policy violation, and anything you still quietly blame on a colleague. Prepare a backup with a different theme, since some interviewers ask for a second one.
The STAR+ structure: STAR plus learning and change
Plain STAR (Situation, Task, Action, Result) tends to end a failure story at its worst moment. Add two beats so it ends on growth instead of damage. The percentages are our rough guide to pacing, not any company's rubric:
| Part | What to say | Share of answer |
|---|---|---|
| Situation | The project, your role and why it mattered, in one or two sentences | ~10% |
| Task | What you owned and what success looked like | ~10% |
| Action | The decision you made, how it went wrong and what you did once you saw it | ~30% |
| Result | The honest outcome, with real numbers if you have them | ~10% |
| Learning | The root cause in your own judgment, not just in the system | ~20% |
| Change | The habit or guardrail you adopted, and a later time it worked | ~20% |
Two rules make it work. Name the failure plainly and early: “I ran a migration that caused 25 minutes of failed orders” beats three sentences of hedging. And say “I” for your own decisions. Amazon's interview advice stresses hearing what you personally did, backing answers with data, and keeping each response to four minutes or less.
Treat it like a postmortem with your name on it. Google's SRE book describes a postmortem as a written record of an incident covering its impact, the actions taken to mitigate it, the root causes and the follow-up actions that prevent a repeat, written without blaming individuals. Borrow that shape: blameless toward everyone else, fully accountable for your own part.
Four example answers, from intern to staff
These are illustrative stories; the details and numbers are invented to show the shape of a strong answer. Use your own story and real numbers, and practice from bullet points rather than a script.
Intern or new grad: building the wrong thing
Situation and task. In my internship I owned one feature end to end: adding reporting to an internal operations dashboard.
Action. I decided charts were the most useful kind of reporting and spent four weeks building them without showing anyone, because I did not want to bother my mentor with unfinished work. At my midpoint review, the operations lead explained they needed filtered CSV exports for a weekly audit. Nobody would have used the charts.
Result. I had spent almost half the internship on the wrong feature. I shipped the export in the time left, but the charts never launched.
Learning. I treated asking questions as a cost and assumed I understood the users without talking to them.
Change. I now get a short written spec confirmed before I start, and I demo something every week, even when it is rough. On my capstone project that habit caught a data-format misunderstanding in week one instead of week five.
Mid-level: a migration that caused an incident
Situation and task. I owned a schema change on our orders service: adding a column and backfilling it for existing rows.
Action. The backfill finished in seconds on staging, so I started it in production mid-afternoon. Staging held a tiny fraction of production's data. The job held locks far longer than I expected and order requests began timing out. I stopped it, posted in the incident channel exactly what I had changed and when, and stayed on until error rates recovered.
Result. Customers saw failed orders for about 25 minutes. No data was lost, but it was a real outage, and I caused it.
Learning. I assumed “worked in staging” meant “safe at production scale.”
Change. I wrote the postmortem, rewrote the backfill to run in small batches, and added a migration checklist to our pull request template: estimate row counts, batch writes, run off-peak, keep a kill switch. My next three migrations went through it without an incident, and two neighboring teams adopted it.
Senior: a build-versus-buy call that did not hold up
Situation and task. As the senior engineer on a platform team, I decided we should build our own job scheduler instead of adopting a managed service, because of a few unusual retry requirements.
Action. The build went fine; running it did not. Within months the scheduler was our largest source of on-call pages: retry edge cases, clock drift, unplanned upgrades. I had compared features carefully and barely weighed maintenance cost.
Result. I proposed reversing my own decision and led the move to the managed service, which covered our retry needs with a thin wrapper. The detour cost roughly a quarter of one engineer's time.
Learning. I optimized for the interesting problem and underweighted the boring one: who keeps this running at 3 a.m. for the next three years.
Change. My design docs now include total cost of ownership for every option and an explicit “we will revisit if” condition. When we later evaluated a caching layer, that section is what steered us to a managed option from the start.
Staff or tech lead: a cross-team migration that slipped
Situation and task. I led the deprecation of an internal API used by six teams, with a deadline tied to the end of a vendor contract.
Action. I treated it as a technical project: a solid design, a working replacement and a migration date announced to all of engineering. I never got the consuming teams to put the work on their roadmaps, and two had already committed their quarter elsewhere.
Result. We missed the date by a full quarter and had to extend the vendor contract. Once the miss was clear, I went to my director with a revised plan before the date slipped publicly.
Learning. For cross-team work, alignment is the critical path, not the code. I had a plan; I did not have commitments.
Change. I now get explicit sign-off from each owning team's lead before announcing any date, and I ship compatibility shims so teams can migrate on their own schedule. The next deprecation I led, across eight teams, finished ahead of its date.
Prepare for the follow-up questions
Good interviewers dig in. Have a response ready for each:
- “Why didn't you catch it earlier?” Give the honest reason (an assumption, time pressure, a tooling gap) without making it an excuse, then point to what you changed.
- “What would you do differently?” Tie it to the decision point, using information you could have had at the time.
- “How did your manager or team react?” Describe it factually, including how you rebuilt trust if someone was frustrated.
- “Has anything like it happened since?” The best answer is a later case where the new habit caught a similar problem early.
- “Tell me about another failure.” Use your backup. If the first story was technical, make the second about communication or prioritization.
Mistakes that sink failure answers
- The humble-brag. “I worked too hard” or “I'm a perfectionist” reads as dodging the question.
- Blaming someone else. Even if a teammate or fuzzy requirements contributed, focus on your part and speak about past colleagues respectfully.
- A generic lesson. “Communication is important” is not a lesson. “I get written sign-off from each consuming team before announcing a date” is.
- Too much setup. If you are 90 seconds in and have not said what failed, you are losing the room.
- Getting defensive. Re-arguing whether it was really your fault undoes the ownership you just showed.
Several of these traps also apply to “What is your greatest weakness?”, another question where candor beats polish. Keep your failure story separate from the one you use to describe a challenging project; reusing one story for both makes your experience look thin.
How to prepare your answer in an hour
- Brainstorm for ten minutes. List every miss you remember: incidents, slipped launches, rewrites, bad estimates, feedback that stung.
- Filter to two. Keep a primary story and a backup with a different theme.
- Write one bullet per STAR+ part, plus one number that shows the impact and one that shows the change worked.
- Say it out loud and time it. Aim for two to three minutes. Cut setup first.
- Rehearse the follow-ups. Have someone ask “why?” three times in a row. Without a partner, run a free AI mock interview in CoPilot Interview with a behavioral mix: the AI interviewer builds questions from your résumé, reads them aloud and scores each spoken answer.
- Check it against your story bank. Make sure it does not duplicate your conflict, leadership or challenging-project stories. Our behavioral STAR examples guide shows how to cover the common prompts with a small set of stories.
Rehearse your failure story out loud
Paste in the job description and your résumé, pick a behavioral mix, and answer out loud; every answer gets a score with what worked and what to improve. The free plan gives you 15 minutes a day with no credit card.
Try a free AI mock interviewFAQ
What is a good failure to talk about in a software engineering interview?
A real work failure where your own decision caused a meaningful miss, such as a production bug you shipped, a blown estimate or a design you had to reverse, that is now resolved and changed how you work. Match its scope to the level you are interviewing for.
Is it okay to say I have never failed?
No. It suggests either limited experience or limited self-awareness, and the interviewer will usually push for an example anyway. Pick a modest, real failure and focus on what you changed afterward.
How long should my answer be?
Aim for about two to three minutes so there is time left for follow-up questions. Advice varies: Amazon's own interview advice says responses should be four minutes or less, and some prep guides allow longer for a detailed story.
Can I use a failure from school or an internship?
Yes, if you are an intern or new grad and it is your most relevant experience. Experienced engineers should use a professional failure, because a college story can look like you are avoiding recent work.
Should I talk about a failure at my current job?
Yes, as long as you leave out confidential details such as customer names and internal system names. Keep the failure and your role in it intact, and speak about your employer respectfully.
Is "tell me about a mistake you made" the same question?
Mostly. A mistake can be smaller and more individual, while a failure usually means a missed goal, but the same STAR+ structure works for both. Have two different stories ready in case both come up.