"Tell Me About a Time an Architecture Decision Went Wrong": How to Answer Without Blaming or Bleeding

Every architect interview loop has one question that is not about systems at all. It is about you: “Tell me about a time an architecture decision went wrong.” Candidates who can design a global message bus on a whiteboard freeze on this one, or worse, answer it in a way that quietly disqualifies them.

The question is a test of ownership, judgment, and learning, in that order. By the end of this post you will know how to choose a story that passes all three, how to tell it in about three minutes with a structure that holds up, and how to handle the follow-ups that are designed to find out whether you actually owned the outcome.

The Question

The direct forms:

• “Tell me about a time an architecture decision went wrong.”
• “Tell me about a technical decision you regret.”
• “What is the biggest design mistake you have made?”
• “Tell me about a time you had to reverse a decision you made.”
• “Tell me about a system you designed that did not scale the way you expected.”

They are the same question with different emphasis. The last two lean toward the recovery. The first three lean toward the decision. Prepare one story that covers both.

What They Are Really Asking

1. Do you own decisions, or do you narrate them? An architect makes calls that other people live with. The interviewer wants to hear “I decided,” “I missed,” “I changed.” They are listening for pronouns.
2. Was your judgment reasonable at the time? A decision that went wrong is not the same as a bad decision. The strong answer shows that the choice was defensible given the information available, then names the specific information that was missing and why you did not have it.
3. How fast did you notice? The real failure in most architecture mistakes is not the decision. It is the months between the decision and the moment someone admits it is not working. The interviewer wants to know what signal you saw, how long it took, and whether you were the one who called it.
4. Did you change how you decide? “I learned to be more careful” is not a change. “I now write down the assumption the decision depends on and the condition that would make us revisit it” is a change.
5. Have you operated at a level where mistakes have consequences? A trivial story signals either that you have not carried real responsibility or that you are hiding a bigger one. Both are bad.

A weak answer is a small mistake, told with passive voice, blamed on requirements or the team, ending with a generic lesson. A strong answer is a real mistake, told in the first person, with numbers attached to the impact, a clear signal that revealed it, a recovery you led, and a concrete change in practice.

The Gotchas

Gotcha 1: The fake mistake. “We picked a logging library that we later replaced.” Nobody’s career was affected by that. The interviewer concludes that you have either never owned anything important or you are evading. Pick something that cost real time or money.

Gotcha 2: The humble brag. “My mistake was that I designed the system so well that we grew faster than expected.” The interviewer has heard it a hundred times. It signals that you are not willing to be honest in an interview, so you will not be honest in a postmortem either.

Gotcha 3: Blaming. “The team did not implement it correctly.” “The requirements changed.” “Leadership would not give us time.” Some of that may be true, and none of it is the answer. Even where others contributed, the frame is what you decided and what you would do differently. If requirements changed, the lesson is about how you designed for the change you should have anticipated, or how you failed to build in a reversal point.

Gotcha 4: Hindsight framing. Presenting the original decision as obviously stupid. If it was obviously stupid, why did you make it? You want the opposite: show that a reasonable person with the information you had would have made the same call, then show what you would now do to get the missing information earlier.

Gotcha 5: No detection story. Candidates jump from “we chose X” to “it did not work.” The interesting part is the middle. What did you observe? Who noticed first? How long did you keep going after the first signal, and why? That is where judgment lives.

Gotcha 6: No numbers. “It caused some problems.” Say what it cost: months of migration, hours of outage, a percentage of engineering time, a delayed launch. Numbers make it real and show you measured the blast radius rather than just feeling bad about it.

Gotcha 7: The generic lesson. “I learned to plan more carefully.” “I learned to communicate better.” These are not lessons, they are apologies. A lesson is a specific change to how you make decisions, and it should be something the interviewer can imagine you doing next week.

Gotcha 8: The story where nothing could have been known. A vendor went bankrupt. A regulation appeared out of nowhere. These are bad luck, not bad decisions, and the interviewer learns nothing about your judgment. Unless you can point to a signal you missed, choose a different story.

