Run a system design interview
Use a repeatable framework to turn a vague prompt into a defensible design.
- Structure a 45-minute design interview into clear phases.
- Separate functional requirements from non-functional ones.
- Explain why every component should trace back to a requirement.
A system design interview starts with a deliberately vague prompt such as “Design a URL shortener.” There is rarely one right answer. The interviewer is watching how you handle ambiguity, make reasonable assumptions, communicate trade-offs, and drive toward a design that works. A repeatable framework stops you from jumping straight to boxes and arrows.
A framework you can reuse
- Clarify requirements. Functional requirements say what the system does (“users can create short links”). Non-functional requirements say how well it must do it: scale, latency, availability, consistency, durability.
- Estimate scale. Rough requests per second, storage, and bandwidth - just enough to guide decisions.
- Define the API and data model. The key endpoints and the main entities with their access patterns.
- Sketch the high-level design. Clients, load balancers, services, data stores, caches, and queues.
- Deep-dive. Pick the hardest parts (often where the interviewer steers you) and go into detail: bottlenecks, failure modes, scaling limits.
- Wrap up. Summarize trade-offs, what could fail, and what you would build next.
1phases = [("Requirements", 5), ("Estimation", 5), ("API and data model", 5),
2 ("High-level design", 10), ("Deep dives", 15), ("Wrap-up", 5)]
3for name, minutes in phases:
4 print(f"{name}: {minutes} min")
5print(f"Total: {sum(minutes for _, minutes in phases)} min")Requirements: 5 min Estimation: 5 min API and data model: 5 min High-level design: 10 min Deep dives: 15 min Wrap-up: 5 min Total: 45 min
The time budget is a guide, not a script. Some interviewers skip estimation; others spend the whole deep dive on one component. What matters is that you lead the conversation, check in with the interviewer at each transition (“Does this high-level design look reasonable before I go deeper?”), and adapt when they steer you.
Key takeaways
Clarify requirements before drawing anything.
Functional requirements are features; non-functional requirements are qualities like scale, latency, and availability.
Lead the conversation, state assumptions, and check in with the interviewer between phases.
Lesson quiz
6 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: simulate system design building blocks
Use small Python programs to estimate capacity and simulate caches, load balancers, hash rings, and rate limiters. These exercises run locally in your browser.
Sort requirements
The list pairs each requirement with its kind. Print Functional: followed by each functional requirement as - text, then Non-functional: followed by each non-functional one, keeping the original order within each group.
- Grouped requirements
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…