Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Why bother estimating in a design interview?

They're testing: whether you see estimates as a design tool, not a ritual.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Because the numbers decide the architecture. A few writes a second fits one database; tens of thousands may need sharding. Whether hot data fits in memory decides the cache design. Whether egress is megabits or hundreds of gigabits decides whether you need a CDN. I estimate early so every later choice has a reason.
3
4**Counter-questions:**
5- *"What if your estimate is wrong?"* → It will be, a little. What matters is the order of magnitude. If I'm off by 20%, nothing changes. If I'm off by 10 times, the design changes, so I double-check the zeros.
6- *"Can you skip estimates if I tell you the scale?"* → I'd still turn your scale into per-second numbers and storage, because that's what the components actually see.
7
8**Trap:** doing estimates and then never using them in the design.

Q2. Estimate the requests per second for a feed app with 100 million daily users.

They're testing: the method, out loud.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** I'll assume each user opens the feed 10 times a day and each open loads one page of posts. That's 1 billion feed requests a day. A day is about 100,000 seconds, so roughly 10,000 a second on average (more precisely about 11,600). With a peak factor of 3, I'd design for around 35,000 a second.
3
4**Counter-questions:**
5- *"Why 10 opens a day?"* → It's an assumption. I'd ask you, or adjust it if the product data says otherwise. The method stays the same.
6- *"What about posting?"* → Say 1 post per 10 users a day: 10 million posts a day, about 115 a second. So this is very read-heavy, which points to caching feeds.
7
8**Trap:** jumping straight to a number without stating the assumptions.

Q3. How do you estimate peak traffic?

They're testing: whether you know averages hide the danger.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Average is the daily total divided by 86,400. Peak is the busiest moment, usually 2 to 3 times the average for normal daily patterns. For scheduled events (a sale, a ticket opening, a results announcement), the peak can be far higher, so I'd ask about known events and design for those.
3
4**Counter-questions:**
5- *"How would you get the real peak factor?"* → From metrics: compare the busiest minute or second with the daily average, over several weeks.
6- *"Would you buy servers for the peak all year?"* → Not necessarily. Autoscaling adds servers for predictable peaks. For sudden spikes, you keep some headroom and protect the system with queues or rate limits.
7
8**Trap:** designing for the average.

Q4. How much storage will this need in 5 years?

They're testing: a clean formula and the metadata vs media split.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Writes a day × size of each × 365 × 5 × number of copies. I'd split it: small metadata in a database, large media in object storage. For example, 2 million photos a day at 2 MB is 4 TB a day, about 7.3 PB over 5 years for one copy, around 22 PB with 3 copies. The metadata at 1 KB each is only about 3.65 TB over 5 years.
3
4**Counter-questions:**
5- *"Can we reduce that?"* → Compress, store fewer sizes, move old photos to cheaper storage classes, and delete what users delete (Chapter 11).
6- *"Why multiply by copies?"* → Because we keep several replicas so a disk or machine failure doesn't lose data.
7
8**Trap:** forgetting replicas, or lumping metadata and media together.

Q5. How many servers do you need?

They're testing: whether you include headroom and failure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Peak requests a second, divided by one server's capacity times a target utilisation, plus spares. If peak is 17,400 a second, one server handles an assumed 1,000, and I run at 60%, that's 29 servers plus 1 spare. I'd flag that per-server capacity must be measured by load testing.
3
4**Counter-questions:**
5- *"Why not run at 100%?"* → Latency climbs sharply as a server gets close to full, and there's no room for spikes or for traffic moved from a failed server.
6- *"Is server count the real bottleneck here?"* → Often not. App servers scale out easily. The database and network usually hit limits first.
7
8**Trap:** peak ÷ capacity with no headroom or spares.

Q6. How much memory do you need for the cache?

They're testing: the 80/20 idea and checking whether it fits.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Estimate a day's read data, then cache the hot share, often assumed to be 20%. For 500 million metadata reads a day at 1 KB, that's 500 GB a day, so about 100 GB of cache. That fits in one large cache server or a small cluster. For the images, the same maths gives 20 TB, which is a CDN's job, not an in-memory cache's.
3
4**Counter-questions:**
5- *"Why 20%?"* → It's a common rule of thumb for skewed traffic. If we have real access data, we'd size by the hit rate we want instead.
6- *"What if it doesn't fit in one machine?"* → Shard the cache across several nodes (Chapter 13).
7
8**Trap:** sizing a cache for all the data.

