System Design Mock Interview: How to Talk Through It

Most people who fail a system design round do not fail because they lack knowledge. They fail because they talk without a plan, draw twenty boxes in the first five minutes, never say a number, or go silent when asked about a failure. This lesson is about what to say, and when.

It is not a new theory lesson. The theory is already in other lessons, and I link to it instead of repeating it:

• The method: A 5-Step Framework for Any System Design Problem.
• The numbers: Back-of-the-Envelope Estimation, Step by Step.
• How a practical design interview is run: How to Run a Practical Design Interview.
• The full worked designs: Design a URL Shortener and Design a Notification System.
• Telling stories about past work: The Experience-Level Round.

Here we take one problem, a short-link service, and say it out loud from the first minute to the last, with times.

Words used in this lesson

• A mock interview is a practice interview with a friend or a timer. You do the real thing out loud, so mistakes happen in practice and not in the real room.
• Functional requirements say what the system does ("create a short link, redirect from it").
• Non-functional requirements say how well it must do it (fast, available, durable, safe).
• Scale numbers are the rough sizes: users, requests per second, data per year.
• QPS (queries per second) is the number of requests in one second. Peak is the busiest moment, usually a few times the average.
• Back-of-the-envelope means rough maths done quickly, with round numbers, to decide a design.
• An API sketch is a short list of calls (method, path, input, output) without full detail.
• A trade-off is a choice where you win one thing and lose another. Fast and simple often cost something else.
• A single point of failure (SPOF) is one part whose failure stops the whole system.
• Failover means switching to a spare when the main part fails.
• A deep dive is the part of the interview where you go into one area in detail.
• Think aloud means saying your thoughts as you have them, so the interviewer can follow and help.

The 45-minute timeline

A 45-minute round has about 40 minutes of real design time. The rest is hello and goodbye. This is the clock I practise with. Keep a small clock or timer in view.

Two rules about the clock:

1. Say the plan once, at the start. "I will take about five minutes for requirements, then boxes, then I would like to go deep on code generation and the redirect path, and keep five minutes for failures." Now the interviewer knows your plan, and they can steer you early.
2. Never spend more than ten minutes on the first drawing. The most common time trap is a beautiful first diagram and no time for the hard part.

This is the same shape as the five steps in Lesson 59 of the system design series, and the six-step frame in Design problems, Lesson 0. The names differ a little. The idea is the same: clarify, size, sketch, deepen, break, summarise.

The first five minutes: requirements, scale, API

The first five minutes decide the mood. Do three things, in this order.

Step 1. Repeat the problem in your own words

"So we are building a service that takes a long URL and gives back a short one, and when someone opens the short one, we send them to the long one. Is that right?"

This takes ten seconds. It proves you listened, and it catches a wrong guess early.

Step 2. Ask five or six scoping questions

Ask short, closed questions. Each should change the design. Do not ask 20 questions. Do not ask questions whose answer would not change what you draw.

When the interviewer says "you decide", decide out loud and write it down: "I will assume 100 million new links a month and 100 reads for each write. I will write that on the board. Tell me if you want different numbers."

Step 3. Say the non-functional needs in one breath

"For quality I care about four things: redirects must be fast, the service must be highly available, codes must be unique, and a saved link must not be lost. I accept that analytics can be a little late."

That last sentence is a trade-off you made before the interviewer asked. It shows good judgement.

Step 4. Sketch the API in two lines each

Say the call, the input and the output. Do not describe every field.

POST /links   { "longUrl": "...", "alias"?: "...", "expiresAt"?: "..." }   ->  201 { "code": "aZ3k9Qp" }GET  /{code}                                                                ->  302 Location: <longUrl>   (or 404 / 410)

Say: "I will use 302 so the browser asks us each time. That lets us count clicks and turn off bad links. 301 would be cheaper, but the browser would cache it." (This choice is explained in Design problems, Lesson 1.)

Rule of thumb: after five minutes, there should be four things on the board: requirements, numbers, API, and the question you will go deep on.

