An interviewer asks you to pick an architectural decision your team made in the last year and write its decision record on the whiteboard, then hands you a fact partway through that would have changed the choice. What is being assessed, and how should you work through it?

What the interviewer is testing

Not whether you know the template. The template — context, decision, status, consequences, popularised by Michael Nygard's 2011 post on documenting architecture decisions — takes ninety seconds to learn. The test is whether you can separate the forces that made a choice reasonable from the choice itself, because that separation is the only thing that makes the record useful later.

The mid-question fact is the real exercise. A candidate who quietly rewrites the decision has shown that their records are written backwards from outcomes. A candidate who adds it to Context and says "that would have moved us to option B, and here is the condition I would now monitor" has shown they understand that a record is a dated position, not a claim of correctness.

The clarifying questions that change the answer

• Who was the decision for? A record read by the four people in the room needs three sentences. One read by a future team that has never met you needs the constraints spelled out, including the ones that felt obvious at the time — team size, the deadline, what you already ran in production.
• Was it reversible? A two-way door deserves a short record and a fast decision. An afternoon spent documenting a choice you could undo in a day costs more than being wrong would have. Choose the three-sentence form unless the decision will outlive the people who made it.
• What was rejected, and by whom? Rejected options are the most-read part of a record two years on, because the next team will independently arrive at the same alternatives.

A strong answer's arc

Write the context as facts with dates and numbers: nine engineers, 400 requests per second at peak, a compliance deadline in October, one existing Postgres instance the team already operated well. Then the decision in one sentence. Then consequences split into what you accepted knowingly and what you were uncertain about.

Finish with a trigger condition: "revisit when write throughput passes roughly 3,000 per second or when a second region becomes a contractual requirement." That single line converts a point-in-time judgement into something a later reader can check in five minutes.

When the new fact lands, append and supersede — never edit an accepted record. The old record stays, with a link forward. The history of why the system is shaped as it is disappears the moment records become editable documents, and that history is the entire asset.

Common weak answers

• "I would update the ADR to reflect the new information." Editing accepted history destroys the record's evidentiary value and hides that the team once believed something else for good reasons. This is how a decision log fails silently: every record agrees with the present, so nobody can tell which assumptions were wrong, and the same argument returns every eighteen months.
• "The decision was obviously right." No useful record reads like this. If nothing was given up, it was not a decision.
• Reciting the template headings without producing a single number, constraint or rejected option.

What a strong answer adds

The organisational layer: who had the decision right, who was consulted, and how long the decision took. A record that took three weeks to write for a choice that was reversible in a day is a symptom, not a success, and saying so unprompted separates a senior candidate from a diligent one.