Explain your design decisions like you would in an interview.
Frame every decision as: requirement → options → trade-off → choice → constraint check. Lead with what the design is optimizing for; name the alternatives you rejected and why; call out where you'd revisit. Avoid being defensive — interviewers want to see reasoning, not certainty. Practice a 60-second 'pitch' for one project so you can do it cold.
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:
- What requirement or constraint is this serving? ("We needed sub-100ms search latency on mobile.")
- What options did you consider? ("Server-side search vs client-side index vs prefix Trie.")
- What's the trade-off? ("Server-side meant network roundtrip; client-side meant bundle weight.")
- What did you choose and why? ("Client-side Trie because catalog fit in 200KB gzipped and 95% of searches happened offline.")
- 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."
Follow-up questions
- •Pick a recent project and walk through 2 design decisions using this frame.
- •What's a decision you regret and why?
- •How do you handle pushback on a design decision in a code review?
Common mistakes
- •Sounding like every decision was obviously right.
- •Vague 'we used React' without trade-offs or alternatives.
- •Defensive responses to pushback.
- •'We' when you mean 'I' — or vice versa.
- •Fabricating numbers you don't actually remember.
Performance considerations
- •N/A — behavioral.
Edge cases
- •Decisions made before you joined the team.
- •Decisions where you were overruled.
- •Decisions made under deadline pressure without full evaluation.
Real-world examples
- •STAR-formatted project walkthroughs.
- •ADRs (Architecture Decision Records) — a written version of this frame.