Failure, Mistakes and Feedback
Failure and feedback questions test self-awareness and accountability. Learn a five-step structure for failure stories, how to choose a failure that is real but safe to tell, and how to answer questions about receiving feedback, giving it, and your weaknesses.
🎯 What you'll learn
- A five-step structure for failure stories
- How to choose a real but appropriate failure
- Answering feedback questions in both directions
- The 'biggest weakness' question
📚 Before you start
"Tell me about a failure" is a test of self-awareness and accountability. Interviewers want to see that you take responsibility without excuses, respond well in the moment, and change something so it doesn't happen again. Questions about feedback test the same thing from another angle.
1Typical Questions
- "Tell me about a time you failed." / "…a mistake you made."
- "Tell me about a project that didn't go as planned."
- "What's the most critical feedback you've received? What did you do with it?"
- "Tell me about a time you gave difficult feedback to someone."
- "What's your biggest weakness?"
2Structure for Failure Stories
| Step | What to say |
|---|---|
| Own it | "I made the call to skip the load test." No passive voice ("mistakes were made"). |
| Contain it | What you did in the moment: rollback, communication, customer impact limited. |
| Root cause | Why it happened, including your own reasoning at the time. |
| Fix the system | The process, test, alert or habit you changed. |
| Show the lesson stuck | A later situation where you applied it. |
Spend roughly a third on the failure and two thirds on the response and learning.
Weak answer
"A deployment went wrong and the site was down for a while. It wasn't really anyone's fault, the process was bad. We fixed it and I learned to be more careful."
Strong answer
"I shipped a schema migration on a Friday without testing the rollback; it locked the orders table and checkout was down for 25 minutes. I rolled back, posted updates in the incident channel, and wrote the postmortem. The root cause was that I'd assumed the migration was online-safe. I added a migration linter to CI that flags locking operations and a rollback rehearsal step to our checklist. Six months later the linter caught a similar migration from another team."
3Choosing a Real Failure
Pick something real and meaningful with consequences (a missed deadline, an outage, a project cancelled, a bad hire recommendation), where you made a decision that contributed. It shouldn't be catastrophic negligence or something that questions your integrity.
| Too weak | Good | Too risky |
|---|---|---|
| "I once forgot a semicolon." | "I pushed a migration without a rollback plan; checkout was down 25 minutes." | "I ignored security warnings and leaked customer data." |
| "I'm a perfectionist." | "I underestimated a project by 3x because I didn't break it down." | Stories about dishonesty |
4Feedback Questions
Receiving feedback: name specific feedback, how you felt (briefly, honestly), what you did to understand it, the concrete changes you made, and how you checked they worked ("I asked my lead to flag it again in a month").
Giving feedback: show you were specific and timely, did it privately, focused on behaviour and impact rather than personality (the situation–behaviour–impact model), and followed up.
"Biggest weakness": give a real, non-fatal weakness, the evidence that you've noticed it, and what you're doing about it ("I tend to take on too much myself; I now write down what I can delegate at sprint planning").
⚠️ Common Pitfalls
- Humble-brag failures ("I cared too much"): they read as evasive.
- Blaming others or circumstances; even if others contributed, focus on your part.
- No system change: "I'll be more careful" is not a fix.
- Too much time on the disaster, too little on the response.
- A weakness that's core to the job ("I don't like writing code").
📋 Quick Reference
Own it → contain it → root cause → fix the system → show the lesson stuck
~1/3 failure, ~2/3 response and learning; no passive voice, no blame
Feedback received: specific feedback → understand → change → verify
Feedback given: private, timely, situation–behaviour–impact, follow up
Weakness: real, not fatal to the role, with evidence of improvement🧠 Key takeaways
- Own failures in the first person, without blame or passive voice.
- Spend most of the answer on the response, root cause and system fix.
- Pick a failure that's real and consequential but doesn't question your integrity.
- For feedback: change and verify when receiving; SBI, private, timely when giving.
🛠️ Practice exercises
Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.
✅ Check yourself
Answer the questions — feedback is instant.