skip to content

Tell me about a technical decision you made that you would make differently today.

level: middleimportance: should knowfreq 54%

answer

  1. name the decision and why it looked right
  2. the evidence that turned it
  3. what the wrong call cost
  4. how you reversed or contained it
  5. the rule you apply now

basics

~10 s

Probes intellectual honesty about your own calls. Name one decision you genuinely owned, the evidence that proved it wrong, what it cost, how you reversed or contained it, and the rule you apply now.

how to answer

5 beats
  1. the decision and the case for it at the time
    Say what you chose and give the honest reasoning that made it look right, in two or three sentences. Steelmanning your past self is what makes the reversal credible; a decision presented as obviously stupid makes the interviewer wonder about your judgement rather than your growth. Keep setup and framing to roughly a fifth of your airtime.
  2. the signal that it was wrong
    Name the specific evidence and when it arrived: a measurement, a review pattern, a support trend, a person who kept getting stuck. Say who noticed, and if it was not you, say that plainly. The moment of recognition is the hinge of the whole story.
  3. what you did once you were sure
    This is the bulk of the answer, around sixty percent of your airtime. Walk through the decision to reverse or contain, what you said to the people who had adopted your call, how you sequenced the unwind, and which unglamorous part of the work you took yourself.
  4. the outcome, with a number
    Close the loop with a concrete result and an honest cost — what improved, and what the correction consumed in time or rework. Both halves matter; a result with no price makes the reversal sound free, and a price with no result makes it sound wasted.
  5. the rule you carry forward
    End on one practice you now run because of this, stated concretely enough that the interviewer can picture it happening. Result and reflection together should take about a quarter of your airtime, and the reflection must be a changed behaviour rather than a sentiment.

your answer

5 story prompts
pick a story
  • Pick a decision YOU owned and can name in one sentence, not an inherited stack you disliked.
  • Choose a story where you were still around to correct it, so you can describe the unwind.
  • Write down the measurement that changed your mind, with a before and after number.
  • Name what the correction cost in engineer-time, and which part you carried yourself.
  • This can be the same story as your biggest-failure answer, re-angled onto the decision itself.

draft and rehearse your own answer in a learn session

go deeper

This prompt tests intellectual honesty and ownership: whether you can look at your own judgement critically and treat a decision as a revisable bet rather than a position to defend. A strong answer proves you detect a bad call from evidence rather than from being told, that you absorb the correction cost yourself, and that the experience changed how you decide, not just how you feel.

at middle level

On an internal claims-review console — a team of eight, all of us on one enterprise front end — I pushed for a styling approach that computed every component's styles in the browser at render time. I liked that it kept styles next to the component, and I taught the pattern to the two engineers I paired with each week. Five weeks in, the operations users started describing the console as sluggish. I pulled traces from the machines they actually use rather than mine, and time to interactive on the queue screen had gone from 2.6 seconds to 4.3. About a third of that was style computation before first paint. It was my call that had put it there, and I had taught it to two other people, which is exactly what made it hard to say out loud. I spent four days on a spike that moved the same screen to styles extracted at build time, then brought the traces to the team instead of an opinion. We agreed to migrate. I took the dull half of the work — 23 components — so the two engineers I had coached into the pattern were not left unpicking my decision on their own. Three sprints later the queue screen was at 1.8 seconds. What changed for me: I do not teach a pattern before I have measured it on the hardware our users have. The spike now carries a performance budget, and if the budget is missed, the pattern does not become the house style.

why this lands

The signal sits in the recognition beat and the ownership of the cleanup: the candidate measured on real user hardware, brought traces rather than an opinion, and took the tedious share of the migration from people they had personally taught. Dropping the number, or leaving the unwind to others, would downlevel this to a confession.

at senior level

I owned the front-end guidance for four squads in a large back-office organisation, and I decided we should wrap the vendor design system in our own abstraction layer so that swapping component libraries later would be cheap. It read as insurance against churn, and I ran a weekly office hour teaching squads how to use the wrapper. The bill arrived about a quarter later. Because the wrapper hid the imports, every field type shipped in every bundle, and on the customer-onboarding workflow time to interactive climbed from 3.1 seconds to 5.4. The quieter cost was that new engineers had to learn two vocabularies, and my office hour had become translation between them. That was the signal I had been discounting. I killed my own abstraction. I wrote the reversal into the decision record underneath the original entry, with the numbers and the reasoning that had been wrong, because I wanted the next person to see how the call was made rather than only that it had been undone. Then I sequenced the migration so the two squads with the least slack went last, and I did the first 37 forms myself with a rotating pair from each squad, so the knowledge did not end up concentrated in me again. Onboarding came back to 2.2 seconds. The part I would not skip again: I told the squad leads in a room that the reversal was mine and not theirs, before I asked any of them for an hour of migration work.

why this lands

