In this article
Before you start
This answer is one entry in the behavioral interview questions learning path. A behavioral question asks about something that really happened, so your answer is a short true story, not an opinion about failure.
Nothing else is assumed. The same shape works for the neighboring questions in common interview questions.
Why interviewers ask this
A weak failure answer costs the interviewer the one thing the question exists to find: how you behave when something you did goes wrong. Candidates report the question in several wordings. One asks what you owned and what evidence shows you changed afterward (reported by candidates for Pinterest). Another asks what you learned and what you changed (reported for Google). A short one asks for your biggest failure (reported for Palantir). These are candidate reports, not public statements.
The wordings share three tests: did you own the mistake, did you act well once it was visible, and is there a change someone could check. A weak answer blames circumstances or dresses a strength up as a flaw. A strong answer names a real mistake, takes responsibility in one plain sentence and ends with a changed habit. For the way one large employer frames this, see Google behavioral interview questions. For the general method behind every failure question, see how to answer a failure interview question; this page stays on one worked example and the Staff-level answer.
A failure answer from first principles
- Failure story
- A failure story is a spoken account, about a minute long, of one real mistake of yours, told in order: the situation, what went wrong, what you owned, what you did and what changed afterward. It answers the biggest failure question and is built to survive a short drill-down.
- Evidence of change
- Evidence of change is a fact an outsider could check that shows different behavior after a failure: a new step in your process, a checklist, a changed default, or a later project that went differently. It is stronger than a promise such as "I learned to communicate better", which nothing can confirm.
- Intelligent failure
- An intelligent failure is a failure at the frontier of what is known that happens quickly, on a small scale, and yields valuable information (Edmondson, 2011). A small experiment that disproved your hypothesis fits; a repeated lapse in routine work does not.
In plain words
Think of your answer as a short incident report after a project went wrong. A good report says what happened. It says who was responsible. It says what was done and what changes so it does not repeat. It neither hides the incident nor blames the weather.
The analogy breaks in one place. An incident report is written for engineers. Your answer is spoken to a person judging how you handle responsibility, so it must be short and in order.
In one precise sentence: a failure story states one mistake you owned, the action you took when you saw it, and evidence that your behavior changed.
Step 1: Choose a failure you owned
The best failure to choose is one you caused or could have prevented, with a clear cost and a clear change. Edmondson (2011) sorts failures into three categories: preventable ones in predictable operations, unavoidable ones in complex systems, and intelligent ones at the frontier. A preventable failure is a deviation from a known good process, such as a skipped check.
The same article makes the point that "some failures are inevitable and some are even good", so a failure is not a confession of weakness. Pick a preventable failure you owned, or an intelligent one such as a small experiment that failed fast. A complex-system failure also works if you name your own part in it. Avoid a disguised strength, a trivial slip with no cost, and a story where nothing was in your control.
You now have a story chosen; the next step is to tell its setting briefly.
Step 2: Set the scene in two sentences
Two sentences of situation are enough: your role, the goal and the deadline. In this illustrative example the candidate leads the migration of an invoicing service and tells the finance team it will take six weeks. That is the whole scene.
Input: the story you chose. Output: just enough context for the mistake to make sense. Long backstory is a common way for a good story to lose its listener, because the interviewer waits for the mistake while you explain the setting. Keep only what the listener needs to judge the decision: who relied on you, what you promised and by when. Names of tools, teams and earlier projects can wait for a follow-up question. In the model answer below, the situation takes about a quarter of the words,1 a suggestion for balance rather than a sourced norm.
Step 3: Own the failure in one plain sentence
Ownership is one sentence that says what you did wrong, with no "but" in it. In the example, the sentence is "That was my failure: I gave a date to sound decisive before I had evidence for it."
Compare two illustrative versions. The weak one says: "The old data was worse than anyone told me, so the launch slipped." The strong one says: "I committed to a date without checking the data, so the slip was mine." The facts are the same; only the second shows ownership.
Input: the mistake. Output: a sentence a listener can repeat back. Keep it short, because the evidence in the later steps carries the weight, not the apology.
Step 4: Show what you did once you saw the problem
The action step describes what you did when the problem became visible, and it should show judgment under pressure. In the example, the candidate tells finance the same day, brings a revised plan and a cleanup script, and writes down what the delay will cost them.
Good actions are specific and early: you told the people affected, limited the damage, and fixed what could be fixed. Say what you did, not what the team did, unless you name your own part in it. A story of "we" with no "I" leaves the listener unable to tell whether you owned anything.
Input: the moment of discovery. Output: a recovery the listener can picture in one or two sentences.
Step 5: Show evidence that you changed
The closing move is evidence of change, because the usual follow-up asks for it directly: what did you change afterward, and what shows it? A promise such as "I am more careful now" cannot be checked. A new step can: in the example, a two-day data audit before committing to any date, and later projects that shipped on the date given.
Be honest here. If you have no later project to point to yet, a changed process still counts. If the change is small, say so; a small true change beats a large invented one. The last step is also where the answer ends, so stop after it.
Step-by-step description
- Pick a real failure you owned.
- Two sentences of context.
- One plain sentence, no but.
- What you did when you saw it.
- Something an outsider could check.
- The five moves are: choose a failure you owned, set the scene, own it, act, and prove the change.
- The answer ends with evidence that you changed, not a promise.
The five moves are: choose a failure you owned, set the scene, own it, act, and prove the change. The answer ends with evidence that you changed, not a promise.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
The model answer below is illustrative and written for a lead engineer; every detail in it is invented, so replace it with your own true story.
Tell me about a time you failed.
Last year I led the migration of our invoicing service, and I told finance it would take six weeks. I had not looked at the old data first. In week four we found that about a tenth of the customer records were duplicates, and the launch slipped by three weeks. That was my failure: I gave a date to sound decisive before I had evidence for it. I told finance the same day, with a revised plan and a cleanup script, and I wrote down what the delay would cost them. Since then I run a two-day data audit before I commit to any date. The next two projects I led shipped on the date I gave.
What makes it Staff-level: the failure is a judgment call, not a typo, the cost is stated, and the closing evidence is a process other people could audit.
The same story told badly
A weak version of the invoicing story (illustrative example) follows, with the three phrases that sink it.
- "much worse than anyone told us" blames the data and other people, so no mistake of yours is named.
- "we" throughout means the listener cannot tell what you did or decided.
- "I learned to be more careful" is a promise nothing can confirm; the strong version names a two-day data audit.
The same moves in a non-engineering role
A sales coordinator shows the same five moves outside engineering (illustrative composite, told in the third person). A new coordinator sent a client a quote built from last quarter's discount table, and the client signed at the lower price. In the interview the coordinator says the mistake was sending the quote without checking the current table. The coordinator told the manager within the hour, offered the client a corrected quote and documented what the error cost. Since then every quote gets a second check against the live table, and the team adopted the step. The moves are the same five; only the domain changes.
The answer is 117 words, about 54 seconds at 130 words a minute and about 64 seconds at 110.1 Both rates are illustrative assumptions, not measured norms. A clip of 60 to 90 seconds is about 130 to 195 words at 130 a minute (illustrative),1 so a fuller version can add one sentence of detail, usually in the action or the evidence. As a suggestion, the time splits as follows: situation 12.9 seconds, what went wrong 10.2, ownership 7.8, action 11.1 and change 12.0.1 Ownership is the shortest part, and it should be.
Text description of the diagram
- Ownership is the shortest part at 7.8 seconds.
- Situation takes 12.9 seconds and change takes 12.0 seconds.
The spoken structure: scene, what went wrong, one sentence of ownership, what you did, what changed.
The rubric
Use this as a self-check when you rehearse out loud; it is advice on what a strong answer shows, not any company's scoring sheet.
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Choice of failure | A disguised strength or a trivial slip | A real mistake with a clear cost | A judgment call with team-level cost, told without drama |
| Ownership | Blames people or circumstances | One plain sentence of responsibility | Names the decision that was wrong and why it seemed right then |
| Action | Vague, "we fixed it" | Specific steps you took, early | Limits harm, informs affected people the same day |
| Evidence of change | "I learned to be careful" | A new habit or step | A process others use, with a later result |
| Delivery | Long backstory, rambling | About a minute, in order | Stops after the change and invites questions |
Three variants of this question
Tell me about a time you proceeded without asking for help when you arguably should have.
Use the same five moves, but make the mistake a decision to go alone. Name the signal you ignored, who you could have asked, and the rule you now follow, such as asking after a set time stuck.
Tell me about a meaningful professional failure: what did you own and what evidence shows you changed?
The meaningful-failure wording asks for the last two moves by name. Spend more of your time on ownership and on evidence of change, and keep the scene to two sentences.
Tell me about a time a project didn't go as planned.
The project-didn't-go-as-planned wording does not demand fault, so separate the causes outside your control from the part that was yours, and own that part. If the story is about moving people, the influence without authority page covers the neighboring question.
Common mistakes
- "It wasn't really a failure; I just worked too hard." (wrong) This is a disguised strength and reads as avoidance. (right) "I missed a deadline because I did not check the data first."
- "The vendor delivered late, so we missed the date." (wrong) Blame hands the story to someone else. (right) "I did not build slack for a late vendor; now I add it to every plan."
- "I learned to communicate better." (wrong) Nothing in it can be checked. (right) "I now send the sponsor a weekly risk note."
- Three minutes of backstory before the mistake. (wrong) The listener loses the point. (right) Two sentences of context, then the mistake.
- A story that stops at the damage. (wrong) It shows no recovery. (right) Always end with what you did and what changed.
Follow-up questions
What did you learn from the failure?
Name one specific lesson and tie it to the change. "I learned to check data before committing to a date" is a lesson; "I learned a lot" is not.
What if the failure was caused by someone else?
Pick a different failure, or own your part in it, such as not raising the risk earlier. A story that is all about another person does not show ownership.
What if I have never failed at work?
Choose a smaller real mistake, a failed experiment or a project that missed its goal. Edmondson (2011) notes that some failures are good, so a small, fast one with a lesson is a fair answer.
What is the difference between this question and the greatest weakness question?
The failure question asks for one event and its aftermath; the greatest weakness question asks for a standing trait and how you manage it. Prepare a different story for each.
Does an Amazon-style interview treat this as an ownership question?
Amazon publishes ownership as a leadership principle, and the text says "They never say 'that's not my job.'" (Amazon, accessed October 2026), so a story where you own the fix fits that vocabulary. See Amazon Leadership Principles for the full list.
- Choose a real failure you owned, with a clear cost.
- Set the scene in two sentences and own the mistake in one.
- Say what you did when you saw the problem, and say it in the first person.
- End with evidence of change that someone could check.
- Rehearse out loud; a tight version fits about a minute.
Sources
- Strategies for Learning from Failure — Harvard Business Review (Amy C. Edmondson), 1 Apr 2011
- Amazon Leadership Principles — Amazon (page accessed 2026-10-26), 26 Oct 2026
