Swiggy PM Interview — Bangalore Dinner-Peak Order Volume

It tests whether you can turn an ambiguous marketplace question into a defensible quantitative model out loud. The interviewer is not grading numeric accuracy. They are watching whether you clarify scope before computing, build a segmentation tree before any arithmetic, state the reasoning behind each assumption before using it, run both a bottom-up and a top-down path, reconcile them when they diverge, and close with a strategic implication. Freezing under deliberate silence and skipping the sanity-check are the two fastest ways to lose this round.

Open by clarifying scope: food delivery only, not Instamart or Dineout, Bangalore only, dinner window only. State which window you mean and why, for example 7 to 10 PM with the sharpest demand 8 to 10 PM. Then say your segmentation out loud before multiplying: from city population down to people who actually order food on the app on a given evening, or from a known Swiggy daily-order anchor down to the Bangalore dinner-hour share. Narrate every assumption with a reason, then run the other direction as a cross-check and reconcile.

Starting to multiply before clarifying scope or stating a structure. Using a per-user order frequency or urban share without saying why it is reasonable. Going silent when the interviewer stops guiding instead of narrating the next step. Reporting an all-day average as if it were the peak-hour rate. Counting Instamart or Dineout volume as food orders. Assuming the whole Bangalore market is Swiggy and ignoring the Zomato split. Quoting a falsely precise number like 187,432 instead of a defensible rounded range.

It behaves like a deliberately non-guiding Swiggy interviewer who withholds the expected flow on purpose. It will not coach you toward a framework, will not praise an answer, and will not feed you the next step. It probes every assumption, interrupts mid-calculation, introduces a constraint such as rain collapsing rider supply, and asks for a sanity-check if you produce a number with no cross-check. The difference is that it never tires, applies the same depth on every thread, and produces a transcript-backed scorecard at the end.

Your transcript is scored against dimensions that mirror how published PM guesstimate frameworks grade: scope and market definition, segmentation structure before arithmetic, assumption justification, numeric fluency under interruption, sanity-check and reconciliation, and the closing strategic implication. Each dimension has observable signals. The report quotes the specific moment your structure broke or an assumption went ungrounded, rather than returning a single pass or fail verdict.

Do not start estimating. Spend the first minute clarifying scope out loud: confirm food delivery only, exclude Instamart and Dineout, confirm Bangalore only, and pin the dinner window you will use with a reason. Then state the segmentation path you intend to take before you touch a single number, and say you will run a second path as a cross-check. This signals structure before arithmetic, which is the single strongest predictor of a positive outcome in this round.

Do not abandon your structure. Name which node of your model the constraint hits. Rain across Bengaluru collapses rider supply, so fulfilled orders per hour fall even though demand may rise, which is a supply-constrained ceiling, not a demand change. A festival evening shifts the dinner concentration factor and per-user frequency upward. State which assumption you are revising, re-run only that branch, and give a new defensible range rather than starting over.

It sounds like someone narrating a tree before any math: city population, share who use food apps, share who order on a given evening, average orders, then the dinner concentration factor, and finally the Swiggy share of the duopoly. Every number arrives with a one-line reason. The candidate then says a sentence like, let me check this from the top down using Swiggy's known daily order volume, reconciles the two within a 2 to 3 times band, and closes with what the number means for surge pricing and rider supply.

Bangalore food-delivery demand is shared across a Swiggy-Zomato duopoly. If you estimate total city dinner-peak orders and then report that as Swiggy's number, you have overcounted by roughly the Zomato share. A strong answer estimates total city dinner-peak food orders, then applies an explicit Swiggy market-share assumption with a stated reason, rather than silently assuming the entire market is Swiggy. Forgetting this split is one of the most common observable failure patterns in this round.

Use both. Build one path bottom-up from Bangalore population through the funnel of people who actually order food on the app at dinner, and one path top-down from Swiggy's known national daily order volume scaled to Bangalore and to the dinner hour. Then reconcile. If the two diverge by more than 2 to 3 times, locate the broken assumption rather than averaging blindly. Running both and reconciling is what separates an adequate answer from a strong one.