How to Answer "Tell Me About a Time You Failed"
The short answer
Use STAR: set up a real failure in one sentence, say what you were responsible for, describe what you did — including the decision that went wrong — and finish with the outcome and the specific change you made afterwards. Own it in the first person, and pick something that genuinely failed.
The trap is choosing a failure so small it proves nothing. Here is how to pick one that is real, tell it in ninety seconds, and come out of it looking better.
Or skip ahead and have your answer scored — free, no account needed.
Why interviewers ask “Tell me about a time you failed”
Everyone senior has failed, and interviewers know it. What they are testing is whether you can look at a bad outcome without flinching, whether you take responsibility when it would be easy not to, and whether anything actually changed as a result. A candidate who blames circumstances on a small failure will blame circumstances on a large one, and that is expensive to manage.
What they are actually listening for
- Is this a real failure, or a success story wearing a costume?
- Do you say "I" when describing what went wrong, or does the subject quietly become "we" and then "they"?
- Can you identify the specific decision that was wrong, rather than the circumstances that were unlucky?
- Did anything change afterwards, concretely and durably?
- How do you handle discomfort while talking? This one is being observed as much as answered.
The structure to use: STAR, with the emphasis on Action and Result
This is a behavioural question, so it wants a story with a shape: Situation, Task, Action, Result. What makes the failure version different is that the Action has to include the mistake — stated plainly — and the Result has to include what you changed. Get to the failure inside twenty seconds; a long preamble reads as stalling.
Situation — set it up in one or two sentences
~15 secondsGive just enough context for the failure to make sense: what the project was, roughly when, and what was at stake.
Resist the urge to explain the whole system. The interviewer needs the stakes and your role, not the architecture. Two sentences is almost always enough, and every extra one delays the part they are waiting for.
Task — say what you owned
~10 secondsState clearly what you personally were responsible for, so there is no ambiguity later about whose failure this was.
This beat does quiet work. By naming your ownership up front, everything that follows lands as accountability rather than as an accusation against someone else.
Action — including the decision that was wrong
~35 secondsDescribe what you did, and name the specific choice that turned out to be the mistake.
The word interviewers are listening for is "I". "I decided to skip the load test because we were behind" is a strong sentence. "The timeline was compressed so testing was reduced" is the same fact with the person removed, and it is heard as evasion. Name the decision, and say why it seemed reasonable at the time — that shows judgement rather than recklessness.
Result — the real outcome, then the change
~40 secondsSay what actually happened, including the cost, then describe the specific, lasting thing you changed as a result.
Do not soften the outcome; a failure with no consequence was not a failure. Then land the change, and make it concrete: a process you introduced, a check that now exists, a habit that has held. If the change later prevented a similar problem, that sentence is the strongest one in the whole answer.
Example answers to “Tell me about a time you failed”
These are written to be spoken, not read. Do not memorise them — take the shape and put your own experience through it.
Example 1
Software engineer
A failed launch caused by a skipped load test
About eighteen months ago I owned the rollout of a new search backend at the company I am at now. We had a fixed launch date tied to a marketing campaign.
I was responsible for the migration plan and the go-live decision. We were four days behind, and I decided to cut the load test on the grounds that our staging traffic replay had been clean and the new service was faster than the old one on every benchmark.
It fell over about twenty minutes after the campaign email went out. The bottleneck was not throughput, it was connection pool exhaustion under a traffic pattern staging never produced. We were degraded for about ninety minutes and rolled back. It was the most visible outage the team had had that year, and it was my call.
What changed is that load testing is now a release gate rather than a task on a checklist — it cannot be skipped by an individual, it needs a second person to sign off. I also started running the traffic replay against production-shaped concurrency rather than production-shaped volume, which is the specific thing we had wrong. We caught a similar pool issue before launch on the next two services.
Why it works
- The failure is genuinely serious and visible, so it does not read as a safe choice.
- The wrong decision is stated in the first person, with the reasoning that made it seem sensible at the time.
- The outcome is not softened — ninety minutes of degradation, the team's most visible outage.
- The change is structural (a gate that removes the individual's discretion) and it is shown to have worked since.
Example 2
Product manager
A feature built on the wrong evidence
In my last role I pushed for a bulk import tool. Three of our largest customers had asked for it in QBRs, and I was confident enough that I did not test the demand further.
I owned the prioritisation and I wrote the case for it, so this was mine. We spent about a quarter on it, which meant deferring work on the reporting area that the whole customer base used.
Adoption after three months was under four per cent, and two of the three customers who asked for it never used it — what they actually wanted was to not have to do the import at all, which an integration would have solved. My mistake was treating a loud request from important customers as evidence of a need, and never asking what the underlying job was.
Since then I do not put anything on the roadmap from a request alone. I run at least five customer conversations about the underlying problem first, and I write down what result would tell us we were wrong. The next two things we shipped that way both cleared thirty per cent adoption, and one of them was not the feature that was originally asked for.
Why it works
- The failure is an error of judgement, which is more interesting than an error of execution.
- It names the cost precisely, including the opportunity cost of what was deferred.
- The diagnosis is sharp — it identifies the reasoning error, not just the bad result.
- The change is a repeatable process with evidence that it worked afterwards.
Common mistakes (and the fix)
Choosing a failure that is not one
Stories where the project shipped late but was fine, or where the failure was really someone else's, tell the interviewer you are unwilling to be exposed. That is a worse signal than the failure itself would have been.
Fix: Pick something with a real cost that you can still talk about calmly. If it does not make you slightly uncomfortable, choose a different one.
Sliding from "I" into "we" and then "they"
It is the most common tell in this question. Interviewers track the pronoun deliberately, and the drift is read as blame-shifting even when it is not intended.
Fix: Use "I" for every decision that was yours, especially the wrong one. Save "we" for the parts that genuinely were shared.
Blaming circumstances
Timelines, headcount, and unclear requirements are usually real, but leading with them turns the answer into an explanation of why the failure was unavoidable — which means nothing was learned.
Fix: Mention the constraint once as context, then move immediately to what you could have done differently within it.
Landing on a vague lesson
"I learned the importance of communication" is the ending of an answer that has not been thought about. It is not checkable and it does not describe anything you now do.
Fix: End with a specific mechanism and, if possible, evidence it has held since.
Spending too long on the setup
Long context is usually avoidance. If the failure has not appeared by thirty seconds, the interviewer starts wondering whether it will.
Fix: Two sentences of situation, one of task, then get to the decision.
Free · no account needed
Say your answer out loud. Get it scored.
Reading about the structure is not the same as saying it. Answer “Tell me about a time you failed” the way you would in the room, and get a score plus three specific fixes. Aim for 90-120 seconds (roughly 200-250 spoken words).
This browser cannot record audio. .
Practise the other nineteen questions too
“Tell me about a time you failed” is one question. Paste the actual job posting and your CV and prepare.fyi generates the twenty questions that company is most likely to ask, then lets you answer them out loud — with a live AI interviewer and a scored breakdown of every answer.
“Tell me about a time you failed”: frequently asked questions
- How big should the failure be?
- Big enough to have had a visible cost — a missed launch, a rolled-back release, a feature nobody used, a deadline that slipped and mattered. Avoid anything that suggests a pattern rather than an incident, and avoid anything involving dishonesty or harm to a person. Roughly: serious enough that you remember it clearly, contained enough that you can describe it calmly.
- What if my failure was genuinely someone else's fault?
- Then it is the wrong story for this question. Pick one where the wrong decision was yours. If the situation you want to describe involved others, focus entirely on your own contribution to it and leave the rest out — an interviewer who hears you allocate blame will assume you would do it to a teammate too.
- Should I use STAR for this question?
- Yes. Any question that starts "tell me about a time" wants a story with a shape, and STAR is that shape. The only adjustment for the failure version is that the Action must include the wrong decision and the Result must include what you changed afterwards.
- What if I am early in my career and have not failed at work yet?
- Use a project, a group assignment, an internship, or something you built and abandoned. What matters is that you owned a decision, it went badly, and you can describe what you would now do differently. Interviewers calibrate for experience level; they do not calibrate for evasion.
- Is it the same as "what is your greatest weakness?"
- No. A weakness is an ongoing tendency you manage; a failure is a single event with a specific outcome. They want different structures, and using one to answer the other is noticeable. Prepare both.
Practise the next question
Self-awareness
“What is your greatest weakness?”
Everyone knows "I am a perfectionist" is a non-answer, including you. Here is how to give a real one without damaging your candidacy.
Opening
“Tell me about yourself”
It is the first question in almost every interview, and the one most candidates waste. Here is the structure, three full example answers, and a way to practise yours out loud right now.
Motivation
“Why do you want to work here?”
This is the question that separates candidates who researched the company from candidates who applied to forty of them. Here is how to answer it without flattery.