Failure & learning
In one line
A strong failure story owns a real mistake, shows how you limited the damage, and proves you changed something so it does not happen again.
What it is
Failure questions ask about a time something went wrong because of you: a bug that reached production, a missed deadline, a wrong estimate or a bad decision. They also include 'what is your biggest weakness?' and 'what would you do differently?'.
The interviewer is not trying to catch you out. They want to see honesty, ownership, how you behave under pressure, and above all whether you learn. A story where nothing really went wrong, or someone else was at fault, misses the point.
Why interviewers ask
Everyone makes mistakes, especially in engineering, where outages and bugs are normal. Companies with blameless post-mortem cultures (like Google SRE practice) value people who surface problems early and fix root causes. This question tests self-awareness, accountability and growth, and it is one of the easiest to fail by being defensive.
How it works
- 1Choose a real failure with real consequences, but not a catastrophic or ethical one. It should be clearly your mistake, at least in part.
- 2Situation and Task: briefly set up what you were doing and what was at stake.
- 3What went wrong: state your mistake plainly in one or two sentences. No excuses, no blaming.
- 4Response: what you did immediately to limit the damage, and who you told and when. Raising it quickly is a key signal.
- 5Learning: the root cause and the specific change you made (a process, a test, a checklist, a habit). Ideally show the change working in a later situation.
Worked example · Question: Tell me about a time you failed
- Situation: 'In my first year, I was asked to add a new column to our users table in PostgreSQL, which had around 30 million rows.'
- Mistake: 'I wrote a migration that added the column with a default value and backfilled it in the same transaction. I tested it on a small local database, where it took a second, and deployed it on a Friday afternoon.'
- What happened: 'In production it held a lock on the table for about 6 minutes. Logins failed during that time.'
- Response: 'I saw the error alerts, told the on-call engineer and my lead in the incident channel within two minutes, and we decided to let it finish rather than kill it halfway. I then wrote the incident summary myself.'
- Learning: 'The root cause was testing on unrealistic data and doing schema change and backfill in one step. I changed my approach: add the column without a backfill, then fill it in batches of 10,000 rows. I also added a staging check with a production-size copy, and we agreed on no risky deploys on Friday afternoons.'
- Proof of change: 'Six months later I ran a similar change on a 50-million-row table in batches, with zero downtime.'
- Why it works: clear ownership, fast communication, a concrete root cause, a process change and evidence that the lesson stuck.
Picture it
A failure story is like a good doctor's case report: what went wrong, how it was stabilised, what the underlying cause was, and what treatment prevents it next time. Nobody trusts a doctor who claims never to have had a hard case.
Key patterns
Own, fix, learn, prove
When: Any failure question
How: State your mistake, how you limited damage, the root cause and change, then a later example showing the change worked.
Real weakness, active plan
When: 'What is your biggest weakness?'
How: Name a real but non-fatal weakness (for example, saying yes to too many requests), then the specific steps you are taking and the progress so far.
Blameless root cause
When: Failures involving systems and teams
How: Explain the process gap that allowed the mistake, not only the human error, as in a blameless post-mortem.
Real-world use
A production bug or outage
A deploy that broke something. Strong because you can show incident response, a post-mortem and a concrete fix such as a new test or alert.
A missed deadline or bad estimate
You promised two weeks and it took five. Shows how you communicated slippage and how you estimate differently now (breaking work down, adding buffers).
A wrong technical decision
Choosing a library or architecture that did not scale. Shows judgment, how you recognised it, and how you reversed it at reasonable cost.
A people or communication miss
Not asking for help early enough or not keeping a stakeholder informed. Shows self-awareness about soft skills, not just code.
In a project
You dread failure questions and tend to give a 'humble brag' answer like 'I work too hard'.
- List three real mistakes from work, internships or projects, each with a visible consequence.
- For each, write the root cause in one sentence and the concrete change you made afterwards.
- Pick the one where you can show the change working later; that is your main story.
- Prepare a genuine weakness that is not critical for the role, plus what you are actively doing about it.
- Practise saying the mistake sentence plainly, without softening words or blame.
Impact: You answer failure and weakness questions calmly and credibly, which many candidates handle poorly, and you come across as someone who is safe to trust with production systems.
Trade-offs
Use it when
- 'Tell me about a time you failed' or 'made a mistake'
- 'What is your biggest weakness?' and 'what would you do differently?'
- Questions about feedback, missed deadlines or a project that did not go to plan
Avoid it when
- Failures involving dishonesty, ethics or harm to people
- Mistakes so serious and recent that they raise doubts about core skills for the role
- Fake failures ('I care too much'); interviewers see through them immediately
Common mistakes
- Choosing a fake or tiny failure that teaches nothing.
- Blaming teammates, unclear requirements or bad luck instead of owning your part.
- Spending most of the answer on the failure and almost none on the learning.
- Giving a vague lesson like 'I learned to be more careful' instead of a concrete change.
- Naming a weakness that is critical for the role, such as 'I am not good at debugging' for an engineering job.
Interview questions
Quick revision
- Real mistake, really yours, not catastrophic.
- Say the mistake plainly in one sentence. No excuses.
- Show fast damage control and fast communication.
- Root cause plus a concrete change (test, checklist, process).
- Best ending: proof the lesson worked later.
- Spend at least half the answer on response and learning.
- Weakness: real, non-critical, with an active improvement plan.
Check yourself
1. Which is the strongest choice for a failure story?
2. Which lesson statement is best?
3. What does a blameless post-mortem focus on?
4. Roughly how much of a failure answer should be about your response and learning?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.