Failure & growth
How to answer: “Tell me about a time you failed”
An ownership and learning test. Pick a real, owned failure with a clear lesson you can prove you applied later.
Why it is asked
What this question is really testing
The point of this question is not the failure; it is your relationship with failure. Interviewers want to see that you take ownership instead of blaming others, that you can describe what actually went wrong without flinching, and most importantly that you extracted a lesson you have since applied. A polished non-failure (I once aimed too high) reads as dodging and is worse than a real one.
Use STAR but weight the answer toward the last two letters. Keep the situation and task tight, be honest about the action that led to the failure and your role in it, then spend real time on the result: what you learned and the concrete evidence that you changed your behaviour afterward. The follow-up they almost always ask is what you would do differently, so build that in.
Choose a failure that is real but not catastrophic and irreversible. Something you owned, recovered from, and learned from beats something so small it has no weight.
The signal
What interviewers listen for
- Clear personal ownership, not a story where someone else is the villain.
- Honesty about what went wrong, described without defensiveness.
- A specific, transferable lesson rather than a vague platitude.
- Proof you applied the lesson: a later moment where you did it differently.
Worked example
A STAR answer you can adapt
Scenario: Engineer who shipped without enough rollout safety. Read it for the shape, then swap in your own story.
Situation
I once owned a migration to a new data store under a tight deadline.
Task
I needed to move a high-traffic write path with no customer impact.
Action
To hit the date I cut the gradual rollout and flipped the whole path at once, trusting my staging tests. A schema edge case that only appeared under production load caused a two-hour partial outage.
Result
I owned it in the postmortem, and the lasting lesson was that deadline pressure is exactly when you need the safety rails most, not least. On every risky change since, I have insisted on a percentage-based rollout with automatic rollback, and that habit has caught two issues before they reached customers.
Answer skeleton
Fill-in-the-blank template
I owned [project]. To [pressure], I [the decision that caused the failure], which led to [honest outcome]. I owned it, and the lesson was [specific lesson]. Since then I [the changed behaviour], which [evidence it stuck].
Avoid these
Common mistakes
- Choosing a fake failure that is really a strength.
- Blaming teammates, management, or circumstances for the outcome.
- Skipping the lesson, or giving a generic one with no evidence it stuck.
- Picking something so trivial it carries no weight.
By role
How the answer shifts by role
Engineering
An incident or a bad technical decision works well if you own it and show the durable process change it produced.
Product management
A feature that missed, or a bet that did not pay off, lands if you show what you learned about validation or sequencing.
Engineering management
A hiring or delegation miss is strong: it shows you can fail on people decisions and adjust how you lead.
Be ready for
Likely follow-up questions
- What would you do differently if you faced that again?
- How did you communicate the failure to your team or stakeholders?
- Tell me about a time you applied that lesson successfully.
Last reviewed by the site editor: June 2026
Nearby topics
Questions that often follow this one
Interviewers rarely stop at one story. These prompts sit close to this one and reward the same preparation.
Turn prep into an offer
Behavioral rounds are only half the loop. See the technical and behavioral questions for your exact role, and when an offer lands, check it is competitive with the salary comparison tool.