Four minutes in, the candidate had drawn the most beautiful whiteboard I'd seen that year. Load balancer. API gateway. Kafka. Redis cluster. Cassandra ring. A little CDN cloud in the corner. Arrows everywhere, all of them straight.
I asked one question: "How many tweets per second are we writing?"
They said, "It should scale horizontally."
I asked again, differently: "Roughly. Order of magnitude." They shrugged and pointed at Kafka.
No hire. Meanwhile the person who drew three boxes, wrote ~4k writes/sec in the corner, and spent twenty minutes on one problem got a strong hire from the same panel. That gap is the whole thing. A system design interview does not score your diagram. It scores whether you can make decisions under uncertainty and explain what they cost.
TL;DR
- A system design interview scores five things: requirement scoping, back-of-envelope estimation, one deep dive, explicit tradeoffs, and communication. The diagram is just the artifact those leave behind.
- Naming Kafka, Cassandra, and Redis earns zero points by itself. Saying why not Postgres earns all of them.
- The most common senior failure is starting to draw in minute one. Spend the first 8 minutes asking questions and doing arithmetic instead.
- Budget the 45 minutes: 8 scope, 5 estimate, 7 high-level, 20 deep dive, 5 failure modes. Interviewers who ran out of time write "shallow" on the scorecard.
- You are allowed to not know. "I haven't run this at that scale, here's how I'd find out" reads as senior. Confident guessing reads as risky.
What does a system design interview actually score?
It scores judgment, not vocabulary. Every rubric I've worked from splits into roughly the same five buckets, and they're weighted more evenly than candidates expect.
1. Scoping. Did you turn a four-word prompt into a bounded problem? "Design Twitter" is not a spec. Do we need DMs? Search? Trending? A candidate who says "I'll cover posting, the home timeline, and follows, and skip search unless you want it" has already outscored half the loop.
2. Estimation. Can you get within an order of magnitude of the load? This is the single most predictive signal I've seen, and the one people skip.
3. Depth. Can you go three layers down on at least one component? Breadth is cheap. Anyone can list nine boxes. Very few can explain what actually happens inside one of them at 3am.
4. Tradeoffs. Do you say "X, because Y, at the cost of Z"? Missing the third clause is what separates a mid-level answer from a senior one.
5. Communication. Did I have to drag it out of you? Interviewers write the scorecard from memory an hour later. If your reasoning wasn't audible, it didn't happen.
Why do senior engineers fail the system design interview?
Because experience makes you skip steps that the interview specifically exists to observe. At work, you already know the traffic, the team, and the existing stack, so scoping and estimation happen in your head. In the room, silent competence looks identical to no competence.
The failure modes I see most, roughly in order:
- Drawing before asking. You committed to an architecture before you knew the requirements. Every later answer is now anchored to a guess.
- Design by resume. Reaching for the exact stack from your last job, including the parts that solved a problem this system doesn't have.
- Breadth panic. Sensing time slipping and touching every box for 90 seconds each. This produces a scorecard that says "no depth demonstrated," which is a no-hire even when everything you said was correct.
- Refusing to pick. "We could use SQL or NoSQL here, both have merits." That's not neutrality, that's a missing decision. Pick one, name the cost, move on.
- Ignoring the hint. When the interviewer says "interesting, what happens when that queue backs up?", that is not curiosity. That's the rubric talking. Follow it.
How do you do back-of-envelope math without panicking?
Pick round numbers, state them out loud as assumptions, and never apologize for them. Nobody is checking your arithmetic against a real dashboard. They're checking whether numbers change your design.
Here's the whole "Design Twitter" estimate in about 90 seconds:
- 300M monthly users, say 150M daily.
- Each posts ~0.5 tweets/day, so 75M tweets/day, which is ~900 writes/sec. Peak at 3x, call it ~3k/sec.
- Each user loads a timeline ~10x/day. That's 1.5B reads/day, ~17k reads/sec. Read:write is roughly 20:1.
- A tweet is ~300 bytes of text and metadata. 75M x 300B is ~22GB/day, about 8TB/year before media.
Now say the sentence that earns the points: "So this is read-heavy by twenty to one, and a year of text fits on one beefy machine. The hard part isn't storage, it's fanout."
That last line is the pivot the interviewer is waiting for. With an average of 200 followers, naive write-fanout means 900 x 200 = ~180k timeline writes/sec, and a celebrity with 100M followers turns one tweet into 100M writes. Now you have a real problem to design against: precompute timelines for normal users, pull-on-read for the handful of huge accounts, merge at read time. That hybrid answer only exists because you did arithmetic first.
Do you need to name-drop Kafka, Cassandra, and Redis?
No. Naming technologies is free, and interviewers discount free things. What scores is the comparison you attach to the name.
Weak: "I'd use Cassandra for tweets."
Strong: "I'd use a wide-column store keyed by user ID with the tweet ID as the clustering key, because timeline reads are range scans on a single partition. I lose ad-hoc queries and joins, which is fine here since every access path is known upfront. If the product later wants arbitrary analytics, that goes to a separate columnar warehouse rather than bending this store."
Same technology. Completely different score. The second answer proves you'd make the call again on a system I haven't described yet.
The other cheap upgrade: mention what breaks. "Redis in front of the timeline gets me sub-10ms reads, but a cold cache after a deploy means a thundering herd against the DB, so I'd stagger TTLs and keep a request coalescer." One sentence about a 3am failure signals more operational experience than a whole page of boxes.
How should you spend the 45 minutes?
Say the plan out loud in minute one. It costs fifteen seconds and instantly reads as senior, because it's exactly what a tech lead does when handed an ambiguous project.
| Minutes | What you do |
|---|---|
| 0-8 | Clarify scope, list functional and non-functional requirements, confirm what's out of scope |
| 8-13 | Estimation out loud, land on the dominant constraint |
| 13-20 | High-level boxes, kept boring on purpose |
| 20-40 | One deep dive: data model, fanout, consistency, hot partitions |
| 40-45 | Failure modes, monitoring, what you'd build first |
If the interviewer steers you off the plan, follow them. They're steering toward the part they're scored on. But announcing the plan means when you're at minute 30 in a deep dive, nobody is quietly writing "never discussed failure handling."
What if you've never built anything at that scale?
Say so, then keep designing. "I've run this at a few hundred requests per second, not a hundred thousand, so I'll reason from the constraints and tell you where I'd want a load test" is a completely acceptable senior answer. It's calibration, and calibration is a hiring signal.
What gets punished is fake certainty. If you assert a number you didn't derive and I probe once, the whole interview turns into an audit. Every unearned claim after that costs you double.
The related move: when you're stuck, narrate the stuck. "I'm weighing whether to denormalize the follower graph. Let me think about read patterns for ten seconds." Interviewers can't score silence, but they can absolutely score a person thinking.
So what is a system design interview really scoring?
A system design interview scores how you make and defend engineering decisions when the requirements are vague, not whether you can reproduce a reference architecture. The rubric rewards scoping the problem before drawing, doing rough arithmetic that visibly changes your design, going deep on one component rather than shallow on nine, stating every choice as "X, because Y, at the cost of Z," and being honest about what you haven't built. The candidate with three boxes and a number in the corner beats the candidate with a perfect diagram and no reasoning, every single time, because the panel is trying to answer one question: would I trust this person to make this call on a Tuesday when nobody is watching?
What's the strangest system design prompt you've been given? I'll take "design a vending machine" over "design Twitter" any day.
Top comments (0)