Guesstimates: How To Solve Them

A guesstimate is a question like "How many food delivery orders are placed in Bengaluru on a typical day?" or "What is the monthly revenue of a coffee kiosk at a metro station?" Nobody expects you to know the answer. You are expected to build one, step by step, from things you can reasonably assume.

The word blends guess and estimate, but a good guesstimate is not a guess. A guess is a number pulled from the air. A guesstimate is a chain of small, defensible assumptions that multiply into an answer you can explain and adjust.

This guide focuses on how to solve a guesstimate: the method, two fully worked examples, the mistakes that cost marks and how to practise until the method is automatic.

Guesstimate interview questions are common in interviews for founder's office, chief of staff, strategy and operations, product, growth, consulting and analytics roles. They are asked of freshers and experienced candidates.

The reason is simple. These jobs give you missing details and still ask for a choice. How big is this market? How many riders do we need next month? Is this feature worth building for the users who would touch it? A guesstimate is that kind of thinking compressed into ten minutes, with an interviewer watching.

That is why, when you solve a guesstimate, the exact number matters far less than the route you take to it. Interviewers are usually scoring five things:

Spot the type early. It tells you which structure to reach for.

Most guesstimates fall into one of four types. Recognising the type early tells you which structure to reach for when you start solving.

• Market sizing. How big is the market for something? For example, the number of two-wheelers sold in India each year, or the annual spend on coaching for competitive exams.
• Business or revenue estimates. How much does a specific business earn or sell? For example, the daily revenue of a petrol pump, or the monthly orders of a single quick-commerce dark store.
• Operational counts. How many of something exist or happen? For example, the number of flights leaving Delhi airport in a day, or the number of ATMs in Mumbai.
• Abstract or physical estimates. How many of something fit somewhere? For example, how many tennis balls fit in a bus. These are less common in startup interviews but test the same skills.

Top-down or bottom-up?

There are two broad ways to solve any guesstimate.

Top-down starts from a large known number, usually population, and narrows it with percentages. Population, then takes the portion that falls into the right age group. Next Top-down selects the portion that uses the product. Finally, top-down considers how often users use the product. It is quick. Works well for consumer questions.

Bottom-up starts from a single unit and scales it. One store, one rider or one machine; it adds up how many such units exist. It works well when capacity or supply limits the answer.

A related split is demand side (who wants the thing and how much) versus supply side (who provides it and how much they can provide). The strongest answers often use the demand side to build the estimate and the supply side to check it.

Use the same seven steps for every guesstimate, whatever the topic. The steps matter more than speed, and with practice they become fast on their own. This is the core method for answering guesstimate interview questions.

The seven steps to solve any guesstimate, in order.

Here is the seven-step method applied in full, written the way you would say it in the room.

"I'll take Bengaluru to mean the metro area, count orders placed through delivery apps, and estimate an average day rather than a festival or a weekend peak. Does that work?"

"This is consumer behaviour, so I'll go top-down from the population and segment users by how often they order. Then I'll check the results from the supply side using delivery riders.

• People aged 18 to 60: 1.4 crore × 60% = about 84 lakh.
• People who order online: 84 lakh × 40% = about 34 lakh.
• Average orders per user per week: (20% × 3) + (40% × 1) + (40% × 0.5) = 0.6 + 0.4 + 0.2 = 1.2.
• Orders per week: 34 lakh × 1.2 = about 40 lakh.
• Orders per day: 40 lakh ÷ 7 = about 6 lakh.

Now, from the riders' side: Suppose about 40,000 delivery riders are active across apps on a typical day. A rider on a 10 to 12-hour shift might complete one to two orders an hour, so about 15 orders a day. 40,000 × 15 = 6 lakh. What you say: That matches my demand estimate closely, so I'm comfortable with the order of magnitude.

Notice that the rider count is also an assumption. The check works because it rests on a different set of assumptions. If both routes land in the same range, neither is likely to be badly wrong.

