Split View: 시스템 설계 면접 준비법 — 정답이 아니라 좁혀 가는 과정을 채점받는 45분

How to Prepare for a System Design Interview — 45 Minutes Graded on How You Narrow Down, Not on the Answer

Introduction — Why 45 Minutes Evaporate in Front of a Whiteboard

There is a familiar scene. The moment the interviewer says "design a URL shortening service," the candidate picks up the pen. Client, load balancer, web server, database. Five boxes and six arrows, done in three minutes. Then, about 25 minutes in, the interviewer asks: "How many requests a day does this have to handle?" Only then does the candidate realize they have been drawing a picture without deciding anything.

This failure is not a knowledge problem. The same candidate knows Kafka and knows sharding. What collapsed was the process. A system design interview is a problem left deliberately open so that no correct answer exists, which is exactly why the scoring sheet points at the process rather than the artifact.

Honestly, there is skepticism inside the industry about how well this format predicts real job performance. What you do on a whiteboard for 45 minutes is quite different from design work in production. But that debate aside, someone who has to pass one next week needs to know the rules of the format. This piece is about those rules.

What the Interviewer Is Actually Grading

Alex Xu's System Design Interview (2020) breaks this interview into four steps: understand the problem and set the scope, propose a high-level design and get agreement, dig deep, and wrap up. The reason that structure spread so widely is that real scoring rubrics tend to run on the same axes.

At most companies, the feedback form an interviewer fills in has four or five items. Did the candidate narrow the requirements on their own, does the high-level structure connect back to those requirements, can they go deep on one point, did they name a cost for every choice, did they make their thinking easy to follow. There is usually no line that reads "proposed the optimal architecture."

What the interviewer is looking for is not a correct answer but proof that the candidate knows what to give up once constraints appear. With an unlimited budget and unlimited time, no design is needed. Design is the act of deciding what you will not do, and explaining why you can afford not to do it is the real body of this interview.

The weighting shifts as seniority rises. In junior hiring, "what do you know" carries the larger share; in senior hiring, "do you know what you do not know" takes over. A candidate who talks about an area they have never operated as though they had operated it will struggle to land a senior verdict, however much they know.

How to Spend 45 Minutes — Say the Time Budget Out Loud First

If you do not fix the split in advance, 45 minutes will always leak out of the front end. Here is a solid default.

• Requirements, 5 minutes. Cut the scope to two or three functional requirements and pin the non-functional ones to numbers.
• High-level design, 10 minutes. Boxes and arrows make their first appearance here. One or two APIs and the skeleton of a data model.
• Deep dive, 15 minutes. Go into the one point the interviewer showed interest in. This stretch is effectively half the score.
• Bottlenecks and scaling, 10 minutes. What breaks first when traffic goes up tenfold, and what you change when it does.
• Wrap-up, 5 minutes. Remaining risks, what you would measure next, what you would look at with more time.

One practical tip here. Do not keep this budget to yourself, declare it out loud. "I will take about five minutes on requirements and about ten sketching the high-level structure, then go deep on whichever part interests you. Does that work?" That single sentence does two things at once. It takes control of the pacing, and it signals that you are someone who calibrates with the person across the table.

Then watch the clock. One self-check is enough to remember. If 15 minutes have passed and the first box is still not drawn, you stayed in requirements too long; if the whole picture was finished in five, you decided nothing.

Numbers Worth Memorizing

Most of the judgment calls in a design rest on a sense of orders of magnitude. Why you add a cache, why you split regions, why you cut synchronous calls — all of it comes out of the gaps in the table below.

The source for this table is "Latency Numbers Every Programmer Should Know," compiled by Jeff Dean and spread widely by Peter Norvig. It is usually cited in its 2012 form, and some of the absolute values are already dated. Storage in particular has gotten more than an order of magnitude faster since. Even so, the gaps between the tiers are as valid as ever, and what the interview needs is the gaps, not the exact values.

Only the last row refuses to shrink no matter what the hardware does. Light travels through fiber at roughly 200,000 kilometers per second. Seoul to the US West Coast is about 9,000 kilometers one way, so physics alone puts the round trip at 90 milliseconds. Add the detours of a real route and measurements usually land near 130 milliseconds. Once you know that number, "I would put a CDN and edge caches in front" stops being a list of buzzwords and becomes the conclusion of a calculation.

It is worth memorizing one availability number too. 99.9 percent is about 8.8 hours of downtime a year; 99.99 percent is about 53 minutes. If you can run that conversion on the spot when the interviewer asks about the availability target, the conversation moves naturally to multiple availability zones and the cost of failover.

Estimation Practice — From One DAU Figure to QPS and Storage

