Art of Codeartofcode
Lesson 9 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.8 How do you sketch the data model?

3 min read+10 XP

At the architect's desk: The store room is designed around how you'll look for things. If you always grab rice by name, you label shelves by name. You don't arrange them by the date you bought them.

In the interview: The data model is what you store and how it's organised. Start from the questions your API will ask of the data, then shape the storage to answer them fast.

The URL shortener's API asks one question again and again: "Given this code, what's the long URL?" So:

Table: urls code (primary key) "aB3x9Q" long_url "https://example.com/a/very/long/page" created_at 2026-10-05 10:00 user_id (optional) who created it

Every lookup is "find by exact code". That's a key-value access pattern: one key, one value, no joins. So a key-value store fits well, and so does a relational table with the code as its primary key. Either is a fair choice if you say why (Chapter 8 covers how to pick).

Memory code: "Store it the way you'll ask for it." The access pattern shapes the data model.