Gotcha 9: Eight minutes of context. The story starts with the founding of the company and the org chart. By the time the decision appears, the interviewer has stopped listening. Lead with the headline.

Gotcha 10: Naming names. Do not name the employer, the client, or the colleague who warned you. Describe the domain and the scale. Confidentiality is itself a signal about judgment.

How to Answer

Step 1: Choose the right story

Score your candidate stories against this list. You want a yes on every row.

Criterion	Why it matters
You made or clearly owned the decision	Otherwise it is someone else’s mistake and you are narrating
It had real, measurable consequences	Proves you have carried responsibility
There was a signal you could have caught earlier	Gives you a judgment lesson instead of a bad-luck story
You led or materially drove the recovery	Shows ownership through the whole arc, not just the confession
It is resolved	An ongoing problem cannot be told with a lesson
You can tell it in three minutes	Anything longer means you have not distilled it
It does not require naming anyone	Confidentiality and professionalism

The most credible story types for an architect, roughly in order of how well they tend to land:

• Over-engineering. Microservices, event sourcing, or a custom platform adopted before the team or the domain justified it. Cost: velocity and operational load.
• Under-engineering. A single database, a synchronous call chain, or a shared schema that hit a wall you could have seen coming. Cost: an emergency migration.
• The wrong boundary. A service split along a seam that turned out not to be a seam. Every feature crossed it.
• The wrong bet on a technology. A framework, database, or vendor chosen for strengths that did not matter and weaknesses that did.
• Ignoring operational cost. A design that was elegant on paper and miserable to run, on-call, or debug.
• Build vs. buy misjudged. Built something that a service could have provided, or bought something that could not be bent to the need.

Prepare two stories, ideally one over-engineering and one under-engineering. Interviewers sometimes say “give me another one,” and having a second ready shows a pattern of reflection rather than a single rehearsed confession.

Step 2: Tell it in six beats

STAR (Situation, Task, Action, Result) is fine for most behavioral questions and slightly wrong for this one, because it has no place for “why the decision was reasonable” or “what I changed.” Use these six beats instead, with a rough time budget.

Beat	What to say	Time
1. Headline	One sentence: the decision and the fact that it went wrong. “I chose event sourcing for an order system and it cost us about four months.”	10 seconds
2. Context and reasoning	The situation, the constraints, and why the decision was reasonable at the time. Name the assumption it depended on.	40 seconds
3. Signal	What you observed that showed it was wrong, when, and who noticed. Be honest about how long you kept going.	30 seconds
4. Impact	Numbers. Time, money, outage, delayed launch, morale if it is concrete.	20 seconds
5. Response	What you did: how you made the call to reverse, how you communicated it, how you led the recovery.	40 seconds
6. Change in practice	The specific thing you do differently now, stated as a habit the interviewer can picture.	30 seconds

Roughly three minutes. Then stop and let them ask.

Step 3: A worked example

Here is an illustrative composite that follows the beats. It is not a specific real project. The point is the shape.

Headline. A few years ago I chose event sourcing for an order management system, and it turned out to be the wrong fit. It cost us roughly four months of delivery and a migration.

Context and reasoning. We had a real audit requirement: regulators needed to see every state change on an order. We also expected to add several downstream consumers. Event sourcing gave us a perfect audit log for free and made adding consumers straightforward. I had used it before on a smaller system. The assumption I was leaning on, without writing it down, was that the team would be comfortable thinking in events and projections within a few weeks.

Signal. About two months in, feature velocity had dropped by roughly half. Every new field meant a new event version and a projection rebuild. Onboarding a new engineer took three weeks instead of one. I noticed the velocity number early but attributed it to the learning curve. The signal I should have taken seriously was that the two most senior engineers on the team were quietly building an escape hatch: a conventional relational read model they queried directly, bypassing the projections.

Impact. Feature delivery ran at about half speed for four months. The migration back to a conventional model with an explicit audit log table took another six weeks with two engineers. We missed a planned launch by a quarter.