How to draw boxes

You are not an artist. You are making a map that the interviewer can follow while you speak.

1. Draw left to right, in the order a request travels. Client, load balancer, app servers, cache, database. If you draw it in the order of the story, you can point and tell the story.
2. Start with the smallest working picture. Client, one service, one database. Walk one request through. Only then add parts, and say why you add each one.
3. Name each box with a job, not a product. Write "cache" and "database", and say "Redis" and "Postgres" if you like. The picture should still make sense if you change the product.
4. Draw arrows with a short label. "GET /abc", "read", "async event". An arrow with no words hides the important thing: what travels on it.
5. Use two line styles. A solid arrow for the request the user waits for. A dashed arrow for background work (analytics, cleanup). This one habit answers many questions before they are asked.
6. Number the steps of the main request. Write 1, 2, 3 next to the arrows and say them as you point.
7. Leave space. You will add a replica, a queue or a second region later.

A good first picture for our problem has only five boxes:

 client --1--> [ load balancer ] --2--> [ app servers (stateless) ] --3--> [ cache ] --4 (miss)--> [ database ]                                                 |                                                 +- - - - async - - - -> [ queue ] - - -> [ analytics store ]

Say it like this: "1: the click hits a load balancer. 2: it goes to any app server. The servers keep no state, so I can add more. 3: the server looks in the cache. 4: only on a miss, it reads the database. The dashed path is click counting. It does not block the redirect."

How to state a trade-off in one sentence

A trade-off sentence has four parts: I choose A, because of B, and I give up C, which is fine because D.

Here are more with the same shape:

Three habits make these sentences strong:

• Say what you give up. If you only list the benefits, it sounds like you did not think.
• Tie the reason to a number or a requirement you already said. "Because reads are 100 times more" is a reason. "Because it is better" is not.
• Stop after the sentence. Do not defend it for two minutes. If the interviewer wants more, they will ask. Then you go deeper.

How to use numbers

You do not need exact answers. You need round numbers, shown work, and a decision at the end. The full method is in Back-of-the-Envelope Estimation; here is how to say it.

Rules for speaking numbers:

1. Round hard. A month has about 2.5 million seconds (30 days times 86,400, which is 2.59 million). Say "about 2.5 million" and move on.
2. Say the unit every time. "40 writes per second", "3 terabytes", not "40" or "3".
3. Show the line, then the answer. "100 million a month, divided by 2.5 million seconds, is about 40 per second." The interviewer can check you.
4. Ask "so what?" after every number. 40 writes per second is small: one database handles that. 4,000 reads per second is more, so a cache helps. The number is only useful if it changes a choice.
5. Peak is about 5 times the average. Say that you assume it. Design for peak, not average.
6. If you are off by 2 times, nobody cares. If you are off by 100 times, say it again. Check the size of the answer: "3 terabytes. Does that sound right? 6 billion rows at half a kilobyte each. Yes."

A pattern I use to open the numbers: "Let me do two quick numbers: traffic and storage. Then I will decide if one machine is enough."

How to handle "what if X fails?"

This question is not an attack. It is the main test. Interviewers ask it to see if you think about failure as normal. A calm, repeatable answer beats a clever one.

Use four steps. I call it detect, limit, recover, accept.

1. Detect: how do we know it failed? (health checks, timeouts, alerts)
2. Limit: how do we stop the damage from spreading? (timeouts, retries with a limit, circuit breakers, falling back to a degraded mode)
3. Recover: how does it come back? (a replica takes over, a new instance starts, we replay from a queue)
4. Accept: what do users see in the meantime, and is that acceptable? (slower, slightly old data, or a clear error)

Example, in speech: "If the cache goes down: we detect it with a timeout on the cache call. We limit damage by falling back to the database, with a short timeout, so a slow cache cannot block the request. Reads go up by 100 times on the database for a while, so I would also have a limit on connections, and I would warm the cache again slowly after it returns. Users see slightly slower redirects, not errors. I accept that for a short time."

