Tell me about a time you were wrong about a technical decision.
answer
- the call I made, and why
- how the evidence reached me
- said it out loud, fast
- the fix and what it cost
- the check that outlives the mistake
basics
~10 sTests whether you can be wrong without defending it. Name a real call you got wrong, how you found out, what you said and to whom, and the guardrail that came out of it.
how to answer
5 beats- the call I made, and why it looked rightTwo or three sentences, no more — roughly the first sixth of your airtime. Give just enough context that the error is understandable, and state the position as yours rather than as something the team decided.
- the evidence that contradicted meSay concretely what surfaced the error and how it reached you: a canary, a report from a user, a colleague's reproduction. If someone else found it, say so plainly; hiding that is worse than the fact.
- what I said, to whom, and how fastThis is the beat that carries the signal, so give it real airtime. Quote roughly what you wrote or said, name the channel, and make clear whether you spoke before or after you had a fix in hand.
- the correction and what it costTogether with the previous beat this should be around sixty percent of the answer. Name the rework, the delay or the wasted effort in concrete units, including cost you imposed on other people.
- the check that outlives the mistakeClose in twenty to thirty seconds with the guardrail or habit that exists today because of this, plus one number on the outcome. Resolve statements without a mechanism read as filler.
your answer
4 story prompts- Pick a call you made yourself, not one you merely executed for someone else.
- Choose an error you admitted within days, not one you only see in hindsight now.
- Have one number for the damage and one for the recovery before you rehearse.
- This can be your failure story re-angled, as long as the wrong call was yours.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this prompt to test intellectual humility and ownership under ego pressure. They want to know whether you notice your own errors, concede them quickly and in public, and act on the correction — or whether your mistakes get discovered by other people, late. A strong answer proves that being wrong is cheap around you.
I was one of the newer contributors on an open-source backend project that was migrating its ingestion adapters onto a new queue driver. I picked up the adapter for a file-based source and argued in the pull request that the old and new paths were behaviourally identical, so the compatibility test a maintainer had asked for was redundant. It got merged on that argument. Two days later the maintainers ran it in a canary on their reference deployment and acknowledgement retries stopped being counted, so redeliveries piled up behind it. The canary burned 18% of that week's error budget in about 40 minutes before someone rolled it back. I saw the rollback in the tracker before anyone pinged me, and I posted in the thread that the regression was mine and named the line: my adapter swallowed the retry counter the old path incremented. I did not wait until I had a patch to say it. The patch came about two hours later, and with it the compatibility test I had argued against, plus one for the acknowledgement path nobody had covered. What actually changed for me is smaller than the story. I stopped arguing that a test is unnecessary. If the real reason is that I do not want to write it, I say that instead, and usually then I write it.
The signal sits in the third paragraph: they claimed the regression before being asked and named the exact defect, without waiting for a fix. At this level a task-scope call plus the guard they had skipped is the full bar. Waiting to be paged, or a longer setup, would downlevel it.
I maintained the queue-driver interface on an open-source backend project during a storage migration, and I wrote the section of the design proposal arguing we could cut adapters over directly instead of running a dual-write phase first. My reasoning was that the write path was idempotent, so a replay after cutover would reconcile anything lost. Three other maintainers signed off partly because I had the most context on that interface. The first cutover covered nine adapters. Within a day, people running the project themselves reported duplicate side effects on non-idempotent sinks — outbound mail and webhooks — which my argument simply had not considered. Burn rate on the reference deployment sat at 2.3x for about eleven hours. I paused the remaining cutovers myself before anyone asked me to, then amended the proposal that evening rather than arguing the edge case was narrow. I wrote that my idempotency claim was wrong for any adapter with an external side effect, and that the dual-write phase I had cut had to go back in for the remaining twenty-five. I also messaged the two contributors who had started porting adapters on my advice, because their work now needed redoing. The rest of the migration ran dual-write with a reconciliation report. The habit I kept: in a proposal I now write out the class of thing my assumption does not cover, before someone else has to find it.
What lifts this is scope and sequence: a design others had signed off and started building on, paused before being asked, corrected in writing, then a direct message to the people whose work it wasted. Skipping that message, or leaving the amendment verbal, would pull it back down a rung.
Task scope is enough: a call you made on your own piece of work. The signal an interviewer wants is that you raised it yourself rather than hoping it slipped through, and that you added the check you had skipped.
Pick a design call others built on — a review you pushed through, an interface you argued for. Show the mechanics of retracting in public: where you said it, how fast, and what you asked people to stop doing while you fixed it.
State the blast radius honestly, including people who had already committed work to your position. Interviewers listen for whether you told them before they discovered it, and for the prevention that followed rather than just the patch.
Your wrong call was a published position at org scope, so the correction has to be structural: what you changed about how such decisions get made, reviewed or reversed, and evidence that others found it cheaper to reverse themselves afterwards.
saying these in an interview costs you the question
- Picking a mistake so trivial that admitting it costs nothing
- Blaming vague requirements or a teammate for the call you made
- Someone else caught it and the story shows no ownership afterwards
- A long defense of why the decision was reasonable, with no reckoning on the outcome
- The story stops at the apology and never reaches a result
- Relitigating the technical point in the interview to prove you were partly right
- How much time passed between the first sign you were wrong and you saying so?Answer with a real interval and do not round it down. If it was long, name what delayed you — waiting for certainty, wanting a fix in hand — and say what you would compress next time. Interviewers accept a slow admission with a diagnosis far more readily than an implausibly instant one.
- Who else was affected, and how did you tell them?Name the groups by role and say which channel you used and whether you went to them or they came to you. The strongest version includes someone whose work you had made useless, and what you offered them. Avoid shrinking the audience to make the mistake look tidier.
- What would have caught this earlier?Give one specific mechanism — a test, a canary, a review question, a smaller first cutover — and say whether you actually put it in place. If you did not, say why and what you would need to. A generic 'better communication' answer wastes the strongest follow-up in the set.
## One story, several wordings This prompt arrives in several wordings that all want the same signal: - 'Tell me about a time you were wrong' - 'What is the biggest technical mistake you have made?' - 'Describe a decision you got wrong' - 'When did you last change your mind about something technical?' Treat them as one story with one adjustable emphasis. The **mistake** wordings want the failure and the recovery; the **changed-my-mind** wording wants the evidence and the update. Prepare the episode once and shift which beat carries the airtime. ## What is being measured The evaluation axis is **intellectual humility**, and interviewers probe it because being wrong is not rare — engineers are wrong constantly — so what they are actually measuring is the cost of your errors to the people around you. A candidate who detects their own errors and announces them early is cheap to work with. A candidate whose errors are discovered by others, late, after the argument has consumed a week, is expensive regardless of how often they are right. ## Three weak answers 1. The commonest weak answer is the **safe mistake**: a typo, a misestimated ticket, an outage caused by an intern's script. It reads as risk management rather than reflection, and the interviewer's follow-up will hunt for a real one. 2. The second commonest is the **reasonable-decision defense**: three minutes explaining why the choice was correct given what was known, then a shrug at the outcome. That answer never concedes anything, which is the whole test. 3. The third is the **deflected mistake**, where the root cause conveniently sits in someone else's decision, missing documentation or a shifting requirement. ## What a strong answer does A strong answer picks a call you personally argued for, states the error in a single unhedged sentence early ('my idempotency claim was wrong'), and then spends its airtime on behaviour rather than on the technical post-mortem. The technical detail is context, not evidence; the evidence is what you did in the first hour after the evidence landed. Who did you tell, in what channel, before or after they could have found out on their own, and what did you ask people to stop doing while you fixed it. Interviewers are listening for a verb sequence: **noticed, said, paused, fixed, guarded**. ## Evidence that lands well and badly Evidence types that land well, roughly in ascending order of strength: 1. an artifact you wrote that records the reversal (an amended design doc, a comment on your own closed pull request); 2. a check that exists today because of the mistake; 3. a named person you had to go back to; 4. and a number on the damage that you did not have to volunteer. Evidence that lands badly: praise from a manager for handling it well, and any framing where the mistake turns out to have been secretly beneficial. ## How the bar shifts by level The bar shifts by level in scope of the claim you were wrong about, not in the sophistication of the apology. - **Early on**, the error lives inside your own task and the credible correction is a test you added. - **In the middle**, the error lives in a design others consumed, and the correction includes telling them. - **Higher up**, the error had a constituency — people who defended your position because you held it — and the correction has to reach the process that let the position stand unchallenged. At every level, the answer ends on what is different now, said in one sentence and not a paragraph of resolve.