Estimation

What this round is

Estimation - also called guesstimates, market sizing, or Fermi questions - is the round where the interviewer asks for a number you can't possibly know and watches how you get there. "How many gas stations are in the US?" "How many rides does Uber do in this city per day?" "What's the annual revenue of the App Store?"

There is no right answer - there's a right method. The interviewer wants to see you turn an unanswerable question into a clean equation, break it into pieces you can estimate, state every assumption out loud, do the arithmetic without fumbling, and sanity-check the result against something you know. A candidate who blurts "about 50 million" loses instantly. A candidate who builds a transparent tree and lands within an order of magnitude wins even if the final number is off.

The defining feature versus the other rounds: this one is procedural and time-boxed. It's often a 10–15 minute sub-question rather than a full 45-minute case. There's less room for nuance and more room for clean execution. The bar isn't insight - it's legible logic plus arithmetic you don't drop.

The thing interviewers actually score first isn't your number - it's whether you announced your approach and why before touching a calculation. Saying the wrong number is rarely fatal. Saying nothing about how you chose to attack it is.

What they're testing

Not your memory of statistics. Your ability to decompose, assume, compute, and check - calmly, out loud, under time pressure.

The five dimensions being scored:

1. Structure - Can you turn "how many X?" into a written equation of 3-5 estimable pieces?
2. Approach choice - Do you announce top-down vs. bottom-up and why before computing? This is scored before any arithmetic.
3. Assumption quality - Are your numbers anchored to real reference points (populations, penetration rates, frequencies) rather than pulled from air?
4. Mental math - Can you compute cleanly with rounded numbers and powers of ten without losing the thread or making careless errors?
5. Sanity & communication - Do you check the result against a known benchmark, give a range, and name the assumption it hinges on?

The four things that win the round

1. Announce the approach first. "I'll go bottom-up, building from one store and scaling, because this is supply-constrained." One sentence of reasoning before the first number - that alone beats most candidates.
2. Round aggressively. 8 billion, not 8.1 billion. 300 million for the US. Powers of ten everywhere. Clean numbers prevent the careless arithmetic that sinks people.
3. Anchor every assumption. Tie each number to something the interviewer can nod at - "US population ~330M, ~40% are drivers, each fills up ~once a week." Anchored assumptions are defensible; invented ones aren't.
4. Sanity-check out loud. End by comparing your number to a reference point and giving a range. "That's ~X billion - in the same ballpark as the known figure, so I'm comfortable in the range A-B."

The mental model - 6 questions

Estimation is the one round where the mental model and the framework nearly coincide - it's a procedure, and the procedure is the thinking. Unlike the other rounds, the order here is mostly fixed. But the rigour at each step is what's scored - not the recitation of the sequence.

1. What exactly am I estimating - in what unit, scope, and timeframe? "How many photos per day, globally, uploaded (not viewed)?" Pin the unit and the boundaries before anything else. Most wrong answers start with a fuzzy unit.
2. Top-down or bottom-up - and what's my equation? Top-down starts from a big known anchor (population, GDP) and filters down - best for consumer/national questions (~80% of them). Bottom-up builds from one unit (one store, one driver, one server) and scales up - best for B2B, infrastructure, and capacity-constrained questions. Pick one, say why, then write the formula.
3. What's my base, and how do I segment it MECE? Break the population or unit into clean, non-overlapping groups (by geography, age, user type, urban/rural). Estimate each group separately when behaviour differs across them.
4. What number goes in each slot - and is each one anchored? Assign a value to every term, stating the assumption and the reference point behind it. Round hard. Flag which assumptions are shaky.
5. What does the arithmetic give - computed cleanly, out loud? Multiply through step by step, tracking units, keeping the running total visible. Powers of ten are your friend.
6. Does it survive a sanity check - and what's the range plus the key driver? Compare to a known benchmark. Give a range, not false precision. Name the one assumption the answer is most sensitive to.

The question shapes

Consumer / national → top-down; B2B / infra / capacity / physical → bottom-up.

Sample questions

Market sizing (TAM/SAM/SOM). Usually top-down; finish with "this is the ceiling if you captured 100% share."

• Size the market for electric scooters in India.
• Estimate the market for online food delivery in a tier-2 city.
• What's the TAM for pet insurance in the US?
• Size the market for paid music streaming globally.

Volume / throughput. Watch the unit and timeframe carefully (per day vs. per year, uploads vs. views).

• How many photos are uploaded to Instagram per day?
• How many searches does Google handle per day?
• How many Uber rides happen in [city] on a typical day?
• How many packages does Amazon deliver in the US per day?

Revenue. Volume × price or × monetisation rate. Often follows a volume estimate.

• Estimate Google's daily search-ad revenue.
• Estimate the annual revenue of the Apple App Store.
• Estimate the daily revenue of a single McDonald's outlet.

Infrastructure / resource. Bottom-up from a per-unit figure; great for showing technical fluency.

• How much storage does YouTube need for one day of uploads?
• How much bandwidth does Netflix consume at peak?
• How many delivery drivers does a grocery-delivery service need in one city?

Physical / spatial (Fermi). Pure decomposition + geometry; tests calm structured thinking with zero domain knowledge.

• How many gas stations are in the US?
• How many windows are in New York City?
• How many tennis balls fit in a school bus?

