Art of Codeartofcode
Lesson 10 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.9 What does a good high-level design look like?

3 min read+10 XP

Draw, Dive, Defend: solve it

At the architect's desk: A floor plan shows every room and how you walk between them. It doesn't show the wiring or the paint. And a good architect checks it by imagining walking through: front door, hall, kitchen. If you can't reach the kitchen, the plan is wrong.

In the interview: The high-level design is a diagram of the main components (boxes) and how requests flow between them (arrows). Two rules make it good:

  1. Start with the simplest design that meets every requirement. Add complexity only when the requirements or numbers demand it.
  2. Walk a request through it. Trace one real request, step by step. If some requirement has no path through your boxes, something's missing.

the URL shortener's first floor plan, with one redirect traced through it.

Figure: the URL shortener's first floor plan, with one redirect traced step by step. Clicks take the green path. The database is touched only on a miss.

Walking a redirect through it:

  1. The user clicks sho.rt/aB3x9Q.
  2. The load balancer sends the request to one of many identical app servers (Chapter 7).
  3. The app server checks the cache for aB3x9Q (Chapter 12).
  4. On a miss, it reads the database and puts a copy in the cache.
  5. It replies with a redirect to the long URL.

Creating a link takes a different path: the app server gets a new unique code from the ID maker (Chapter 10), saves it in the database, and returns the short URL.

Memory code: "Draw it simple, walk it through." The simplest plan that works, then trace a real request across it.