The estimate is about 6 lakh orders a day, likely between 4 and 8 lakh. The most sensitive assumption is how often regular users order, so that is what needs to be validated first. As a so what: a new cloud kitchen brand aiming for 1% of the city's orders would need around 6,000 orders a day, which tells you it would need many kitchens, not one.

This time, start from capacity rather than population, because a kiosk can only serve so many people.

• Opening hours: 7 am to 10 pm, so 15 hours.
• Peak hours: about 4 hours across the morning and evening rush. One counter can serve roughly one customer a minute at full pace, but queues are uneven, so assume 70% of capacity: about 40 cups an hour, or 160 cups.
• Off-peak hours: the remaining 11 hours at about 15 cups an hour: about 165 cups.
• Total: roughly 325 cups a day; call it 330.
• Average ticket: about ₹150, allowing for some customers adding a snack.
• Daily revenue: 330 × ₹150 = about ₹50,000, or roughly ₹15 lakh a month.

Sanity check: does a ₹15 lakh monthly revenue make sense against the rent and staffing costs of a prime station spot? It seems plausible, which suggests the estimate is in the right range. A good close would be: "The answer is most sensitive to peak throughput. If the kiosk added a second counter during rush hours, revenue could rise meaningfully."

You will reach for a few base numbers again and again. Round, recent figures save time and make your assumptions easier to defend. These are approximate and worth refreshing every year.

One caution: subscriptions are not people. Many people hold more than one SIM, so the number of unique internet users is lower than the subscription count. Pointing this out in an interview is exactly the kind of judgment guesstimates are meant to surface.

Eight common guesstimate mistakes. Most cost marks for reasoning, not maths.

Guesstimates reward repetition more than reading. Knowing the method takes an afternoon. Using it calmly under pressure takes practice.

• Do one a day. Pick a question from Guesstimate questions (with answers) or from everyday life: the cars in your apartment complex, the orders your local bakery takes. Give yourself ten minutes.
• Say it out loud. Practise talking through every step, ideally recording yourself. Most people discover they go quiet exactly where the interviewer needs to hear them.
• Time yourself. Aim to state your structure within two minutes and finish within ten.
• Always do the second angle. Make the sanity check a habit, not something you remember when you have time.
• Practise with someone who pushes back. A friend who challenges your assumptions is more useful than a model answer, because interviews are conversations.
• Keep an anchor sheet. Note the base numbers you use often and refresh them every few months.
• Review, then redo. After each attempt, find the single assumption that moved the answer most. Redo the question with a better one. This builds judgement faster than starting a new question every time.

After reading enough discussions from candidates and former interviewers and consulting interview forums, the same lessons come up again and again. Most are less about maths and more about how you behave while solving.

• The interviewer usually does not know the answer either. A recurring point is that guesstimate interview questions exist to test your approach, so rounding freely is fine and exact figures are not the goal. Treat the number as a by-product of the method.
• Memorised answers are easy to spot. A former consulting interviewer describing how they ran interviews says they never checked whether a candidate's final number was right, and could tell early whether a number was being built or recalled. Learning the method beats learning answers.
• Check an assumption, do not ask for the answer. Forum advice draws a clear line here. If you are unsure of a number, give a range and ask whether a point inside it is reasonable, such as "somewhere between 50 and 80 metres, I'll use 70". Asking the interviewer to supply the figure itself reads as avoiding the work.
• Strong candidates catch their own mistakes. A common observation is that weaker candidates finish and look to the interviewer to say whether they got it right. Stronger ones run their own sanity check and fix errors before declaring they are done.
• If you cannot defend an assumption, break it down further. Experienced candidates suggest a simple test for every number: would you be able to defend it if challenged? If not, split it into smaller parts you can defend. The approach that needs the fewest shaky assumptions is usually the right one.
• Composure counts, and so does adapting. Visible panic tends to hurt a candidate more than an imperfect number. Equally, a wrong assumption is rarely the problem. Sticking to it after the interviewer offers a better one is. Do not worry if the interviewer moves on before you finish, as long as you were working steadily towards an answer.

These points all reinforce the seven-step method above. The candidates who do well are rarely the ones with the best numbers. They are the ones whose reasoning is easiest to follow, question and trust.