1. Clarify first
Start by clarifying functional and non-functional requirements before designing anything.
step1: clarify-requirementsTyporithm · medium
Step 1 of 8 · intro card
Design Interview
A system design interview follows a repeatable arc: clarify requirements, estimate scale, sketch a high-level design, deep-dive one component, then discuss bottlenecks and tradeoffs. Think out loud and confirm assumptions instead of jumping straight to a solution.
The framework gives you structure under pressure. First clarify the functional requirements (what the system must do) and the non-functional ones (scale, latency, availability), then turn them into rough numbers — users, queries per second, storage.
With the scope agreed, sketch a high-level design: clients, services, databases, and the data flow between them. Only then deep-dive a single component the interviewer cares about, designing its schema, API, or core algorithm in detail.
Finish by naming bottlenecks and the tradeoffs you made. Throughout, think out loud and confirm assumptions — the interviewer is grading your reasoning, not a single right answer.
Clarify functional and non-functional requirements first.
Estimate scale before drawing boxes.
Deep-dive one component, then discuss tradeoffs.
framework:
step1: clarify-requirements
step2: estimate-scale
step3: high-level-design
step4: deep-dive-components
step5: bottlenecks-tradeoffsConnect each part of the code to the concept before you type.
Start by clarifying functional and non-functional requirements before designing anything.
step1: clarify-requirementsBack-of-the-envelope numbers (users, QPS, storage) shape every later decision.
step2: estimate-scaleSketch the major components and their data flow before drilling into any one.
step3: high-level-designPick one component and go deep — schema, APIs, or the algorithm behind it.
step4: deep-dive-componentsClose by surfacing bottlenecks and the tradeoffs you accepted along the way.
step5: bottlenecks-tradeoffsRead the concept map and follow the code breakdown.
Type the implementation, repair mistakes and work through every recall exercise.
Use the final check without hints; revisit weak concepts in short practice sessions.