How to structure your answer

The structure of your answer is nearly all of the signal in this round - more than in any other.

• Talk through every step. Silent math is invisible math. The interviewer scores the reasoning, not the final digit.
• Use the whiteboard. Write the equation, the segments, the running total. A visible tree is the single biggest credibility boost.
• Announce the approach before computing. "Bottom-up, because this is capacity-constrained." One sentence. Do this first, always.
• Round to powers of ten. Clean numbers prevent the careless errors that fail otherwise-good candidates.
• State every assumption with an anchor. Never insert a number silently.
• Track units. Catch errors by checking that units cancel to the answer you want.
• Sanity-check before you commit. Compare the magnitude to something known, then give a range.
• Time it tight (~10-15 min total): ~2 min clarify + approach, ~3 min structure + segment, ~4 min assumptions + math, ~2 min sanity-check + range, ~1 min "so what."
• End with the "so what." Tie the number to the decision it would inform - that's the senior move that distinguishes you from someone who just did arithmetic.

Common traps

• Diving into numbers before defining the unit. "Per day or per year? Uploads or views?" Fuzzy units guarantee a wrong answer.
• Not announcing the approach. Computing without saying "top-down because…" is the most-penalised omission in this round.
• Un-rounded numbers. 312,476,901 instead of 300M turns the question into an arithmetic minefield.
• Silent assumptions. Inserting a number with no stated reasoning reads as guessing.
• Dropping a zero. Careless math with messy numbers is the classic fail. Powers of ten and unit-tracking prevent it.
• Skipping the sanity check. Handing over a number you never tested against reality signals you can't tell a plausible answer from an absurd one.
• False precision. "47,293,118" is worse than "~50 million." Give a range.
• Over-segmentation. Splitting the base into ten groups you then can't fill burns your clock.
• Forgetting the timeframe conversion. Estimating a per-day figure when asked for annual (or vice versa).
• No "so what." Ending on a bare number. Tie it to the decision it informs.
• Panicking at a quirky prompt. "Windows in NYC" feels alien but yields to the same decomposition. Stay calm and structure it.

Strong vs weak answers

Prompt: "How many photos are uploaded to Instagram per day?"

A weak answer sounds like:

"Instagram is huge - billions of users. So probably… a few hundred million photos a day? Maybe 500 million? Actually it could be a billion. Let's say somewhere around there."

What's wrong: no unit definition, no approach, no equation, no anchored assumptions, no segmentation, no math anyone can follow, no sanity check, no range - just a vibe.

A strong answer sounds like:

"First, the unit: photos uploaded per day, globally, counting both feed posts and Stories. I'll go top-down, because this is a consumer question with a clean population anchor.

My equation: daily uploads = monthly active users × share active daily × share who post on a given day × average posts per posting-user.

Anchoring the inputs: Instagram has roughly 2 billion monthly active users. Say about half are daily active - that's ~1 billion DAU. Of those, not everyone posts daily; I'd estimate ~20% post something (feed or Story) on a given day, so ~200 million posting-users. And a posting-user averages maybe 2 photos that day across feed and Stories.

Math: 200 million × 2 = ~400 million photos per day. Let me keep it in powers of ten - 2 × 10⁸ × 2 = 4 × 10⁸.

Sanity check: 400M photos across ~1B DAU is roughly one photo per 2.5 daily users - that feels plausible for a photo-first network, maybe even slightly low given Stories volume. So I'd give a range of 300-600 million per day. The assumption I'm least sure of is the 20% daily-poster rate; if it's closer to 30%, the answer pushes toward 600M.

If I were sizing storage or ranking infrastructure off this, the daily-poster rate is the first number I'd pull real data on - that's where my estimate is softest."

What's right: defined unit, announced approach with reasoning, written equation, anchored MECE assumptions, clean powers-of-ten math, a sanity check against known scale, a stated range, the key sensitivity, and a "so what" tied to a real decision.

How to prepare

Estimation is the most trainable round in the loop - it's a procedure plus a small fact base. Reps and anchors do almost all the work.

• Memorise an anchor sheet. World population 8B; US ~330M; India ~1.4B; your home country; life expectancy ~75-80 yrs; smartphone/internet penetration by region; typical ad CPM ($10-15); rough revenue of a few big companies. Having these cold removes 80% of the hesitation.
• Drill 20-30 questions across all five types. Volume, revenue, market size, infrastructure, physical. Patterns repeat fast.
• Practise both approaches on the same prompt. Solve a question top-down, then bottom-up, and watch them converge (or diagnose why they don't). Cross-checking is a strong-candidate habit.
• Train mental math with powers of ten. Practise multiplying and dividing rounded numbers fast and out loud.
• Always say the approach first. Build the reflex: "top-down/bottom-up, because…" before any number, every single time.
• Always end with a sanity check and a range. Make both non-negotiable parts of your routine.
• Practise the "so what." For each answer, name the decision it would inform.
• Time-box hard. Most estimation prompts are 10-15 minutes. Practise landing a clean tree, math, check, and range inside that window.
• Record yourself or use a partner. The failure mode is rarely the number - it's mumbled structure or a dropped zero. Hearing yourself surfaces both.

Define the unit, announce the approach, build an anchored MECE tree, compute cleanly in powers of ten, sanity-check, and land a range with a "so what" - and the round is yours.