An interviewer asks which architectural analogy you reach for too often. Assume you genuinely do not know the answer. How would you find it from your own written record, and what would you do with the finding?

What the interviewer is testing

Not humility. They are testing whether you have a method for inspecting your own judgement, because pattern recognition is the source of an experienced architect's speed and of their most confident errors, and the errors are invisible from the inside: the analogy that fires fastest feels like insight. An answer that names a fashionable anti-pattern ("I over-use microservices") with no evidence behind it tells the interviewer you have never looked.

The procedure

This is a two-hour exercise on your own artefacts, written between 2023 and now.

1. Collect the last 20 written decisions you authored or strongly influenced: decision records, design documents, review comments where you pushed a direction.
2. For each, write the one sentence naming the prior case you argued from. Almost every decision has one, and it is usually implicit: "this is the same shape as the ingestion pipeline at my last company", "this is the hot-partition problem again". If you cannot name a prior, mark it as reasoned from scratch; that count matters too.
3. Count the priors. Any single prior appearing in more than about a third of the decisions is a candidate over-application. On 20 decisions, that is 7 or more.
4. For each candidate, write the three preconditions the original case satisfied — the properties that made the solution work there, not the symptoms. Then check each precondition against every decision where you applied it.
5. Count the misses. A prior applied 7 times with at least one precondition failing in 3 of them is your answer.

What the finding looks like

The failures cluster, and the cluster is the real output. The precondition that breaks is almost never random: it is one dimension, usually write volume, team size, consistency requirement, or whether an operator is available at 3am. "I apply the event-log pattern from a system that had three producers and one consumer to situations with many consumers and no schema owner" is a finding. "I over-index on scalability" is not.

What to do with it

Not stop using the pattern. Attach the preconditions to the pattern inside your own notes, so recall drags the check along with it — the pattern and its entry conditions become one object, and the check costs ten seconds instead of an afternoon. Then ask a peer the cheap version of the same question: "what do I always say?" Colleagues answer this accurately and immediately, and it covers the gap in the written audit.

The audit's own failure mode

Your written record contains the decisions important enough to write down. The analogies you apply in hallway conversations, in standups and in code review are the high-frequency ones, and they are absent. That skews the finding towards large decisions and hides the habitual ones, which is why the peer question is not optional.

Common weak answers

• "I do not think I have one." Read as either no self-examination or no decisions. Experience is pattern accumulation, and accumulation without pruning produces over-application by construction.
• "I always reason from first principles." This is slower than the job allows and it is not what the interviewer sees in your work. It also hides the real risk, because an architect who believes they never pattern-match cannot audit the matching they are doing anyway.

What a strong answer adds

Run the same audit on the team's records, not just yours. Shared blind spots are organisational: four teams all reaching for the same prior because it is the one the founding engineers brought with them. That finding is worth more than your personal one, because it explains why four systems have the same unexamined shape — and the fix is the same, which is writing the preconditions next to the pattern in the place where people look it up.