system-design

Estimation in the Interview

How to do back-of-the-envelope math under pressure, out loud, without a calculator — and how to use the numbers to drive the design rather than just producing them.

Prerequisites: Back-of-the-Envelope Estimation, The Framework Time to read: ~14 minutes

Why estimation scores so well

🚨 Doing quick, sound estimation is one of the clearest signals of an experienced engineer, because it separates people who reason about scale from those who guess. And it’s the phase where your answer becomes justified: “we need a cache” is an opinion; “450,000 reads/second, so no single database serves that — we need a cache” is a derived conclusion.

The full technique is in Back-of-the-Envelope Estimation; this chapter is about doing it in the interview — fast, out loud, and connected to the design.

The rules for doing it under pressure

🚨 Five rules that make estimation work in a high-pressure setting:

1. Round aggressively. You want the order of magnitude, not precision. 86,400 → 100,000. Nobody challenges rounding; everyone appreciates speed. 🚨 Anyone doing long division on a whiteboard has misunderstood the exercise.

2. State every assumption out loud. “I’ll assume 100M daily active users, each posting twice a day.” This lets the interviewer correct you (making the rest valid) and shows your reasoning.

3. Narrate the arithmetic. Estimation is graded on the reasoning, which the interviewer can only see if you say it. A silent calculation, even if correct, scores nothing.

4. Use powers of ten. Convert to scientific notation; arithmetic becomes adding exponents.

5. Carry units. requests/second, bytes/day, GB. Unit errors are the only errors that matter, and units catch them.

The numbers to have memorized

🚨 You must know these cold — you can’t derive them mid-interview:

Seconds/day        ≈ 100,000 (86,400)     ← THE most important approximation
1 million/day      ≈ 12 QPS
1 billion/day      ≈ 12,000 QPS
Peak = 2-3× average (consumer), up to 100× (event-driven)

Sizes:  tweet ~300B, photo ~2MB, 1min 1080p ~50MB
Latency: RAM 100ns, SSD 100µs, datacenter RTT 0.5ms, cross-continent 150ms
Throughput: 1 Gbps ≈ 125 MB/s
Replication: raw × 3 × ~1.2 index overhead ≈ 3.6×

→ Latency Numbers. The 86,400 ≈ 10⁵ approximation is the single most useful one — it turns any daily figure into QPS in your head.

The recipe (in the interview)

1. USERS      → DAU, actions per user per day
2. QPS        → average (÷ 100,000), then peak (× 2-3)
3. STORAGE    → bytes/item × items/day × retention × 3.6 (replication+index)
4. BANDWIDTH  → QPS × payload size
5. MEMORY     → hot fraction (80/20) for cache sizing

Do the ones that matter for the problem — usually QPS and storage — and skip the rest unless relevant.

🚨 The crucial part: USE the numbers

🚨 The point of estimation is not the arithmetic — it’s the architectural conclusion. Every estimate should end with “…which means…”:

🎙️ The strong pattern: “[number] [operation]/second, which means [design implication].” This is what makes estimation valuable — it derives the architecture from the numbers, which is exactly the reasoning-not-reciting behaviour that scores.

A candidate who computes 450,000 QPS and moves on has wasted the estimate. One who says “so caching is structural here” has used it.

Worked example (compressed)

“Let me size Twitter. I’ll assume 300M monthly users, half daily active — 150M DAU. Each posts twice a day, so 300M tweets/day, which is 300M over 100,000 seconds ≈ 3,000 writes/second, peak maybe 9,000. Each reads 100 tweets a day, so 15 billion reads/day ≈ 150,000 reads/second, peak ~450,000.

So the read/write ratio is 50:1 — this is read-heavy, and 450,000 reads/second means the database can’t serve reads directly, so I’ll cache and precompute feeds.

Storage: 300M tweets/day at ~1KB is 300 GB/day, ~110 TB/year, so ~550 TB over 5 years with retention — that needs sharding. Media, if 10% have a 2MB photo, is 60 TB/day — 200× the text, so that goes to object storage behind a CDN, uploaded directly, not through our servers.

So the design is: read-optimized with heavy caching and precomputed feeds, sharded metadata, media in object storage and CDN.”

🚨 Notice how each number produces a design decision. That’s the whole skill.

Time management

🚨 Budget 3-5 minutes. Don’t over-estimate. Estimation is a tool, not the deliverable — a common mistake is spending 15 minutes on elaborate arithmetic and running out of time for the design. Do the 1-2 estimates that drive the key decisions (usually QPS and storage), state the implications, and move on.

🚨 Interview traps

🎙️ Soundbites

🛠️ Try it

1. Estimate ten systems out loud, timed. For ten prompts (WhatsApp, Uber, YouTube), do the QPS and storage estimate out loud in under 5 minutes each, ending each with the design implication. Check against Estimation Drills. The out-loud, timed practice is what builds the under-pressure skill.

2. Drill the memorized numbers. Flashcards for 86,400 ≈ 10⁵, 1M/day ≈ 12 QPS, the latency table, object sizes. Five minutes a day for a week — you must know these without thinking.

3. Force the “which means” every time. For every number you compute, immediately state the architectural implication. Until this is automatic, you’ll produce numbers without using them — the biggest estimation mistake.

4. Practice rounding. Take real figures (347.2, 86,400, 8.3M) and round them to powers of ten instantly. Speed at rounding is what lets you estimate in your head under pressure.

Check yourself

