# Failure, Mistakes and Feedback — Part 1: Owning What Went Wrong

"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.

![A failure answer: own it, contain it, find the root cause, fix the system, share the lesson](diagrams/01-failure.svg)

## 1. Typical 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?"

## 2. Structure 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.

## 3. Choosing 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 |

## 4. Feedback 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

1. **Humble-brag failures** ("I cared too much"): they read as evasive.
2. **Blaming others** or circumstances; even if others contributed, focus on your part.
3. **No system change**: "I'll be more careful" is not a fix.
4. **Too much time on the disaster**, too little on the response.
5. **A weakness that's core to the job** ("I don't like writing code").

## Quick Reference

```text
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
```