How do you answer "tell me about a failure"?

How do you answer "tell me about a failure" without sinking your candidacy?

Answer in four beats: the decision that was yours, what went wrong and your honest share of it, what you did to contain the damage, and the specific thing you changed for good. Keep the wreckage to about a third of your airtime and spend the rest on the repair. On 15 October 2026, Amazon's devices chief Panos Panay made a public version of the same argument, saying that builders can recover and learn from all sorts of failures, even catastrophic ones. That isn't corporate therapy. It's precisely why the question exists: the interviewer wants to know whether you turn failure into judgement, or whether you quietly hand it to somebody else.

Interviewers aren't collecting confessions. On a structured scorecard this question usually maps to self-awareness, accountability and learning agility, and the losing answers are depressingly predictable: the humblebrag ("I failed because I care too much"), the deflection ("leadership didn't resource us"), and the trivial ("I once sent a report an hour late"). A hiring manager who sits through six of these in a week clocks each one inside ten seconds. What scores is specificity — a timeframe, a number, a consequence somebody else felt — followed by a change you can actually evidence. If your answer could belong to any candidate in any industry, it tells the panel nothing, and nothing is the same as a no.

STAR still works here, with one amendment: the R stops meaning Result and starts meaning Repair. Situation and Task get two sentences of scene-setting, Action carries the weight, and the close is what you do differently now plus the proof it stuck. Aim for 90 seconds to two minutes spoken aloud — long enough to show real stakes, short enough that you're not still talking when the follow-up should land. The same muscles power a weakness answer that doesn't backfire, so if you've built one of those, reuse the architecture rather than inventing a second format under pressure.

Which failure should you pick, and which ones will sink you?

Pick a failure with real consequences, a decision that was genuinely yours, and no ethical shadow over it. Anything involving dishonesty, harassment, safety, financial misreporting or a confidentiality breach is off the table — not because it can't be forgiven, but because an interviewer can't sign off on a risk they'd have to explain to their own boss. The sweet spot is a judgement error: you under-scoped a project, you trusted a signal you should have tested, you kept a struggling workstream alive three months too long. If the episode ended with you being let go, that's a separate conversation with its own four-part script for being fired, not a line you bury inside this answer.

Stakes matter more than drama. A missed internal deadline on a project nobody cared about reads as evasion, and senior panels hear it that way instantly. Scale the failure to the level you're applying for: a junior candidate can own a broken data pipeline that forced a week of manual reporting; a senior candidate needs something with budget, headcount or customers attached — a launch that missed its number, a hire who didn't work out, a migration that overran and cost the team a quarter. The test isn't how bad the failure was. It's whether someone at that level would plausibly have been in the room making that call.

Recency and verifiability decide the rest. Reach back more than about five years and you invite the obvious follow-up: nothing since? Pick something a reference could confirm in broad strokes, and make sure it doesn't contradict your own paperwork — claiming you owned a failed launch in a role your CV describes as support-only is the kind of mismatch that ends interviews. One more constraint people ignore: never choose a failure whose root cause is the exact skill the job description puts first. Owning an estimation blunder is fine. Owning a forecasting blunder in an interview for a forecasting role is not.

How much blame should you take, and how much should be the lesson?

Take complete ownership of your own decisions and none of anyone else's. That's the line. You can state context factually — the vendor slipped, the brief changed in week three, two engineers were pulled onto an incident — as long as every one of those facts is followed by what you should have done about it anyway. "The spec changed and I didn't renegotiate the date" owns the failure. "The spec changed" blames the process. Interviewers aren't scoring your contrition; they're scoring whether your account of events puts you in the driver's seat. Candidates who over-apologise sound as unreliable as candidates who deflect, because both suggest you haven't thought the episode through properly.

Mentioning other people is fine if you never name them as the cause. Say "we" for the work and "I" for the decisions, and keep former colleagues anonymous — "my then-manager" rather than a name, "the agency we used" rather than the firm. Describing a specific person as the reason your project died tells the panel exactly how you'll talk about them in eighteen months. Where real blame was shared, the strong move is to say so and then narrow: "Three of us made that call. The part I got wrong was that I had the usage data and didn't put it in front of the group."

Then make the lesson falsifiable. "I learned to communicate better" is worth nothing; "I now write a one-page risk note before any project over six weeks, and I've done it for the last nine" is checkable, and checkable statements are what get quoted back to the hiring committee. The best close names the next time the lesson was tested: the following launch that shipped on date, the escalation you raised in week two instead of week ten, the project you killed early because you'd set exit criteria up front. One concrete sequel beats three paragraphs of reflection.

What if the failure was a shipped product or a project that got cancelled?

Separate the business decision from your execution, and only own the half that was actually yours. A project cancelled above your head is not your failure, and claiming it is makes you look confused about scope; what you can own is the signal you spotted late, the stakeholder you didn't bring along, or the pivot you argued for too quietly. This is the ground Panay's point covers: in product work, shipping something that doesn't land is an expected cost of building, and interviewers in tech know it. Treat a dead product as a case study, not a confession, and the whole answer changes temperature.

For a cancelled or defunded project, lead with what survived. Say what the goal was, what you built, what the measured outcome looked like at the point the plug was pulled, and which pieces are still in use — the dashboard another team inherited, the research that redirected the roadmap, the tooling that outlived the programme. Then name your genuine miss: you optimised for a launch date instead of a proof point, or you never defined what "working" meant, so there was no number to defend the budget with. If the cancellation also left a hole in your dates, pair this with a straight answer for the employment gap so the two stories agree.

For something that shipped and flopped, the credibility comes from numbers and kill criteria. Name the hypothesis, the adoption you expected, what you actually got, and how long it took you to admit it — "we forecast 15% of active accounts in month one, hit under 2%, and I spent another two quarters defending it" is the kind of sentence that makes an interviewer lean in. Then describe the discipline you added: pre-registered success thresholds, a review date set before launch, a sunset plan. Before you walk in, check that the role on your CV frames this work as ownership rather than participation — a free CV analysis with a score out of 100 will show you how that section reads to a screener.

What does a strong answer sound like for junior, senior and career-change candidates?

A junior answer should prove you noticed and escalated. Something like: "In my first analyst role I owned the weekly revenue report. I inherited a query, assumed the filters were right, and sent three weeks of numbers that double-counted refunds. Finance caught it, which was humiliating — they'd quoted my figures in a board pack. I spent that afternoon rebuilding the query, wrote a reconciliation check that compared my totals against the ledger, and told my manager before she heard it from anyone else. The check is still in the repo. Since then I don't publish a number I haven't tied to a second source, and I say so in the footer of every report I send."

A senior answer needs scope, money and a decision only you could make. "I ran a team of eleven and pushed a platform migration we'd scoped at four months. It took nine. The miss was mine: I let optimism in the estimate stand because I wanted the roadmap to look achievable, and I didn't build in time for the legacy integrations nobody wanted to touch. Two product launches slipped behind it. I rebaselined publicly at month five rather than drip-feeding bad news, cut scope by a third, and we landed. Now nothing over a quarter gets a date from me without a two-week spike on the ugliest dependency first."

A career changer should pick a failure from the old field whose lesson travels. "Teaching, final year: I designed a cross-year literacy programme and launched it across six classes without piloting it in one. The materials assumed a reading level a third of the cohort didn't have, and by half-term two teachers had quietly abandoned it. That was a research failure, not a resourcing one. I ran it properly the next term with one class, measured it, then scaled. It's the reason I now insist on a small test before any rollout — which is exactly the habit this role needs." Rehearse it out loud; voice mock interviews built from your CV will expose the sentence where you start rambling.

Frequently asked questions