Q7. Why does memory vs disk vs network latency matter in design?

They're testing: whether you can reason with the latency ladder.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Memory reads take around 100 nanoseconds, a data-centre round trip around half a millisecond, a spinning disk seek around 10 milliseconds, and a cross-continent round trip around 150 milliseconds. Those gaps are huge. They explain why caches help, why chatty services that call each other in sequence get slow, and why we put content close to users with CDNs.
3
4**Counter-questions:**
5- *"An SSD is fast. Do we still need a cache?"* → An SSD random read is around 150 microseconds, still over a thousand times slower than memory. And the database does more work than one read: parsing, planning, maybe several reads.
6- *"How would you cut latency for users in another continent?"* → Serve from nearby: CDN for static content, regional replicas or deployments for dynamic data.
7
8**Trap:** quoting numbers without saying what they mean for the design.

Q8. How much bandwidth do we need?

They're testing: bits vs bytes, and ingress vs egress.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Egress = reads a day × size served ÷ 86,400, then × 8 to turn bytes into bits. For 500 million photo views at 200 KB, that's 100 TB a day, about 1.16 GB a second, about 9.3 Gbps on average, roughly 28 Gbps at a 3 times peak. Ingress from uploads is much smaller. That level of egress is why I'd serve media from a CDN.
3
4**Counter-questions:**
5- *"Why × 8?"* → Network speeds are quoted in bits per second, storage in bytes. A byte is 8 bits.
6- *"Who pays for egress?"* → Cloud providers usually charge for data going out, so egress is a cost question too. A CDN often lowers it.
7
8**Trap:** forgetting the × 8.

Q9. Your estimate is off by 2 times. Does it matter?

They're testing: judgement about precision.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Usually not. A 2 times error is absorbed by headroom, autoscaling and adding a few servers. A 10 times error changes the design: one database becomes a sharded cluster, one cache server becomes a cluster. So I round hard and double-check the zeros.
3
4**Counter-questions:**
5- *"When would 2 times matter?"* → When you're near a hard limit: a link that's already 60% full, a single-machine database close to its write ceiling, or a fixed budget.
6
7**Trap:** spending five minutes on decimal precision.

Q10. How does the read/write ratio change your design?

They're testing: linking a number to architecture.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Read-heavy systems benefit from copies: caches, read replicas and CDNs. Write-heavy systems need the writes spread out: sharding, queues to absorb bursts, and storage that handles appends well. I estimate both so I know which side to optimise.
3
4**Counter-questions:**
5- *"Give an example of each."* → A photo feed at 250 reads per write is read-heavy. A metrics pipeline where 1,000 servers send data every second, and dashboards read a little, is write-heavy.
6- *"Can one system be both?"* → Yes, per feature. A chat app writes every message, but reads recent history a lot. Design each path for its own ratio.
7
8**Trap:** computing the ratio but not saying what it means.
9
10---
11
12## Practice coverage
13
14Every section in this chapter is tested at least once.
15
16| Section | Tested by |
17|---|---|
18| 2.1 Why estimate | Level 1A, Level 5.6, Q1 |
19| 2.2 Units and sizes | Level 2, Level 3, Q4 |
20| 2.3 Time shortcuts | Level 1B.1, Level 4, Q2 |
21| 2.4 Latency numbers | Q7 |
22| 2.5 Users to requests per second | Level 3, Level 5.1, Q2 |
23| 2.6 Read/write ratio | Level 1A, Level 3, Q10 |
24| 2.7 Peak vs average | Level 1B.3, Level 2.2, Level 5.1, Q3 |
25| 2.8 Storage | Level 2.3, Level 5.2, Level 5.3, Q4 |
26| 2.9 Bandwidth | Level 1B.2, Level 2.2, Level 4, Level 5.4, Q8 |
27| 2.10 Cache memory | Level 3, Q6 |
28| 2.11 Servers | Level 1B.3, Level 3, Level 5.5, Q5 |
29| 2.12 Rounding and checks | Level 1B, Level 4.3, Q9 |
30
31---

2. Back-of-Envelope Estimation