Art of Codeartofcode
Lesson 4 of 21

1. How to Approach a Design Question

1
The picture to keep in your head
2
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 breaks
17
Practice: five levels
18
Interview questions
19
Solutions
20
Sources
21
Code lab
1. How to Approach a Design Question

1.3 What's the step-by-step framework?

3 min read+10 XP

At the architect's desk: A good architect always works in the same order: ask what's needed, size it, plan the doors and the store room, draw the floor plan, zoom into the tricky part, then walk the family through it.

In the interview: Same order, seven steps:

  1. Requirements: functional and non-functional (1.5, 1.6).
  2. Estimates: rough numbers for traffic and storage (Chapter 2).
  3. API: the operations the system offers (1.7).
  4. Data model: what you store and how you'll look it up (1.8).
  5. High-level design: the boxes and arrows (1.9).
  6. Deep dive: zoom into the hardest part (1.10).
  7. Trade-offs and wrap-up: what you chose, what it costs, what you'd improve (1.11).

The first four steps are where you understand the problem. The last three are where you solve it. Read the first four letters: Requirements, Estimates, API, Data model. That's READ. You read the problem before you design it.

Why this order? Each step feeds the next. Requirements tell you what to estimate. Estimates tell you whether one database is enough. The API tells you which data you need. The data model tells you what storage fits. Skip a step and you're guessing.

Memory code: "READ, then Draw, Dive, Defend." Requirements, Estimates, API, Data model. Then the high-level drawing, the deep dive, and defending your trade-offs.