"Tell me about a time you failed" is one of the most feared interview questions. Most candidates either pick something trivial that doesn't read as a real failure, or they describe a genuine failure so badly that they tank their chances. The question has a clear answer structure, and the candidates who use it stand out sharply from those who don't.
What interviewers are actually looking for
They're not looking for perfection. They know you've failed. Everyone has. What they're evaluating is: do you have the self-awareness to recognise your failures honestly? Do you take ownership or do you deflect blame? And crucially, did you learn something and change your behaviour as a result? The failure itself is less important than how you handled it.
Candidates who claim they can't think of a failure, or describe a failure that was clearly someone else's fault, are red flags. Candidates who describe a genuine failure with clear ownership and a tangible lesson are memorable and credible.
How to pick the right failure to talk about
Pick something real, not trivial. "I once submitted a report with a typo" is not a failure. Neither is "I worked too hard on a project." The failure should have had real consequences: a missed deadline, a product that didn't perform, a client relationship that suffered, a project that had to be restarted.
Avoid failures that directly implicate a core requirement of the job you're interviewing for. If you're interviewing for a financial analyst role, don't lead with a catastrophic financial modelling error. Pick something from a different domain.
- A clear decision or action you took (not just something that happened to you)
- A real negative consequence
- Honest ownership with no deflection
- A specific behaviour change afterwards
How to structure your answer
Use STAR, but in this case the Result comes in two parts: the negative outcome of the failure, and the longer-term positive outcome from what you learned. This structure stops the answer from ending on a low note while remaining genuinely honest about what went wrong.
Sample STAR answers
Example: skipping user testing
S/T: "I was leading the redesign of our mobile app onboarding flow. We had a tight timeline and I made the call to skip a full round of user testing, because I was confident we understood the user problem from previous research."
A: "That was my decision alone. I overestimated how much the existing research transferred to the new design. The team pushed back and I overrode their concern."
R: "The new flow had a 12% higher drop-off than the original version. We had to roll it back and redesign with proper testing. It cost three weeks and significant engineering time. I presented the post-mortem to the team and took full ownership. The lesson was that confidence is not the same as validation. I've never shipped a significant user-facing change without testing since, regardless of timeline pressure."
Example: over-committing on delivery
S/T: "Early in my career, I promised a client we could deliver a data migration in six weeks. I hadn't properly scoped the complexity of the source data."
A: "I gave that estimate based on a 30-minute scoping call. I was trying to win the project and I underestimated what I didn't know."
R: "We delivered in 11 weeks. The client was frustrated and nearly walked. I had to have an honest conversation with them at week four when I realised we weren't on track, which I should have done much earlier. I didn't lose the client but I lost their trust for a period. Now I always build a proper scoping document before committing to any timeline, and I add a 25% buffer for technical unknowns. I haven't missed a committed deadline since."