Art of Codeartofcode
Lesson 17 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

Practice: five levels

3 min read+10 XP

Assignments

Five levels. Do them in order. Answers are in "Solutions" at the end, so try first.

Level 1: Think (no code)

A. Functional or non-functional? Use "verbs vs adjectives".

  1. Users can upload a profile photo.
  2. The feed loads in under 200 ms for most users.
  3. Users can follow other users.
  4. No uploaded photo is ever lost.
  5. The app stays up even if a whole data centre goes down.
  6. Users can search posts by hashtag.

B. The prompt is "Design a food delivery app's order tracking." Write one clarifying question for each letter of SCALE.

Level 2: Calculate

You're designing the URL shortener. You agree these assumptions with the interviewer:

  • 100 million new short links per month (use 30 days per month).
  • Links are read 100 times for every one created.
  • Each stored link takes about 500 bytes.
  • Keep links for 5 years.
  1. How many new links per second, on average?
  2. How many redirects per second, on average?
  3. How much storage do you need for 5 years?
  4. Codes use base62 (0-9, a-z, A-Z). What's the shortest code length that gives enough unique codes for 5 years of links?

Level 3: Build

Write a small in-memory URL shortener, Shortener, with:

  • shorten(long_url): returns a short URL. Reject anything that doesn't start with http:// or https://.
  • resolve(code): returns the long URL, or None if the code doesn't exist.
  • Codes come from a counter written in base62, so they're always unique.

Check that:

  1. Shortening then resolving returns the original URL.
  2. Shortening the same long URL twice returns the same short URL.
  3. Different long URLs get different codes.
  4. An unknown code returns None.
  5. An invalid URL is rejected.

Level 4: Debug

A. Buggy code. A teammate wrote this to avoid a counter: "random codes can't be guessed, and 62^6 is 56.8 billion, so they'll never clash." After a year, users report that some short links open someone else's page.

python
  1. Find the bug. Explain step by step how a user ends up on someone else's page.
  2. Fix it.

B. Buggy interview answer. Here's how a candidate opened "Design a URL shortener". Find at least four mistakes from this chapter.

"OK, so we'll use microservices: a shortening service, a redirect service and an analytics service, talking over Kafka. We'll put Cassandra underneath because it scales. For the codes I'll hash the URL with MD5. Then for the front we'll have a CDN... (two minutes of silent drawing)... and that should handle a billion users."

Level 5: Design

Run the full framework on: "Design Pastebin" (users paste text, get a short link, and anyone with the link can read it).

Deliver, in order, as you would on the whiteboard:

  1. Functional and non-functional requirements, plus the SCALE questions you'd ask.
  2. Your assumed numbers and a rough estimate of writes per second, reads per second and storage per year.
  3. The API (main operations only).
  4. The data model.
  5. A high-level design, with one read and one write walked through it.
  6. What you'd deep dive into, and why.
  7. Two big trade-offs, each in "Because, Cost, Unless" form.