Your team writes ADRs and nobody reads them. What is wrong with them?

What the interviewer is testing

Whether you know what makes a decision record valuable six months later, which is not what most templates emphasise.

The likely problems

Written after the fact. The reasoning was available in the moment; reconstructed rationale is rationalisation, and it omits precisely the constraints that were operative.

No rejected options. This is the highest-value content and the most frequently omitted. Six months later nobody asks "what did we choose" — that is visible in the code. They ask "did we consider X", and without the rejected options the team relitigates the same debate with less information.

No context or constraints as they were. A decision that looks wrong today was often correct given a deadline, the team's skills, or a contract that has since expired. Without that, the record invites contempt for predecessors rather than understanding.

Too long. ADR practices die from length — nobody writes the fifth one if the first took a day. One page.

Stored away from the code, in a wiki nobody opens, rather than in the repository where people working on the system will find them.

Edited rather than superseded, which destroys the history of how thinking changed — the part that is most instructive.

The fix

Write at decision time. Record rejected options with reasons. Record context and constraints. Keep to a page. Store with the code. Supersede, never edit.

What a strong answer adds

The strongest signal that ADRs are working: someone joining the team reads them to understand why the system is the way it is, and someone proposing a change reads the relevant one first. If neither happens, the practice is producing artifacts rather than value — and it is better to write three genuinely useful records a year than forty that nobody consults.

Common weak answers

A better template. Mandating that ADRs be read, which does not make them worth reading.