1. Why is the estimate's *conclusion* more important than the arithmetic? Because the purpose of estimation in a design interview isn't to demonstrate arithmetic — it's to *derive the architecture from the scale*, turning design decisions from opinions into justified conclusions. Computing "450,000 reads per second" and moving on wastes the estimate; the value is in the next sentence: "which means no single database can serve that, so caching and precomputation are structural, not optional." That conclusion is what the estimate is *for* — it establishes *why* the design needs a cache, why it needs sharding, why media goes to object storage. Each number should produce a design implication ("3,000 writes/second → a sharded database handles it," "550 TB → sharding required," "media is 200× the text → object storage and CDN"). This is the reasoning-not-reciting behaviour that scores highest: a candidate who says "we'll use a cache" states an opinion, while one who says "at 450,000 reads/second the database can't serve reads directly, so caching is structural" has *reasoned* to the cache from the scale. The arithmetic is just the means; the architectural conclusion is the end, and skipping straight to it (or producing the number and forgetting to draw the conclusion) is the most common way candidates waste an otherwise-correct estimate.
2. Why must you narrate the arithmetic and state assumptions out loud? Because estimation is graded on the *reasoning process*, and the interviewer can only evaluate what they can hear. A silent calculation — even one that arrives at the exactly correct number — demonstrates nothing about how you got there, whether you understand what the number means, or whether your assumptions were sound; it just produces a figure that could have been guessed or memorized. Narrating ("300M tweets a day, over 100,000 seconds, is about 3,000 writes per second") shows the interviewer your method, your fluency with the approximations, and your ability to reason about scale — which is the skill being tested. Stating assumptions out loud ("I'll assume 150M daily actives, each posting twice a day") serves a second critical function: it lets the interviewer *correct* you if an assumption is wrong, which makes everything downstream valid rather than building an elaborate estimate on a bad premise — and a stated, correctable assumption is far better than a silent, unverifiable one. It also signals that you know estimation is about *reasonable assumptions plus sound arithmetic*, not about knowing the "real" numbers, which you couldn't anyway. The combination — narrated arithmetic plus explicit assumptions — turns estimation from an opaque calculation into a visible demonstration of the exact judgment the interview is probing.
3. What are the most important numbers to have memorized, and why? The single most important is **86,400 seconds per day ≈ 100,000 (10⁵)**, because it lets you convert any daily figure into QPS instantly in your head: a million requests per day is 10⁶/10⁵ = ~12 QPS, a billion per day is ~12,000 QPS — arithmetic you can do while talking, without a calculator. Beyond that: the **peak multiplier** (2-3× average for consumer apps, up to 100× for event-driven spikes), because designing for average means being overloaded every peak; **object sizes** (a tweet ~300 bytes, a photo ~2MB, a minute of 1080p video ~50MB), for storage and bandwidth estimates; the **latency numbers** (RAM ~100ns, SSD ~100µs, datacenter round trip ~0.5ms, cross-continent ~150ms) and **throughput** (1 Gbps ≈ 125 MB/s), for reasoning about performance and capacity; and the **replication multiplier** (~3.6× raw, combining 3× replication and ~1.2× index overhead) for realistic storage sizing. You must have these *memorized* because you can't derive them mid-interview — you can't work out that a day has 86,400 seconds and round it while also reasoning about the design; the memorized approximations are the building blocks that let the estimation happen fluently at conversational speed. Drilling them with flashcards until they're automatic is a high-return, low-effort preparation, because every estimation question depends on them.
4. Why is aggressive rounding correct rather than sloppy? Because back-of-the-envelope estimation seeks the *order of magnitude* — is this 10 servers or 1,000? 100 GB or 100 TB? — not a precise figure, and the design decisions it drives depend only on the order of magnitude, not the exact number. Whether the answer is 3,000 or 3,200 writes per second doesn't change the conclusion ("a sharded database handles it"); whether it's 3,000 or 300,000 does. So rounding 86,400 to 100,000, 365 to 400, and 8 bytes to 10 sacrifices nothing that matters while making the arithmetic doable in your head at speed — which is the whole point, since you're estimating out loud under time pressure without a calculator. Aggressive rounding is *correct technique*, not corner-cutting: it reflects understanding that precision is irrelevant to the exercise and that speed and clear reasoning are what count. The opposite — doing long division on a whiteboard to get 3,187.4 writes per second — signals that you've misunderstood the exercise, wasting time on precision that doesn't affect any decision and that nobody expects or wants. Interviewers appreciate a candidate who rounds fluently and reaches the architectural conclusion quickly far more than one who grinds through exact arithmetic. The skill being demonstrated is *sizing*, and sizing is an order-of-magnitude activity.
5. How long should estimation take, and why not longer? About 3-5 minutes of the 45-minute round — enough to do the one or two estimates that drive the key architectural decisions (usually peak QPS and storage volume) and state their implications, but not more. It shouldn't take longer because estimation is a *tool*, not the deliverable: its job is to establish the scale so the design is grounded, and once you've derived the decisions it points to ("read-heavy, so cache and precompute; 550 TB, so shard; media dominates, so object storage and CDN"), further estimation adds nothing and consumes time you need for the design and deep dives — where seniority is actually demonstrated. A common failure is treating estimation as an end in itself, producing elaborate multi-step calculations for every dimension (bandwidth, memory, CPU, connection counts) when only QPS and storage actually changed a decision, and then running short on time for the architecture. The discipline is to estimate *selectively* — do the calculations that matter for *this* problem, skip the ones that don't, round aggressively for speed, extract the design implications, and move on. Just as spending too long on requirements leaves no time to design, spending too long on estimation leaves no time to demonstrate the depth the interview is really evaluating. The estimate sets up the design; it isn't the performance.

Further reading

This site is open source. Improve this page.