Response. Once I accepted the signal, I wrote a one-page decision record proposing the reversal, with the velocity numbers and the onboarding time, and took it to the team and then to my director the same week. We kept events only for the one workflow where replay actually mattered and moved everything else to a normal transactional model with an append-only audit table. I led the migration plan and made sure the audit requirement was verified against the new design before we cut over.

Change in practice. Two things. First, I now write down the assumption a decision depends on and the condition that would make us revisit it, before we start. In that case: “if onboarding time or velocity drops by more than a third after eight weeks, we reconsider.” Second, when a design has a team-skill dependency, I prototype the risky part with the actual team for two weeks before committing, instead of relying on my own experience with the pattern.

Notice what it does. First person throughout. The original decision is defensible. The signal is specific and the delay in acting on it is admitted. The impact has numbers. The recovery shows communication upward and leadership. The lesson is two concrete habits.

Step 4: Get the language right

• Use “I” for the decision and the miss. Use “we” for the recovery. “I chose. I missed the signal. We migrated.” This is the pronoun pattern of ownership without grandstanding.
• Say the reasonable-at-the-time part explicitly. “Given what I knew, I would make the same call. What I would change is how quickly I would get the information I did not have.”
• Admit the delay. “I noticed at week six and did not act until week twelve. Those six weeks were the expensive part.” Interviewers trust people who volunteer this.
• Do not self-flagellate. One sentence of ownership is enough. Three sentences of contrition make it about your feelings instead of your judgment.
• State the lesson as a habit, not a value. Not “I learned humility.” Rather “I now do X before Y.”

Step 5: Connect it to how you decide now

The strongest candidates close the story by linking it to a decision-making practice they use today. Three that land well with architecture interviewers:

• Architecture Decision Records (ADRs) with an explicit “we will revisit this if” clause. Decisions become reviewable instead of permanent.
• One-way vs. two-way doors. Classify decisions by how reversible they are. Spend real analysis time on the one-way doors. Move fast on the two-way ones and build in the reversal point.
• Prototype the riskiest assumption first. Not the easiest part, the part the whole design depends on.

If you can say “this is how the story changed the way I make decisions, and here is what that looks like in my current work,” you have answered the question the interviewer actually asked.

Follow-Up Questions to Expect

• “What would you do differently?” Not “avoid event sourcing.” Rather: get the missing information earlier, with the specific mechanism from your lesson.
• “Did anyone warn you?” This is an honesty test. If someone did, say so, say why you did not listen, and what you do now to make dissent easier to hear.
• “How do you know it was the decision and not the execution?” Separate the two. “The team implemented the pattern correctly. The pattern’s cost was structural, which is why fixing execution would not have helped.”
• “How did you communicate the reversal to leadership?” Have the actual answer: what document, what meeting, what you asked for. Leaders want to know you bring bad news early with a plan attached.
• “How did the team react?” Be honest. Some relief, some frustration at the wasted work. Describe what you did to make the reversal feel like a shared decision rather than a decree.
• “Give me another one.” This is why you prepared two.
• “What signals do you watch for now?” Velocity trends, onboarding time, escape hatches being built, on-call load, and the number of features that cross a boundary. Name three.

Key Takeaways

• The question tests ownership, judgment, and learning. Pick a story that lets you demonstrate all three.
• Choose a real mistake with real cost. Small mistakes and humble brags both fail.
• Show the decision was reasonable at the time, then name the missing information and why you did not have it.
• The detection story is the interesting part. Say what the signal was and admit how long you took to act on it.
• Put numbers on the impact.
• Use “I” for the decision and the miss, “we” for the recovery.
• End with a specific habit you practice now, not a value you now hold.
• Prepare two stories.

Further Reading

• Michael Nygard, Documenting Architecture Decisions
• Jeff Bezos, 2015 shareholder letter on one-way and two-way door decisions
• Google SRE Book, Postmortem Culture: Learning from Failure
• Annie Duke, Thinking in Bets, on separating decision quality from outcome quality