An interviewer asks: "Tell me about an architectural decision you got wrong." What is being tested, what does a weak answer look like, and what does a strong one contain?

What the interviewer is testing

Three things, none of them humility. Whether you have a feedback loop at all, whether you can describe a decision in terms of the information available at the time rather than with hindsight, and whether your conclusion generalises or is a grudge.

The first is the real filter. Architectural decisions return their verdict in 12 to 36 months, often after the person who made them has changed team. An architect with no examples either has not owned a decision long enough to see it land, or is not looking.

The clarifying questions that change the answer

Ask which kind of wrong they want: a choice that was reasonable with what you knew and turned out badly, or one you should have got right. They are different stories. The second is more valuable and more uncomfortable, and volunteering it is a strong signal.

A strong answer's arc

1. The decision and the constraints at the time, in one or two sentences with numbers. "Four engineers, a six-month regulatory deadline, 200 requests a second and no operations staff."
2. What you chose and why it was defensible then. If it was not defensible, say so plainly; that is the better answer.
3. How you found out. This is where the answer is won or lost. "Our p99 doubled at 3x traffic and I had assumed it would be linear" is a feedback loop. "Someone complained eventually" is not.
4. The cost, quantified. Two engineer-months of rework, a migration that took a quarter, an incident with a stated duration.
5. The generalisation, stated as a rule you now apply. "I now write down the load at which a design stops working, and I put it in the decision record" is transferable. "I would use Postgres next time" is not.
6. What you would still do the same, because a decision with zero defensible parts is usually being misremembered.

Common weak answers

• The humblebrag. "I over-engineered it because I cared about quality." This says the lesson was about other people's patience.
• The blameless abstraction. "We did not gather enough requirements." True of everything, therefore useful about nothing.
• The technology grudge. A story whose lesson is that one vendor or language is bad. It tells the interviewer how you will reason about the next choice, which is by prejudice.
• A decision that was somebody else's. If the story's protagonist is a previous architect, it is not an answer to the question asked.

When this is the wrong story to tell

Do not reach for a decision that is still contested at your current employer, and do not choose one whose honest telling requires disclosing a security weakness or a customer's identity. Pick a decision that is closed, whose cost is known, and where the generalisation is something you can show you now do. If you genuinely have no example, say what you would look for in your own current decisions and how you would know — thinner, and far better than an invented failure, because invented ones collapse on the second question.

What a strong answer adds

The senior layer is calibration. "I was 80% confident in that assumption and did not write it down, so nobody could check it. Now the assumption and its confidence go in the decision record, and the record names the signal that would falsify it." That answer describes a change to how decisions are made, not merely to what was decided, which is the difference between an engineer's answer and an architect's.