Scope plus a reversal handled in public is the difference — the decision record updated with the wrong reasoning intact, the migration sequenced to protect the squads with least slack, and accountability stated before help was requested. Without the human cost named aloud, this would read as a competent refactor story.

for a junior

A scoped decision inside your own task is enough: a data shape, a library you reached for, an approach you argued for in review. Show that you noticed the cost yourself and asked for help early rather than defending it.

for a middle

Pick something with blast radius past your own branch — a pattern others copied, a dependency that entered the build. The core signal is the measurement that changed your mind and your visible part in the cleanup, not just the confession.

for a senior

The decision should have shaped how a team or a service worked, and your answer should carry the reversal cost you absorbed and how you protected the people who had built on your call. Say what you wrote down so the next person can see how the call was made.

for a principal

Scope is a standard, a platform direction or a build-versus-buy call across teams. Show the reversal handled in public, the cost named in engineer-time, and the mechanism you introduced so bets of that size carry a review date from the start.

saying these in an interview costs you the question

  • Picking a decision that was actually somebody else's call to make
  • Framing the regret as a constraint you were handed rather than a choice you made
  • Judging the decision wrong by hindsight or vibe, with no measurement behind it
  • Never saying what it cost in time, money or user experience
  • Changing nothing yourself and concluding that others should have listened sooner
  • Spotting the problem and leaving the unwind to whoever came next

  • At what point could you have known it was the wrong call?
    Answer with a specific earlier checkpoint and what would have been visible there — a measurement you skipped, a user you did not watch, a prototype you shortened. Resist both extremes: it was unknowable, or you knew all along and shipped anyway. The credible version says the information was reachable for a small cost and you did not spend it.
  • What did the reversal cost the team?
    Give a real figure in the currency you have — engineer-weeks, sprints, a delayed dependency — and say which part you carried yourself. Understating the cost sounds evasive; dramatising it sounds like a bid for sympathy. Then close on what the team got out of the correction, so the number is context rather than a wound.
  • Who disagreed with you at the time, and what did they see?
    Name the concern fairly and in their terms, without turning them into a prop who was proved right. Say why you discounted it — usually a reasonable trade you weighted wrong. Finish with how you now surface that kind of objection deliberately, so the answer shows a changed process rather than a settled score.
  • How do you make that kind of decision differently now?
    Describe one concrete practice you actually run: a timeboxed spike with a stated pass mark, a written record of the assumptions, a cheap reversibility check before committing others. One practice you can describe in operation beats three you can only name. Tie it back to the specific failure mode in your story.

### What the question is really testing This prompt is a trapdoor for ego. Interviewers ask it because engineering careers are built on decisions made with partial information, and the useful predictor is not whether you were right but whether you notice, say so, and act while the cost is still small. A candidate who treats their own past call as revisable evidence is safe to give a design decision to. A candidate who cannot produce one regret has either never owned anything or cannot see their own work clearly, and both readings hurt. ### Common wordings You will hear this as a decision you regret, a technology choice you got wrong, an architecture you would revisit, or the flat version: what would you do differently. Some interviewers narrow it to a tool — a framework, a database, a queue — and some widen it to an approach or an abstraction. Prepare one story that answers all of these, and adjust the opening sentence to name whatever they named. If they ask specifically about a technology choice and your best story is about an abstraction you invented, say so in one clause and continue; the signal being marked is identical. ### The story you should not pick Three choices sink otherwise strong candidates. The first is a decision that was not yours — an inherited stack, a mandate from above — which converts the question into a complaint. The second is a decision that was correct given what you knew and only looks wrong with information that arrived later; interviewers hear this as a refusal to answer. The third is the humble-brag, where the regret is that you built something too well or too fast. Pick a call that was genuinely available to be made better at the time, with information you could have bought cheaply and did not. ### Evidence beats adjectives The difference between a mid-level answer and a strong one is usually the presence of a number and the moment it arrived. Weak: the approach turned out to be slow and hard to maintain. Strong: on the hardware the users actually had, the screen took nearly twice as long to become usable, and a third of that was traceable to the choice. The measurement does not have to be performance — it can be review time, defect counts, onboarding days, support tickets — but it has to be something you observed rather than felt. Say who gathered it, and if it was you, say what it cost to gather; that detail is what makes the rest sound remembered. ### The correction is the second half of the answer Many candidates stop at the confession, and the answer dies there. Interviewers want the unwind: what you told the people who had adopted your call, which part of the migration you took yourself, what you salvaged, and where the reasoning was recorded so the next person can see how the decision was made and not merely that it was reversed. Writing the reversal into the same decision record as the original is a small, concrete move that reads as senior at any level. ### How the bar moves At junior and mid level the scope can be small; the grading is on honesty, evidence and follow-through. From senior upward the interviewer starts listening for the human cost — the engineers who built on your bet — and for the mechanism that keeps the next bet cheap to exit: a timeboxed spike, a stated pass mark, a review date, a reversibility check before others commit. Close on that mechanism rather than on the apology.

context

resolving links…