When an interviewer asks you to "explain your design decisions," they're testing how you think, not whether your design is "right." Structure the answer so the reasoning is visible.

The 5-part frame for every decision

For each major decision, walk through:

1. What requirement or constraint is this serving? ("We needed sub-100ms search latency on mobile.")
2. What options did you consider? ("Server-side search vs client-side index vs prefix Trie.")
3. What's the trade-off? ("Server-side meant network roundtrip; client-side meant bundle weight.")
4. What did you choose and why? ("Client-side Trie because catalog fit in 200KB gzipped and 95% of searches happened offline.")
5. Where would you revisit? ("If the catalog grew past 1MB, we'd flip to server-side.")

The 60-second project pitch

Have one project ready that you can pitch cold:

"We built X for Y users. The hardest constraint was [Z]. Our architecture was [3-sentence overview]. The key trade-offs were [2-3 named ones]. I owned [my piece]. If I did it again, I'd [change ONE thing]."

Practice this until it's effortless — interviewers ask some form of this in nearly every loop.

Talk about trade-offs explicitly

Avoid sounding like every decision was obviously correct. Interviewers know real design has trade-offs; pretending otherwise is a yellow flag.

✓ "We chose X. The cost was Y, which we accepted because Z." ✓ "I picked A over B; A is simpler to operate, B is faster — we needed simpler." ✗ "We chose X because it was the right answer."

Name your alternatives

"We used React Query" alone is weaker than "We considered Redux Toolkit Query and React Query; we picked React Query because of the simpler mutation model and our team's existing familiarity."

This shows you actually evaluated, not just defaulted.

Quantify when you can

"Faster" → "p95 LCP went from 4.2s to 2.1s on 4G." "Less memory" → "Heap dropped from 80MB to 30MB after virtualizing." "More reliable" → "Crash rate fell from 0.4% to 0.05% in the week after."

Numbers separate signal from hand-waving.

Acknowledge what you didn't choose

"We didn't try X because we already had Y working — but if I were starting fresh, X might have been better."

This is honest and shows judgment about cost-of-change.

Distinguish what you built vs what the team built

Use "we" carefully. Be explicit about your specific contribution. "The team did the migration; I designed the rollback path and the gate." Interviewers will probe — be honest about scope.

Avoid the defensive trap

If the interviewer pushes back ("why not Z?"), don't dig in. Acknowledge the alternative:

• "Yeah, Z would've worked too. We didn't pick it because [reason]. If [condition], we'd switch."

Defending every choice as obviously correct kills the conversation. Curiosity and confidence in the reasoning, not the answer, is what they're after.

When you don't remember a detail

"I don't remember the exact number, but it was in the order of [X]." Better than fabricating. Or: "We had a doc; let me reason about what we likely chose."

Common interview prompts this answers

• "Walk me through a project you're proud of."
• "Why did you choose X here?"
• "What would you do differently?"
• "Why not Y instead?"
• "How did you decide between A and B?"

Interview framing

"For each decision: name the requirement, the options you considered, the trade-off, the choice, and where you'd revisit. Have a 60-second project pitch you can deliver cold: what you built, the hardest constraint, the architecture in three sentences, the trade-offs, your specific contribution, and one thing you'd change. Quantify outcomes when you can. Acknowledge alternatives you didn't pick. Don't be defensive when challenged — say 'yes, that would also have worked; we chose this because…' The interviewer is grading the reasoning, not the answer."