Describe a time you had to make an architecture decision with incomplete information

#Why "I Gathered More Data" Is the Wrong Answer

Almost every mid-level answer to this question is some version of "I did more research until I felt confident." That's not wrong exactly, but it dodges the actual question, which is about judgment under a deadline, not research skills in a vacuum. In a real organization, waiting for full information is itself a decision — and often the more expensive one. The skill an interviewer is probing for is how you decide how much certainty a given decision actually deserves before you act.

#Sort the Decision Before You Make It

I split architecture decisions into two kinds before doing anything else: the ones that are expensive or slow to undo, and the ones that are cheap to reverse. Something like a persistence format, a wire-format contract shared with a backend team, or picking a cross-platform framework at the start of a multi-year project deserves real upfront diligence, because reversing it later means migrating data or rewriting a large surface. Something like a single module's dependency-injection approach, a naming convention, or one screen's local state pattern should just get decided quickly and revisited later if it's wrong — spending a week of research on a decision you could undo in an afternoon is itself a mistake.

#A Concrete Story: Choosing a Sync Strategy Without Final Requirements

The clearest example I can give is picking an offline-first sync strategy before product had validated whether multi-device concurrent editing was actually going to matter to users. The honest options were building custom, app-specific conflict resolution, which is cheaper to build but brittle if requirements grow, or adopting a CRDT-based approach, which is more robust but a real investment to integrate and reason about. I timeboxed a one-week spike: pulled real usage logs from the existing single-device flow to estimate how often two sessions from the same account overlapped in a way that would matter, prototyped the riskiest part of each approach against that data, and made the call with the assumptions written down explicitly rather than left implicit.

#Build the Reversal Path In, Regardless of Which Way You Decide

Whichever direction I go, I architect an off-ramp on purpose: an abstraction boundary — a repository or sync-engine interface — so that swapping the underlying mechanism later doesn't ripple through the UI layer; a feature flag so the new path rolls out gradually instead of all at once; and telemetry specifically aimed at catching the decision being wrong within weeks, not discovering it by accident six months later. This is the part that turns "I guessed" into "I built a decision that survives being wrong."

#Document the Decision, Not Just the Outcome

I write a short record for anything non-trivial: the context, the options considered, the decision, and — this is the part people skip — the specific trigger condition under which I'd revisit it. For the sync example, the trigger was explicit: "if concurrent multi-device editing exceeds five percent of sessions, revisit the investment in a CRDT layer." Eighteen months later, when nobody remembers the original constraints, that sentence is the difference between a calm re-evaluation and an argument about who was wrong.

#Own the Outcome Either Way

Whether the story resolves as "it worked and we never revisited it" or "the trigger fired and we changed direction," the senior signal is narrating the revisit calmly, as evidence the process worked, not as an admission of failure. "We set a condition, the condition fired, we revisited, here's what we learned and changed" is a stronger closing line than either false confidence or an apology.