Behavioural Interviews Module 4 – Core question families
Failure and mistake questions
Answer failure and mistake questions with a real setback: its impact stated plainly, your own part, the recovery, and the check that stops a repeat.
What you will learn
- Pick a real failure whose impact you can describe plainly
- State your part without self-punishment or blame
- Show recovery, prevention and what changed in your behaviour
- Size the failure appropriately for the role and level
Before you start
What you’ll learn · Before you start
What you will learn
- Pick a real failure whose impact you can describe plainly
- State your part without self-punishment or blame
- Show recovery, prevention and what changed in your behaviour
- Size the failure appropriately for the role and level
Before you start
On this page
Kabir, an invented backend engineer at an online pharmacy in Lucknow, once shipped a settings change that switched off payment retries for 40 minutes, and about 1,150 payments failed that would normally have been tried again. Asked “Tell me about a mistake you made”, he has a far stronger answer in that story than in “I care too much about quality”, even though it is harder to say.
Failure and mistake questions ask whether you can look at a real setback plainly: what went wrong and what it cost, your own part in it, how you recovered, and what you changed so that it would not happen again.
Employers ask for real failures, and fake ones backfire
Employers say plainly that an honest failure does not count against you. Meta’s full-loop guide notes that not every project is a runaway success and that “being transparent in these situations won’t be counted against you”. Netflix lists under candor that “you admit mistakes openly and share learnings widely”, and Stripe wants people “who are not afraid to be wrong”.
| Source | What it says about failure |
|---|---|
| Meta’s full-loop guide | Being open about projects that went badly is valued, not penalised |
| Netflix’s culture memo | Candor: admit mistakes openly and share what you learned |
| Stripe’s compatibility page | Not afraid to be wrong; mistakes are learned from together |
| Microsoft’s interview tips | STAR(R): a fifth part, reflection on what you learned |
Together the four ask for two things: openness about what went wrong, and what you learned from it. A fake failure fails twice. “I care too much about quality” is a humblebrag: A boast disguised as a complaint or as modesty, such as naming a strength as your biggest weakness. In studies it made people less liked and seen as less competent than plain bragging., a boast dressed as a weakness. Across nine studies, Sezer, Gino and Norton found that humblebragging made people less liked and seen as less competent than plain bragging, because it came across as insincere. And it leaves the question unanswered.
Not affiliated
None of the employers quoted here is connected with MySmartCoPilot. Their pages, linked under References, are revised now and then.
Checkpoint
Check: Real failures, and why fake ones backfire
A failure story spends most of its time on recovery and prevention
The setback itself takes a sentence or two. A failure answer has six parts, a MySmartCoPilot pattern: what you were trying to do; what went wrong and its impact; your part, in the first person; how you recovered; what you changed so it would not recur, a mechanism: Something you put in place that keeps producing a result without you, such as a review, a standard, a template or a guide that other people run and use. More in “Behavioural signals for staff and principal roles” such as a check or a test rather than a promise to be more careful; and evidence that the change worked. Step through Kabir’s:
The drawing shows the whole scene; its 7 steps are listed below.
Every step as text
- The aim. Kabir changes the payment settings to cut the gateway timeout from 30 seconds to 10, so that checkout feels faster. A reasonable aim, which matters: the failure is not carelessness about users.
- What went wrong. With the timeout, he copies a block of settings from the test file, and with it a retry count of 0. For 40 minutes no failed payment is retried: about 1,150 fail, and about 250 orders are abandoned.
- His part. One sentence, in the first person, said once: he copied the test setting. No excuse about the file, and no punishing himself either.
- The recovery. The alert fires at minute 12, he links it to his change at minute 25 and the rollback finishes at minute 40. The same afternoon he gives support the list of the 250 abandoned orders, and they contact every customer.
- What stops a repeat. In the blameless review the cause is a condition, not a person: test and production values in one file, and nothing checking their ranges. He adds a check to every deploy that rejects payment settings outside agreed limits.
- Evidence it works. In the next quarter the check stops two similar mistakes before they ship, a timeout of 0 and a retry count of 50. He also compares the settings a change touches with production before he merges it.
- The answer. Six parts, about a minute and a half aloud. The mistake takes two sentences; recovery, prevention and proof take the rest.
His part takes one sentence, said once and without drama; the rest is what he did about it. The checker reads four tellings of the same mistake. Press Edit, put your own story in the “Owned” version, and run it again:
// A failure checker: one mistake told four ways, read for what an interviewer listens for in an answer about a
// failure. To check your own story, replace the four parts of the "Owned" version (or add a version) and set RATE to
// your own speaking rate, then run it again.
//
// Kabir, the online pharmacy and the incident are invented.
// Words a minute when telling a story aloud: time yourself once and put your own rate here.
const RATE = 140;
const VERSIONS = {
Fake: {
situation: 'My biggest failure is that I care too much about quality.',
task: 'I hold myself to very high standards, so I sometimes spend too long polishing my code.',
action: 'I am working on it by trusting my team more and accepting good enough.',
result: 'Now I am getting better at it.',
},
Blamed: {
situation: 'A config change went out that broke payment retries for 40 minutes.',
task: 'We had to get payments working again.',
action: "The review didn't catch it, and the person who looked at the change should have noticed. The ops team took a long time to roll it back.",
result: 'Eventually it was fixed.',
},
Harsh: {
situation: 'I broke payments for 40 minutes with a stupid config change.',
task: 'I should have been far more careful.',
action: 'It was entirely my fault, I am terrible with configuration, and I still feel awful about it. Someone else rolled it back.',
result: 'I will never forgive myself for it.',
},
Owned: {
situation:
'I was a backend engineer at an online pharmacy in Lucknow. I changed our payment settings to cut the gateway timeout from 30 seconds to 10, so that checkout would feel faster.',
task: 'My goal was a faster checkout without losing a single payment.',
action:
'I copied a block of settings from our test file, and with it a retry count of 0, so for 40 minutes no failed payment was retried. Our alert on failed payments fired at minute 12; I linked it to my change at minute 25, because two other deploys had gone out in that window, and the rollback finished at minute 40. About 1,150 payments failed; most customers paid again, but about 250 orders were abandoned. I gave support the list of those 250 the same afternoon, and they contacted every customer. In the blameless review I wrote the timeline myself. Test and production values sat in one file and nothing checked their ranges, so I added a check to every deploy that rejects payment settings outside agreed limits.',
result:
'In the next quarter the check stopped two similar mistakes before they shipped: a timeout of 0 and a retry count of 50. I now compare the settings a change touches with production before I merge it.',
},
};
// What the interviewer listens for (MySmartCoPilot's checks; change them to suit a question).
// The impact: a number with what it counts.
const IMPACT = /\b\d[\d,]*\s+(?:payments?|orders?|customers?|users?|minutes?|hours?|days?|weeks?|requests?)\b/i;
// Your part, said in the first person.
const MY_PART = /\bI (?:changed|copied|set|shipped|deployed|missed|forgot|misread|broke|skipped|chose|merged|spent|took on)\b|\bmy (?:change|mistake|error|fault)\b/i;
// What you did to recover, in the first person.
const RECOVERY = /\bI (?:rolled|reverted|restored|fixed|gave|told|called|contacted|refunded|warned)\b/i;
// What now stops it happening again: something that works without you remembering, or a habit you can show.
const PREVENTION = /\b(?:I added|added a check|validat\w*|an alert|a test that|automated|I now (?:compare|check|run|test|agree|split))\b/i;
const NUMBER = /\d|\b(?:one|two|three|four|five|six|seven|eight|nine|ten|half|twice)\b/i;
// A boast dressed as a failure, blame passed on, and self-punishment instead of ownership.
const HUMBLEBRAG = ['care too much', 'very high standards', 'too high standards', 'perfectionist', 'work too hard', 'too detail-oriented', 'too long polishing'];
const BLAME = ["didn't catch", 'should have noticed', 'took a long time', 'their fault', 'not my fault'];
const HARSH = ['stupid', 'I am terrible', 'feel awful', 'never forgive', 'useless'];
const words = (text) => text.split(/\s+/).filter(Boolean).length;
const seconds = (n) => Math.round((n / RATE) * 60);
const clock = (s) => (s >= 60 ? `${Math.floor(s / 60)} min ${String(s % 60).padStart(2, '0')} s` : `${s} s`);
const line = (ok, text) => ` ${(ok ? 'ok' : 'missing').padEnd(8)} ${text}`;
const found = (text, list) => list.filter((phrase) => text.toLowerCase().includes(phrase.toLowerCase()));
console.log(`Failure checks at ${RATE} words a minute`);
for (const [name, parts] of Object.entries(VERSIONS)) {
const story = Object.values(parts).join(' ');
const total = words(story);
console.log('');
console.log(`${name}: ${total} words, about ${clock(seconds(total))}`);
console.log(line(IMPACT.test(story), 'the impact, with a number'));
console.log(line(MY_PART.test(story), 'your own part, in the first person'));
console.log(line(RECOVERY.test(parts.action), 'what you did to recover'));
console.log(line(PREVENTION.test(parts.action + ' ' + parts.result), 'what now stops it happening again'));
console.log(line(NUMBER.test(parts.result), 'evidence that the change worked'));
const flags = [
['a boast dressed as a failure', found(story, HUMBLEBRAG)],
['blame passed on', found(story, BLAME)],
['self-punishment instead of ownership', found(story, HARSH)],
];
for (const [what, hits] of flags) if (hits.length) console.log(` flag ${what}: ${hits.join(', ')}`);
}Output
Failure checks at 140 words a minute Fake: 48 words, about 21 s missing the impact, with a number missing your own part, in the first person missing what you did to recover missing what now stops it happening again missing evidence that the change worked flag a boast dressed as a failure: care too much, very high standards, too long polishing Blamed: 50 words, about 21 s ok the impact, with a number missing your own part, in the first person missing what you did to recover missing what now stops it happening again missing evidence that the change worked flag blame passed on: didn't catch, should have noticed, took a long time Harsh: 47 words, about 20 s ok the impact, with a number ok your own part, in the first person missing what you did to recover missing what now stops it happening again missing evidence that the change worked flag self-punishment instead of ownership: stupid, I am terrible, feel awful, never forgive Owned: 209 words, about 1 min 30 s ok the impact, with a number ok your own part, in the first person ok what you did to recover ok what now stops it happening again ok evidence that the change worked
Recorded with Node.js 24.21.0 on macOS 26 arm64. To run it yourself: mise exec node@24.21.0 -- node failure_check.mjs
Runs on this device, in your browser. The first run downloads JavaScript (about 0.6 MB), which is kept for the next runs.
Your run, in this browser
Only “Owned” passes. “Fake” and “Blamed” never give the speaker’s part, and “Harsh” owns the mistake so loudly that recovery and prevention never arrive: punishing yourself is not ownership either.
Key idea
Say your part once and plainly, then spend the answer on the recovery and on the mechanism that now stops a repeat.
Checkpoint
Check: The six parts of a failure answer
Size the failure for the role you want
A failure needs real consequences to be worth telling: a delayed launch, a production bug, a stakeholder’s lost trust. It must not reveal unethical conduct or gross negligence, which no recovery redeems. The right size also grows with the level: in senior roles, a failure of judgement, such as a wrong bet or a wrong priority, says more than a slip.
| Failure | How it lands |
|---|---|
| “I sent my team an email with a typo.” | Too small: nothing was at stake |
| “A settings change of mine failed 1,150 payments in 40 minutes.” | Right for 2–5 years: real impact, owned and fixed |
| “I bet a quarter on a design that could not scale, and we rebuilt it.” | Right for senior roles: a judgement, not a slip |
| “I hid a data leak from my manager for a week.” | Too big: an integrity failure no story repairs |
The variants ask for the same parts: a missed deadline, a wrong estimate, a decision you regret, a project you would have stopped earlier, or a time you were technically wrong.
Checkpoint
Check: Sizing the failure for the role
The 40-minute incident, told in full and probed Pro: opens with a Pro, Premium or Ultimate pass
Kabir’s story holds up under questioning because every minute of it is accounted for and his part is never blurred. Here are the timeline, what each part of the answer gives the interviewer, and four probes with their answers.
In this part:
- Forty minutes, and the weeks after them
- What each part of the answer gives the interviewer
- Four probes, and the facts that answer them
- The variants, told with the same six parts
1 diagram · about 6 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Fake failures rewritten, and what each level shows Pro: opens with a Pro, Premium or Ultimate pass
Many weak failure answers are fake failures or blame in disguise, and both can be rewritten into real ones. Here four fakes are rewritten and checked; then come telling the people affected, what each level is expected to show, and a senior failure of judgement told in full.
In this part:
- Four fake failures, rewritten and checked
- Telling the people affected, and rebuilding trust
- What a failure answer covers at each level
- A failure of judgement, told at senior level
1 runnable example (JavaScript) · about 4 minutes
Opening this part with your pass…Pro part. It opens with the same pass as the part above.
Practise: check your own failure story
Give the checker a failure of your own and fix each missing line. Then answer the questions, which start where your answers are weakest:
Timeline Maker Lay out your incident minute by minute, then tell the story from the timeline instead of from memory.Practice that adapts to you
Practise this lesson
9 questions about 5 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
Interview questions
A short answer follows the first question. Tell a story of your own for each of the others, aloud, before opening its first step.
-
Fresher to mid · Warm-up
Why do interviewers ask about failures, and what are they listening for?
Because how you handle a setback predicts how you will handle the next one, and everyone has setbacks. Employers that publish their guidance say so: Meta's full-loop guide says being transparent about projects that went badly won't be counted against you. The interviewer listens for a real failure with a real cost, your own part said plainly in the first person, what you did to recover, and what you changed so that it would not happen again, ideally a check or a process rather than a promise to be careful, with some evidence that it worked. They also listen for what is missing: a strength dressed as a weakness, blame passed to others, or so much self-criticism that the recovery never comes. Choose a failure the right size for the role, and spend most of the answer on what you did about it.
-
Mid to senior
Tell me about a mistake of yours that affected other people. How did you tell them, and what did you do next?
-
Fresher to mid
Tell me about an estimate you got badly wrong. What did it cost, and how do you estimate differently now?
-
Mid to senior
Tell me about a time you missed a deadline you had committed to. When did you know, and what did you do?
Key takeaways
- Failure and mistake questions want a real setback; a fake failure such as “I care too much” reads as insincere and answers nothing.
- Say your part once, in the first person, without blame and without punishing yourself.
- Spend most of the answer on recovery, on the mechanism that now stops a repeat, and on evidence that it worked.
- Size the failure for the role: real consequences, never misconduct, and judgement rather than slips at senior levels.
Terms in this lesson
- humblebrag
- A boast disguised as a complaint or as modesty, such as naming a strength as your biggest weakness. In studies it made people less liked and seen as less competent than plain bragging.
References
- Software Engineer Full Loop Interview Guide (linked from the onsite preparation page) (Meta Careers)
- Netflix culture: the Dream Team, candor and informed captains (Netflix Jobs)
- Compatibility: what all Stripes have in common (Stripe)
- Interview tips (Microsoft Careers)
- Humblebragging: a distinct and ineffective self-presentation strategy (Sezer, Gino and Norton) (Journal of Personality and Social Psychology (American Psychological Association))
- Site Reliability Engineering, chapter 15: postmortem culture, learning from failure (Google SRE)
- Success Profiles: Civil Service behaviours (UK Cabinet Office (GOV.UK))
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress