What is the best way to answer "describe a time you failed" in a job interview?
Choose a genuine failure where you had meaningful personal responsibility for the outcome. Describe what happened and your specific role in the failure honestly and concisely, then spend the majority of your answer on what you learned and the concrete behavioral changes you made as a result. The goal is to demonstrate accountability and growth, not to minimize or dramatize the failure itself.
The failure question is the most feared in behavioral interviewing, yet it is consistently handled worse than almost any other question type. Candidates either present non-failures disguised as learning experiences, describe failures where they had almost no personal responsibility, or — most damagingly — describe genuine failures without connecting them to growth. None of these approaches work. Understanding what interviewers actually want from this question changes it from a trap into one of the best opportunities in the entire interview.
What the Failure Question Actually Tests
When an interviewer asks you to describe a failure, they are not attempting to identify a disqualifying flaw. They are assessing three specific qualities that have strong predictive value for job performance.
Accountability — Do you accept responsibility for outcomes you contributed to, or do you attribute failures entirely to external circumstances? People who consistently externalize blame do not learn from experience and tend to repeat the same mistakes.
Self-awareness — Can you accurately perceive what went wrong and your role in it? Self-awareness is one of the strongest predictors of leadership effectiveness and is genuinely rare. Candidates who demonstrate it stand out significantly.
Growth mindset — Do you treat failure as feedback that changes your behavior, or as an event to be survived and forgotten? The evidence from organizational psychology consistently shows that learning orientation is a more reliable predictor of long-term performance than current skill level.
"I am actively looking for how much someone has learned from their failures. The candidate who tells me about a significant failure and can trace a clear line from that experience to changed behavior is showing me something far more valuable than a candidate who tells me they have never really failed. Because everyone fails." — Chief Technology Officer, Series B software company
The Anatomy of a Strong Failure Answer
Part 1: Choose the Right Failure (30 seconds)
The failure you select should be:
Real — Not a hypothetical, not a "near miss" where nothing actually went wrong, not a failure you observed but did not personally contribute to.
Meaningful — The stakes should be real. A bug in a side project that affected no one is not a meaningful failure for a senior engineering role. A missed deadline that delayed a product launch, a technical decision that caused a production outage, a team conflict you failed to address that caused a resignation — these have meaningful stakes.
Your responsibility — You should have a clear personal role in why things went wrong. This does not mean you caused the failure singlehandedly, but you should be able to articulate specifically what you did or did not do that contributed.
Not disqualifying — The failure should not reveal a fatal flaw in your fitness for the role. A failure related to time management is not disqualifying for most engineering roles. A pattern of poor technical decisions would be more problematic for a technical lead role.
Recoverable — The failure should have been something that you could learn from and that had a defined conclusion. An ongoing failure is not a good choice.
Part 2: Describe the Failure Honestly (60 seconds)
Explain the situation and what went wrong. Be specific and honest, but concise. The failure description should take about 25% of your total answer. Resist the urge to qualify extensively or preemptively defend yourself.
What to include:
- The project or context and what was at stake
- The specific thing that failed and when
- Your direct contribution to the failure — stated clearly and without excessive hedging
What to avoid:
- Blaming others exclusively
- Describing circumstances that made failure inevitable
- Minimizing the impact of the failure
Part 3: Own Your Role Explicitly (30 seconds)
This is the element most candidates skip or underplay. Say directly what you did or did not do that contributed. This level of explicit accountability is what distinguishes the answer from a situation report.
"The failure happened because I did not raise the concerns I had about the timeline early enough. I noticed signs of scope creep three weeks before the deadline and told myself it was manageable. I was wrong, and I did not bring it to my manager until we were already a week past the commitment date."
Part 4: Describe the Learning and Change (60-90 seconds)
This is the most important component and should receive the most time. Describe:
- What you understood differently after this experience
- The specific behavioral changes you made as a result
- Evidence that those changes have been effective (ideally a subsequent situation where you acted differently)
The more concrete this section, the more compelling the answer. "I learned to communicate earlier" is weak. "I started scheduling a weekly five-minute check-in with stakeholders specifically to surface blockers before they become risks, and in the six months since then I have had no situations where a missed deadline caught my manager off guard" is strong.
Examples of Failure Answers at Different Career Levels
Early Career Example
"During my second year, I was building a feature that required integrating with a third-party payments API. I tested the integration thoroughly in the sandbox environment but did not test adequately for the production edge cases around currency conversion. The feature shipped, and within two hours we had reports from customers in Europe being charged incorrect amounts.
The failure happened because I assumed the production environment would behave identically to sandbox, which it did not. I did not design test cases around production-specific configurations because I did not know to ask whether there were any.
What I changed: I now create a production readiness checklist for any feature that touches external integrations, with a specific section on environment-specific behaviors. I also established a habit of asking the team whether there are known differences between staging and production for any system I am integrating with for the first time. Since then, I have caught two potential production issues in the testing phase that would have caused similar problems."
Mid-Level Example
"I led the implementation of a new microservice that was supposed to improve our checkout reliability. I designed the service based on requirements I gathered from the product manager without doing sufficient validation with the operations team who would be running it. Three weeks after launch, we had a serious operational incident caused by a design assumption that made the service difficult to debug under production load conditions.
My contribution to the failure was that I assumed the requirements I had were complete and did not proactively seek input from operations during the design phase. I thought I was moving fast. I was actually skipping a critical feedback loop.
After this incident, I changed how I approach service design. I now require a design review meeting that specifically includes at least one operations engineer before I finalize any distributed system design. I also added a section to my service design template covering operational observability and failure modes. The next three microservices I led have all gone live without incidents attributable to operational design oversights."
Senior/Staff Example
"I was the tech lead for a major platform migration that I committed to completing in Q3. I was confident in the timeline based on my experience with similar projects. I was wrong by about two months.
The failure had two components I own. First, I significantly underestimated the complexity of the legacy system we were migrating from because I had not spent enough time deeply understanding it before the commitment. Second, when I started to see the timeline slipping in month two, I did not escalate to stakeholders for three weeks because I kept believing we would recover. By the time I escalated, we were behind by a month and had made business commitments predicated on the original date.
This was a significant failure because it created real downstream problems for the business and eroded stakeholder confidence in engineering estimates.
What I changed: I now treat any commitment that involves a system I have not personally worked in for more than two years as requiring a formal spike before I will commit to a timeline. And I set explicit warning indicators — if I am 15% behind at any point, I escalate immediately rather than trying to recover silently. I have managed two complex migrations since then with timelines that held, and both stakeholders specifically commented on the quality of my communication throughout."
The Most Common Mistakes
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| Describing a non-failure ("I worked too hard") | Shows unwillingness to engage honestly | Choose a genuine failure with real consequences |
| Blaming external circumstances exclusively | Fails the accountability test | Identify and state your specific contribution to what went wrong |
| Focusing more on context than on your role | Dilutes accountability | Keep context brief, expand on your specific contribution |
| No concrete behavioral change described | Fails the growth test | Describe specific changed behaviors with evidence |
| Choosing a failure that disqualifies you | Core job skill failure | Pick a peripheral or soft-skill failure |
| Using a team failure where you had no role | Fails the relevance test | Choose a failure where your decisions mattered |
Frequently Asked Questions
Should I choose a recent failure or an older one? Prefer recent failures from the last two to three years. Recent failures demonstrate current self-awareness and relevant growth. Older failures can be used if they were genuinely significant and you can describe substantial learning, but acknowledge the age and explain why you chose them. Using only old failures suggests you either have not failed recently (implying low risk-taking) or are uncomfortable discussing more recent experiences.
What if the failure involved someone else behaving badly? You can acknowledge that external factors were present without making them the center of the story. Focus on what you could have done differently within your control — even if most of the failure was attributable to another person. "My contribution was not escalating when I first became aware that the other party was not delivering" is honest, specific, and demonstrates self-awareness without requiring you to exonerate behavior that was genuinely problematic.
Can I use a failure that turned out fine in the end? This is a common trap. If the project ultimately succeeded, is it really a failure story? It can be, if there was a genuine failure in the process that had real consequences before recovery — a missed deadline, a quality defect, a damaged relationship. The key is that the failure part should be genuine, not just a speed bump. "We were briefly behind schedule but delivered on time" is not a failure.
References
- Dweck, C. S. (2006). Mindset: The New Psychology of Success. Random House.
- Edmondson, A. C. (2011). Strategies for learning from failure. Harvard Business Review. https://hbr.org/2011/04/strategies-for-learning-from-failure
- Ashford, S. J., & Blatt, R. (2003). Reflections on the looking glass. Journal of Applied Behavioral Science, 39(3), 282-307.
- Cannon, M. D., & Edmondson, A. C. (2005). Failing to learn and learning to fail (intelligently): How great organizations put failure to work to innovate and improve. Long Range Planning, 38(3), 299-319.
- Sitkin, S. B. (1992). Learning through failure: The strategy of small losses. Research in Organizational Behavior, 14, 231-266.