Failure, Mistakes & Weaknesses

Intermediate · 14 min read · Question Bank by Theme, Getting Things Done

Owning a real failure, what changed afterwards, and an honest weakness.

"Tell me about a time you failed" is the question candidates fear most, so they dodge it. They give a fake failure ("I worked too hard"), blame someone else, or pick something trivial. That's exactly what the question is designed to catch. Interviewers are testing self-awareness, honesty and learning.

The question in its many forms

What they're scoring

Choosing the failure

The shape: spend half on the aftermath

Weak vs strong

Weak: "We once had a release go wrong because the QA team missed a bug. We rolled back and it was fine. I learned the importance of testing."

"What's your greatest weakness?"

Cracking the Coding Interview is blunt about this one. Give a real weakness, because "I work too hard" signals arrogance or a refusal to admit faults. Then show how you manage it. Its example is weak attention to detail, which leads to careless mistakes, so the candidate always has someone double-check their work.

At senior and staff level

Senior failures are usually judgment failures rather than coding mistakes: a bet that didn't pay off, a plan that was too ambitious, a team or stakeholder you failed to bring along.

Follow-ups to expect

Key takeaways

They're testing honesty, ownership, response and learning; a real failure owned well scores highly.
Choose something real, with consequences, that you resolved; avoid integrity issues.
Spend half the story on the aftermath: the immediate fix, the root cause, what changed, and evidence.
For weaknesses, give a real one plus the concrete habit you use to manage it.

Previous: Ownership & Ambiguity · Next: Deadlines & Trade-offs