Rules for this part:

• Do not say "it will never fail". Everything fails.
• Do not add three new boxes in a panic. Often the right answer is "I accept it", with a reason.
• Separate the paths. Say which path the user waits for (redirect) and which can be late (analytics). This is the strongest sentence in a failure answer.
• If you do not know, say how you would find out. "I do not remember the exact failover time of that product. I would read its docs, and test it in a drill."

Phrases to use, and phrases to avoid

Words carry the interview. Use these.

Phrases to use

Phrases to avoid

A worked walkthrough: design a short-link service

Below is a transcript-style answer. "I" is you. The interviewer's lines are short. Times are minutes:seconds from the start. The design matches Design problems, Lesson 1, so read that for the full theory and code. Here we only practise speaking.

0:00 to 0:05, requirements

Interviewer: "Design a URL shortener."

Me (0:00): "Sure. So the service takes a long URL and returns a short link, and when someone opens the short link, we redirect them to the long URL. Is that right?"

Interviewer: "Yes."

Me (0:20): "May I ask a few questions? First, do users choose their own alias, like /summer-sale?"

Interviewer: "Nice to have. Skip it for now."

Me (0:30): "OK, I will note it as out of scope and come back if there is time. Do links expire, and do we count clicks?"

Interviewer: "Links can have an optional expiry. Click counts are a nice feature."

Me (0:45): "Good. How big should I assume it is?"

Interviewer: "You decide."

Me (0:50): "I will assume 100 million new links per month, and that people click about 100 times for every link created. I will write that down. For quality, I care about four things: redirects must be fast, in tens of milliseconds, and highly available; codes must be unique; saved links must not be lost; and I accept that click counts can be a little late. Is that a fair start?"

Interviewer: "Fair."

Me (1:30): "Here is my plan for the 45 minutes. A few minutes on numbers and the API, then a first drawing, then a deep dive on how we make unique codes and keep redirects fast. I would like to keep the last ten minutes for failures and scale."

(What this showed: restate, scope, assume out loud, state the quality goals and a trade-off, say the plan. About ninety seconds.)

1:30 to 10:00, numbers and API

Me (1:40): "Quick numbers. Writes first. 100 million a month divided by about 2.5 million seconds in a month is about 40 writes per second. Peak, say 5 times, is about 200. That is small. One database can take that."

"Reads are 100 times more: about 4,000 a second, and about 20,000 at peak. That is the number that shapes the design. It tells me reads must come from a cache, and the app servers must be easy to add."

"Storage. If we keep links for 5 years: 100 million times 12 months times 5 is 6 billion links. At about 500 bytes each, that is 3 terabytes. That is too much for a tiny server, but fine for a normal database with replicas. Write speed is not the problem here. Size is the thing to watch."

"Code length. If I use letters and digits, 62 choices per character, 7 characters give 62 to the power 7, which is about 3.5 trillion codes. We need 6 billion, so we use under 1 percent of the space. That makes random codes safe."

Me (5:00): "The API, in two calls." (writes on the board)

POST /links  { longUrl, expiresAt? }  ->  201 { code }GET  /{code}                          ->  302 Location: longUrl   (404 unknown, 410 expired)

"I use 302, so the browser asks us on every click. That costs more traffic, but gives us click counts and a way to turn off bad links. A 301 is cheaper because browsers remember it, but we lose both."

Interviewer: "Why not just 301 and count in the browser?"

Me (6:30): "Good question. Counting in the browser would need a script on the target page, and we do not control that page. So the server must see each click, which means 302. If analytics did not matter, I would use 301 and save load."

