Watch the 40-second version here
Your Interviewer Does Not Want the Right Number
Ask a senior dev how much bandwidth a feature will cost and watch what happens. The good ones start doing arithmetic on a napkin. The rest ask for a Jira ticket and a sprint.
Frontend system design interviews have a step everyone tries to skip: scale estimation. The interviewer says "a hundred thousand daily users," or worse, says nothing at all, and expects you to do something with it. Most candidates freeze. The freeze is the fail. The math is not the point.
Here is why it matters. Nobody on the hiring panel believes your estimate. Not because you are wrong, but because estimation is not about the answer. It is a proxy for how you think when the spec is incomplete, which is the actual job. A staff engineer who can Fermi-estimate a feature in ninety seconds is worth ten who need a "spike story" to tell you what a query costs.
And here is the non-obvious part. Your guesses are the product. Every number you state out loud is an invitation to be corrected, and corrections are free information. Say "assume 10 percent of MAU is concurrent at peak" and a good interviewer will say "closer to 30 percent in our case," and now you are having a conversation instead of doing arithmetic alone. The candidates who bomb are the ones who did the math silently and announced a number. Nobody can argue with a finished number. Everyone can sharpen a wrong guess.
The practical artifact: a 60-second scale card you can use in the interview and on the job.
1. USERS
DAU = ___ Peak concurrent = DAU × peak factor (0.1 to 0.3)
2. JOURNEYS
Actions per user per day = ___
(page loads, screen views, API calls)
3. DATA WEIGHT
KB per journey = ___
(payload + images + JS; weigh the median page, not the homepage)
SCALE = DAU × journeys × data weight
Worked example: 100k DAU × 20 actions/day × 300KB = 600GB of transfer per day. Now you can talk about CDN cache hit ratios instead of vibes. Notice nothing here requires a correct guess. The peak factor is a range, the data weight is measured from one representative page, and every line is stated out loud so the interviewer can correct it.
Nobody gets hired for dividing 600 by 0.7 correctly. They get hired because they broke an impossible question into three small ones and kept talking. Try it on your next project in thirty seconds. It feels theatrical the first time. By the third time it is just how you scope.
Question 7 of 60 from the Frontend System Design Interview Playbook.
Top comments (0)