Back-of-the-envelope estimation is repetition, not talent. It starts with two roundings. A day is 86,400 seconds, but round it to 100,000 seconds, and round a year to 30 million seconds. Now the arithmetic fits in your head. A million requests a day is roughly 10 QPS (11.6, to be precise); a hundred million a day is roughly 1,000 QPS.

Let us run one for real. Ten million daily active users, each making 20 requests a day, gives 200 million a day. Divide by 100,000 and the average is 2,000 QPS. Traffic does not arrive evenly, so put the peak at two to three times the average and take 5,000 to 6,000 QPS as the design target. The moment you say you are assuming a read-to-write ratio of 100 to 1, caching and read replicas follow without any strain.

Storage works the same way. If one text post is 1 kilobyte and there are a million a day, that is 1 gigabyte a day and 365 gigabytes a year. Five years of retention with triple replication comes to roughly 5.5 terabytes. Attach images and the order of magnitude changes. A million images a day averaging 200 kilobytes is 200 gigabytes a day, 73 terabytes a year. Only someone who has run that calculation can say "images go to object storage and only metadata lives in the database" with a reason attached.

What gets graded in estimation is not accuracy but whether you put your assumptions out in the open. It is fine if the ten million figure is wrong. But once you have said "ten million users, 20 requests each, peak at three times average," the interviewer can correct the number on the spot, and from there the two of you are solving the same problem.

Four Places Candidates Break

• Drawing before asking about requirements. The most common and the most fatal. A system handling ten thousand a day and one handling a billion a day are entirely different objects, and if you start without asking you end up drawing neither. Pin down at least these four in the first five minutes: scale, read-to-write ratio, latency target, and the level of consistency required.
• Listing fashionable technology. Kafka, Redis, Elasticsearch and Kubernetes all on one screen, ending with "this is how I would set it up." When the interviewer asks what happens without that queue and no answer comes, the box costs you points instead of earning them. Every time you draw a component, attach one sentence about the problem it removes.
• Asserting without naming a cost. Sentences like "I would use NoSQL" or "I would go with microservices" are never answers in themselves. Handling the CAP theorem precisely here changes the impression a great deal. Proposed as a conjecture by Eric Brewer in 2000 and proved by Gilbert and Lynch in 2002, it is commonly summarized as "two out of three," but Brewer himself corrected that summary as misleading in a 2012 article. The precise statement is that you have to choose between consistency and availability only when a network partition actually occurs, and in normal operation you can have both to a considerable degree.
• Staying shallow in the deep dive. The moment the interviewer says "shall we look at that part a little more" is the center of the scoring. Switching to another component right then reads as evasion. The regular deep-dive topics worth preparing are a known set: shard key choice and hotspots, cache invalidation and stampedes, idempotency and retries, collision-free ID generation, and tail latency.

How to Say "I Do Not Know" Well

Hitting something you do not know is not an accident, it is the design. If nothing in a 45-minute open problem stumps you, the problem was too easy. So what you prepare is not a way to avoid not knowing, but a sentence for handling it.

Saying it in three parts is almost always safe. Admit the boundary, reason from principles you do have, and offer a way to check.

"I have never run exactly-once delivery in Kafka myself. Reasoning from principles, it would need producer idempotency together with transactional commits, and once consumer-side processing is included I suspect you still end up needing idempotency at the application level. In practice I would read the documentation and the benchmarks before deciding."

The points that answer earns are not knowledge points but calibration points. Someone who can draw the line between what they know and what they do not makes fewer dangerous calls in production. That is what the interviewer is watching for. The two worst responses, conversely, are bluffing and then collapsing on the follow-up question, and cutting the conversation off with a flat "I do not know."

The heavier the pressure, the less this sentence comes out. What breaks people in an interview is not the fact of not knowing but the few minutes spent trying to hide it. During those minutes, thinking stops and speech speeds up. Training for that reaction works on the same principle as the stress inoculation covered in how not to fall apart under pressure. There is no shortcut other than shaking a little in advance, under conditions close to the real thing.

And half of this interview is, in the end, a conversation. Someone who reads the other person's reactions and adjusts pace scores better than someone who mutters to themselves until the drawing is done. The principles covered in what it means to be good at conversation work exactly the same way in front of a whiteboard.

Closing — What Is Graded Is Not the Conclusion but the Narrowing

Looking back at the days a system design interview went well, they are usually not the days a dazzling architecture appeared. They are the days you cut five requirements down to two, ran the numbers three times, and dug one point to the bottom. The drawing is, if anything, simple.

Preparation can point the same way. Working three problems out loud on a timer, 45 minutes each, beats skimming ten. And every time, spend the last five minutes putting this question to yourself. What did I give up today, and why did I judge that giving it up was acceptable. Your skill rises in proportion to how well that answer comes together.