(What this showed: every number ends in a decision. The interviewer's challenge was answered with the reason.)

10:00 to 20:00, boxes

Me (10:00): "Now I will draw the smallest version." (draws: client, app server, database) "The client sends a POST to the app server. The server makes a code, saves code -> longUrl in the database, and returns the code. The client opens the short link, the server looks up the code, and answers 302."

"Reads are 4,000 a second, so I add a cache between the server and the database." (draws cache, solid arrow) "The server checks the cache first. On a miss it reads the database and fills the cache. Because links almost never change, a cache with a long lifetime works well. If I estimate a hot set of about 10 gigabytes, it fits in one cache node with a spare."

"I put a load balancer in front, and I keep the app servers stateless, so any server can answer any request." (draws load balancer)

"One more thing, shown dashed: click counting." (draws a dashed arrow to a queue, then to an analytics store) "The server puts a small click event on a queue and returns the redirect at once. A worker adds up the counts later. The user never waits for it."

Interviewer: "Why not update a counter in the database at each click?"

Me (15:30): "At 20,000 peak clicks a second, that is 20,000 writes on a hot row, which would be the slowest part of the system. A queue lets me batch them. The cost is that counts are a few seconds late, and I said earlier that is acceptable."

Me (18:00): "Let me walk one click through the picture." (points along the numbered arrows) "Load balancer, app server, cache hit, 302. About one or two milliseconds inside our system. On a miss, one database read, then the cache is filled."

(What this showed: smallest picture first, each box added for a number-based reason, a dashed line for background work, a walk-through at the end.)

20:00 to 35:00, deep dive

Interviewer: "Let's go deep on creating codes. How do you make a unique one?"

Me (20:10): "I see three options. One: hash the long URL and cut it. Two: a global counter turned into letters. Three: random codes with a retry. I will explain each in a sentence, then choose."

"Hash and cut: simple, but two different URLs can give the same prefix, and the same URL always gives the same code, which is a problem if two users want separate links. Counter: no collisions ever, but one counter is a single point of failure, and sequential codes are easy to guess and scrape. Random: no shared state, and the chance of a clash is tiny."

"I choose random 7-character codes, and I give up a guaranteed first-try insert, which is fine because it is rare. The database has the code as the primary key. If the insert fails because the code exists, I make a new code and try again. With 6 billion used out of 3.5 trillion, about 0.17 percent of tries clash at the very end. So the average is about 1.002 tries."

Interviewer: "What if two servers make the same code at the same time?"

Me (24:00): "The primary key makes one insert win and the other fail. The loser retries with a new code. So uniqueness is enforced by the database, not by the app servers. That is why I trust it."

Interviewer: "Now the redirect path. 20,000 reads a second at peak. Walk me through the cache."

Me (27:00): "I use cache-aside: look in the cache, on a miss read the database, then store the result with a time limit. For popular links, hit rate should be very high, because a small share of links gets most of the clicks. I'd measure the hit rate from day one. If it was low, I'd look for a wrong time limit or a cache that is too small."

"Two details. First, expiry: if a link has an expiry date, I store the time with it, and the redirect checks it, so a cached link still stops at the right time. Second, deletion: if we turn off a bad link, we must remove it from the cache too, or it keeps working. I do that on the write path, with a short cache lifetime as a safety net."

Interviewer: "And a stampede? A link goes viral just as its cache entry expires."

Me (31:00): "Good one. Thousands of requests miss at once and hit the database together. I would add a short lock per code, so one request reloads it while the others wait a moment, or serve the old value a little longer while one request refreshes it. I would also add a random amount to the time limit, so entries do not all expire together."

(What this showed: options listed, one chosen with a one-sentence trade-off, uniqueness placed in the database, details like expiry and deletion, and a clear answer to a follow-up with an unknown topic by naming the problem and two fixes.)

35:00 to 42:00, failures and scale

Interviewer: "What if the cache goes down?"

Me (35:00): "We detect it with a short timeout on cache calls and a health check. We limit the damage by falling back to the database. The database then gets up to the full 4,000 to 20,000 reads a second, so I have a connection limit and a small local cache in each app server for the hottest links. We recover by bringing the cache back and warming it slowly. Users see slower redirects but not errors. I accept that for a short time."

Interviewer: "What if the database primary dies?"

Me (37:30): "Reads come from replicas, so redirects continue. A replica is promoted to primary. In that time, creating links is paused or fails with a clear error, and with asynchronous replication we may lose the last few writes. For short links I'd accept a short pause in creating links, but not in redirecting. If losing even one link is not acceptable, I'd use synchronous replication for that and say we pay in write latency."

Interviewer: "What if traffic grows 10 times?"

Me (40:00): "Redirect traffic scales by adding app servers and cache nodes, because they are stateless or hold copies. The first real limit would be database size, not speed: 30 terabytes. At that point I'd split the links table by code into shards, because every lookup is by code. I would not do it today, at 3 terabytes, because it adds work with no benefit."

42:00 to 45:00, wrap-up

Me (42:10): "To summarise. The main path is load balancer, stateless servers, cache, database. Codes are random, 7 characters, made unique by the primary key. Redirects use 302 so we can count and disable links. Clicks go through a queue, so they never slow the redirect. The weakest part of my design is the cache: if it fails, the database takes a big load. Next I would add the connection limit and a drill that turns the cache off on purpose. I did not cover custom aliases, abuse protection or multi-region. I'd start with a block-list check on create."

Interviewer: "Thanks, that was clear."

Self-scoring checklist

After each mock, give yourself one point for each "yes". This is my own list, not an official scoring sheet. Do the same drill in small parts first (only the first five minutes, only the numbers, only one drawing), then run a full 45 minutes with a friend or a timer, and record it.

Start. I repeated the problem. I asked 4 to 6 questions that changed the design. I said my assumptions out loud and wrote them down. I stated the quality goals (speed, availability, durability). I sketched the API. I said my time plan once. (6 points)

Numbers. I computed writes per second, reads per second and storage. I said units every time. Every number ended with a decision. I named a peak and how I got it. (4 points)

Drawing. I started with the smallest picture. I added each box with a reason. Every arrow had a label. I separated the user path from background work. I walked one request through. (5 points)

Trade-offs. I gave at least three, in one sentence each, and each said what I give up. I did not defend a choice for more than a minute. (3 points)

Failures. I answered "what if X fails?" with detect, limit, recover, accept. I said what the user sees. I did not claim anything never fails. (3 points)

Talking. No silence over ten seconds without saying what I was thinking. I used a hint instead of arguing with it. I checked the depth once or twice. I ended with a summary and my own weakest point. (4 points)

Score out of 25: 20 or more is strong. 14 to 19 is good: find the section where you lost points and repeat that drill. Below 14: do the first-five-minutes drill again before you try a full mock. When you listen to the recording, also count filler words and numbers that had no decision after them.

Interview questions

These are questions about the interview itself and how to talk through it. The answers are first person, and you should adapt them to your own style.

Key takeaways

• Keep to a clock: about 5 minutes of requirements, 5 of numbers and API, 10 of boxes, 15 of deep dive, 7 of failures, 3 to summarise. Say the plan once.
• Open by repeating the problem, asking 4 to 6 useful questions, stating assumptions out loud, and sketching the API.
• Draw the smallest picture first, left to right, add parts one by one with a reason, and label every arrow. Show background work with dashed lines.
• Say each trade-off in one sentence: I choose A because B, I give up C, which is fine because D.
• Use round numbers, say units, show the line of maths, and always end with a decision.
• For "what if X fails?" use detect, limit, recover, accept, and say what the user sees.
• Say "I am not sure, here is how I would check" instead of guessing. Take hints gladly. Never go silent without saying what you are thinking.
• End with a short summary and your own weakest point.
• Practise out loud, in small drills first, then full mocks, and score yourself with the checklist.

What's next

Read the full theory for the problem used here in Design a URL Shortener, then try the same speaking pattern on Design a Notification System. Review the frame in A 5-Step Framework for Any System Design Problem and the number tricks in Back-of-the-Envelope Estimation. When you are ready, run How to Run a Practical Design Interview as a checklist on a friend, and keep your people-skills sharp with Experience round, Lesson 14.