Day 66: System Design Framework: How to Structure a 45-min Interview
Internalize a repeatable structure for ANY frontend/mobile system design prompt, so you never freeze on "where do I even start".
Study
Concepts
A 5-phase structure that fits almost any 45-minute slot
(1) Clarify requirements (5 min): restate the prompt, ask about scale (how many users, how much data), platform (web/mobile/both), and explicitly separate functional vs non-functional requirements — never start designing before this. (2) High-level architecture (10 min): sketch the major pieces (client, API layer, key services) and how data flows between them, at a level someone could follow without deep expertise. (3) Deep dive (15-20 min): the interviewer will usually steer you into 1-2 areas to go deep — this is where Days 41-50's specific knowledge (caching, offline-first, state machines, rendering strategy) gets applied concretely. (4) Trade-offs (5 min): proactively name the alternatives you did NOT choose and why — this is often worth more signal than the "right" answer itself. (5) Wrap-up (a few min): summarize, mention what you would monitor/measure post-launch, and note anything you would revisit given more time.
The single most common failure mode is skipping phase 1 and diving straight into a specific technology choice — interviewers are explicitly testing whether you ask clarifying questions BEFORE committing to an architecture, because in real work the requirements determine the architecture, not the other way around.
Narrate your thinking, don't just produce an answer
A system design interview evaluates your PROCESS, not just your final diagram — verbalize the reasoning behind each decision ("I'm choosing SSR here because SEO matters for a public product page, but I'd use CSR for the authenticated dashboard since SEO doesn't apply there") so the interviewer can follow and probe your judgment, not just your knowledge.
It is not only acceptable but expected to say "I don't know the exact number, but I would estimate/measure X" when a precise fact is not something you have memorized — confidently reasoning through an estimate is a stronger signal than either guessing wrong with false certainty or freezing.
See It
Visualizations
Visualization
A 45-minute system design interview, phased
~5 min
~10 min
~15-20 min
~5 min
remaining time
Build It
Code Examples
A clarifying-question checklist to run through out loud
Scale & users
- Roughly how many active users? Read-heavy or write-heavy?
- Any specific device/network constraints (low-end Android, poor connectivity)?
Platform & scope
- Web, mobile, or both? One shared codebase or platform-specific?
- Is this a new product or an addition to an existing one?
Functional requirements
- What are the 3-5 core user actions this feature must support?
- What is explicitly OUT of scope for this design?
Non-functional requirements
- Real-time requirements? Offline requirements? SEO requirements?
- Any known constraints (must integrate with an existing auth system, etc.)?
-> Only after these are answered: start sketching architecture.Remember
Key Takeaways
- Always clarify requirements FIRST — jumping to a solution before this is the most common, most costly interview mistake.
- Explicitly separate functional (what it does) from non-functional (scale, latency, offline, SEO) requirements — they drive different decisions.
- Narrate your reasoning throughout — the interview evaluates process and judgment, not just the final diagram.
- Proactively naming rejected alternatives and why is often stronger signal than the chosen design itself.
- A reasoned estimate stated with appropriate confidence beats both a guessed "fact" and a frozen silence.
Do It
Practice
- 1Time yourself running through the clarifying-question checklist out loud for a random prompt ("design Instagram Stories") in under 5 minutes.
- 2Pick one system design case from Week 10 and re-answer it explicitly following all 5 phases, timing each phase.
- 3Record yourself (audio) doing a 45-minute mock design and review it for places you jumped ahead without narrating reasoning.