1. How to Approach a Design Question
1
The picture to keep in your head2
1.1 What is a system design interview, and what isn't it?3
1.2 What is the interviewer actually scoring?4
1.3 What's the step-by-step framework?5
1.4 How do you manage a 45-minute round?6
1.5 What questions should you ask first?7
1.6 What's the difference between functional and non-functional requirements?8
1.7 What's an API, and why define it before drawing boxes?9
1.8 How do you sketch the data model?10
1.9 What does a good high-level design look like?11
1.10 How do you choose what to deep dive into?12
1.11 How do you talk about trade-offs?13
1.12 What if you get stuck or don't know something?14
1.13 What are the most common mistakes?15
1.14 What does the bar look like: fresher vs SDE-2?16
Memory card and where the analogy breaks17
Practice: five levels18
Interview questions19
Solutions20
Sources21
Code lab1. How to Approach a Design Question
1.7 What's an API, and why define it before drawing boxes?
3 min read+10 XP
At the architect's desk: Before planning rooms, the architect decides the doors: where people come in, where deliveries arrive, where the car goes. The doors decide how everything inside is laid out.
In the interview: An API (application programming interface) is the list of operations your system offers to the outside world: what goes in, what comes out. Write it before drawing any boxes, because every box you draw later exists to serve these operations.
For the URL shortener, two operations cover both functional requirements:
POST /urls
body: { "long_url": "https://example.com/a/very/long/page" }
returns: { "short_url": "https://sho.rt/aB3x9Q" }
GET /{code}
example: GET /aB3x9Q
returns: a redirect to https://example.com/a/very/long/page
(404 Not Found if the code doesn't exist)
Keep it short: the main operations, their inputs and outputs, and the error case. You don't need every header or field.
Memory code: "Doors before rooms." Decide what goes in and out before you design the inside.