Course · 15

How do I run a system design interview in 45 minutes?

A step-by-step plan for an SDE-2 interview: what to ask, what to draw, how to talk about choices, and how to practise. Built on two public frameworks (Alex Xu's book and Hello Interview). Where something is my advice and not a fact, it says advice.

—Words you need

Each word once, in plain English glossary

01What the interviewer actually scores

SDE-1 vs SDE-2 vs senior core

The interviewer is not checking one right answer. There is none. They watch how you think. Hello Interview names four areas they score. Problem navigation means breaking a big fuzzy problem into parts. Solution design means using known building blocks well. Technical excellence means knowing real tools. Communication means working with the interviewer, not past them.

At SDE-2 the difference is initiative: you bring the numbers, the deep dive and the trade-off before you are asked.

Source: Hello Interview, introduction · Hello Interview, Bitly "what is expected at each level" (both checked 2026-10-25)

02The 45-minute plan

Eight steps, with minutes interview favourite

Alex Xu's book uses four steps. Hello Interview uses six. I split them into eight smaller steps so you always know what comes next. The minutes are a guide, not a law. If the interviewer pulls you somewhere, follow them.

Have a working picture on the board by minute 25. Everything after that is where SDE-2 is judged.

Source: Review of Alex Xu, "System Design Interview", ch. 3 (secondary) · Hello Interview, delivery framework (checked 2026-10-25)

03Clarify requirements

The question checklist core

The question is short on purpose. "Design Twitter" hides a hundred features. Your first job is to pick the 3 to 5 that matter and agree on them. Write them on the board in two lists: what it does (functional) and how well (non-functional).

Functional
  1. Given a long URL, return a short one
  2. Visiting the short URL redirects to the long one
  3. (out of scope) custom aliases, analytics
Non-functional
  - 100M new URLs a day, reads 10x writes      // interviewer confirmed
  - Redirect p99 under 100 ms
  - Highly available; a short link must never point to the wrong URL

Two short written lists, agreed with the interviewer, before the first box. That alone puts you ahead of many candidates.

Source: Hello Interview, delivery · Google SRE workbook, ch. 12 NALSD

04Back-of-the-envelope estimation

Three minutes of maths that pick your tools core

Estimation is not about the exact number. It tells you the size class. Is this one server, ten, or a thousand? Round hard. Say each step out loud so the interviewer can follow and correct you.

// assumptions (agree them with the interviewer)
DAU               = 100M
actions per user  = 10 a day
item size         = 1 KB

1. Average QPS  = 100M x 10 / 86,400      = 11,574  ≈ 12k
2. Peak QPS     = average x 2 to 3          ≈ 35k        // design for this
3. Storage      = 1B items/day x 1 KB      = 1 TB/day ≈ 365 TB/year
4. Bandwidth    = 12k QPS x 1 KB          ≈ 12 MB/s average

The estimate earns its time only if it changes a choice. Say "35k peak QPS, so one database will not hold the writes".

Source: Latency numbers gist · Norvig, "Teach yourself programming in ten years", timing table · SRE workbook NALSD · Page 01 Fundamentals

05API and data model

The contract, then the nouns core

An API (application programming interface) is the list of calls the outside world can make. Write one line per functional requirement. Then list the main entities: the nouns your system stores. This is where you notice missing requirements cheaply.

POST /v1/urls          body: { longUrl }          → 201 { shortUrl }
GET  /{code}                                     → 302 Location: longUrl
// user id comes from the auth token, never from the body

Url   { code PK, longUrl, userId, createdAt, expiresAt }
User  { id PK, email, plan }
// main read: by code → a key-value lookup. No joins needed.

Write the access pattern next to each entity ("read by code"). It picks your database for you in section 07.

Source: Hello Interview, delivery · Pages 02, 06

06High-level design

Draw something that works, end to end core

Start with the plain skeleton below. Walk one request through it, out loud: "the client calls the load balancer, which picks an app server, which checks the cache…". Only then add the boxes this problem needs.

Get the skeleton agreed, then change it. Do not start with the clever part.

Source: Alex Xu review · Pages 03-09

07How to choose a database, cache and queue

A decision you can say in one breath interview favourite

Pick the boring choice first. Leave it only when a requirement forces you. Then say which requirement forced you. That sentence is the trade-off the interviewer wants to hear.

Say "SQL, because we need transactions on orders; I would move to X only if Y". That is a full trade-off in one line.

Source: Kafka design docs · Pages 04, 05, 06, 09, 11

08Deep dives and talking about trade-offs

The sentences that score core

A deep dive zooms into one box and shows the real mechanism. Pick the part that is hardest for this problem: ID generation for a URL shortener, fan-out for a feed, ordering for chat. Then compare two options out loud.

Every pick gets "because" and "the cost is". A pick without a cost sounds like a guess.

Source: Google SRE workbook, NALSD · phrases are advice

09"What if traffic grows 10x?"

The most common follow-up interview favourite

This question checks if you know where the design breaks first. Do not list every tool you know. Use the numbers: multiply your peak QPS and storage by ten, and find the first box that cannot take it.

Peak reads go 35k → 350k QPS. Peak writes go 3.5k → 35k.
1. App servers are stateless: add more behind the LB. Cheap.
2. Feed reads already hit Redis; add Redis shards for memory.
3. DB writes at 35k/s is past one primary  // the real bottleneck
   → shard posts by user_id; move counters to Redis with periodic flush.
4. Celebrity fan-out grows too: switch those users to pull-on-read.

Answer 10x with numbers: "this box hits its limit first, so I change this box". Not with a shopping list.

Source: High Scalability on Raffi Krikorian's 2012 talk · Pages 07, 04

10Thinking out loud

Silence scores zero core

The interviewer can only score what they hear. A great idea you keep in your head is worth nothing. Talk in a loop: say it, draw it, check in, adjust.

Check in at least once per step. It also saves you from building the wrong thing for ten minutes.

Source: Hello Interview, introduction · Alex Xu review

—When to use what

Situation → pick → why decision table

—Common mistakes

What sinks good engineers traps

—Building blocks cheat sheet

One line each, with the course page to revise links

—Practice plan, week by week

Eight weeks, about an hour a day advice

—Interview questions

About the interview itself, with model answers 20 questions

—Cheat sheet

Memorise these numbers

—Sources

—Where next

Use the framework on real problems course

Next, page 16 Classic designs runs this exact framework end to end on eleven classic questions. Before that, page 14 covers the monitoring you mention in the wrap-up. All pages are on the course home.