Swiggy Product Manager Interview: Questions & Prep (2026)

Swiggy PM interviews test whether you can reason about a three-sided marketplace under real-time constraints: customers who want food in 30 minutes, restaurant partners who want order volume without discount fatigue, and delivery partners whose earnings depend on how well you batch and route them. The loop typically runs recruiter screen → product sense round → execution/metrics round → hiring manager round, sometimes with an additional leadership or values conversation at senior levels. Candidates report the execution round leans hard on unit economics — you're expected to think in per-order terms (delivery cost, take rate, discount burn, contribution margin) rather than vanity metrics. Instamart adds a second dimension: quick-commerce questions about dark-store economics, assortment, and 10-minute delivery trade-offs show up frequently. Every answer lands better when anchored in Indian food-delivery reality — IPL-night demand spikes, monsoon supply crunches, and price-sensitive users who churn on a ₹20 delivery fee. If you're earlier in the funnel, start with the broader guide on [how to get hired at Swiggy](/company_guide/how-to-get-hired-at-swiggy.html).

1. Delivery partners are declining orders in a specific zone during dinner peak. Diagnose the problem and propose a fix that doesn't blow up cost per delivery.
2. Average delivery time in Bangalore increased by four minutes over two weeks. Walk me through your investigation.
3. Should Swiggy batch more orders per delivery partner during peak hours? Argue both sides with the metrics you'd watch.
4. Design a feature to increase order frequency for users who order twice a month.
5. Restaurants complain that discounts eat their margins, but removing discounts drops order volume. How do you resolve this as a platform?
6. Instamart wants to promise 10-minute delivery in a new city. What would you need to believe for that to be unit-economics positive?
7. It's an IPL final night and order volume is 3x forecast. What degrades first, and what do you protect at all costs?
8. How would you decide which SKUs an Instamart dark store in a tier-2 city should stock?
9. A surge fee during rain reduces order cancellations by restaurants but increases customer drop-off at checkout. Structure the trade-off.
10. Estimate how many delivery partners Swiggy needs in Pune on a Saturday night.
11. What's one Swiggy feature you'd kill or radically change, and what data would you want first?
12. Design the experience for a customer whose order was picked up but the delivery partner's phone went offline.

Q: Delivery partners are declining orders in a zone during dinner peak. Diagnose and fix.

*Situation:* At a hyperlocal delivery company I worked with, partner acceptance rates in two urban zones dropped below 70% during evening peak.

*Task:* I owned restoring acceptance without simply raising per-order payouts across the board.

*Action:* I segmented declines by cause: long first-mile distance to restaurants, orders from slow-preparing outlets that forced partners to wait unpaid, and payout-per-minute falling below the partner's alternative (a competitor's incentive window). I shipped restaurant-level prep-time predictions into the dispatch logic so partners were assigned closer to food-ready time, and added a targeted wait-time payment only for the slowest 10% of outlets.

*Result:* Acceptance recovered to 88% in four weeks with a 6% increase in zone-level delivery cost — far cheaper than the blanket incentive alternative we'd modelled. At Swiggy I'd start the same way: decompose declines before spending money on them.

Q: Should Swiggy batch more orders per partner during peak?

*Situation:* I ran a batching experiment for a delivery product where singles-only dispatch was driving cost per order up during peaks.

*Task:* Increase orders per partner-hour without breaking the delivery-time promise.

*Action:* I defined guardrails first — p90 delivery time and order-level ratings — then tested batching only for order pairs within a tight pickup-and-drop corridor, predicted by route overlap rather than raw distance. Batches that risked cold food (long second-drop) were excluded.

*Result:* Orders per partner-hour rose 14% in the test cohort; p90 delivery time held within one minute of control. The lesson I'd bring to Swiggy: batching is a constraint-satisfaction problem, not a dial — decide what you refuse to degrade, then push utilisation against it.

Q: Average delivery time increased four minutes in Bangalore. Investigate.

*Situation:* I faced a similar creep in a metro market at a previous role.

*Task:* Isolate root cause within a week, since delivery time drove both retention and partner costs.

*Action:* I split delivery time into stages — assignment, first mile, restaurant wait, last mile — then cut by zone, hour, and restaurant cohort. The regression isolated to restaurant wait time in three zones where a batch of new high-volume outlets had onboarded with unrealistic prep-time estimates.

*Result:* Correcting prep-time inputs and re-tuning dispatch recovered three of the four minutes within two weeks. Stage-wise decomposition beats hypothesising about traffic every time.

For marketplace questions, name all three sides explicitly and state which side's problem you're solving before proposing anything — most weak answers silently optimise customers and break partner economics. For metric investigations, decompose delivery time into stages (assignment → first mile → restaurant wait → last mile) or order volume into traffic × conversion × frequency, then segment by zone, hour, and cohort. For unit-economics questions, write the per-order equation aloud: revenue (commission + delivery fee + ads) minus delivery cost, discounts, and support cost — then show which lever your proposal moves. For Instamart questions, reason from dark-store fixed costs, basket size, and delivery radius rather than treating it as food delivery with groceries. For prioritisation, use contribution-margin impact vs. effort, and say what you'd explicitly not do this quarter.

Candidates report Swiggy interviewers probe for three things. First, genuine unit-economics fluency: you should move between take rate, cost per delivery, discount burn, and contribution margin per order without being prompted, and know that a growth idea which destroys per-order economics is not a growth idea. Second, operational empathy for all three sides — answers that treat delivery partners as an infinitely elastic resource typically land poorly. Third, comfort with real-time trade-offs: what you degrade gracefully on an IPL night (delivery-time promise, serviceable radius, batching aggressiveness) and what you protect (order integrity, partner safety). Interviewers also reward candidates who distinguish food delivery from quick commerce instead of pattern-matching one onto the other.

Week 1: build the metric trees. Write out order volume (users × frequency × conversion), delivery time by stage, and per-order contribution margin, then practise decomposing two hypothetical regressions aloud each day. Week 2: do five product design questions anchored in specific Indian users — a hostel student in Kota, a family in Indiranagar ordering on a rainy Sunday — and three three-sided trade-off questions where you argue the tension explicitly. Add two Instamart cases on assortment and dark-store economics. Week 3: prepare six STAR stories covering ownership, conflict, a failed experiment, and a data-driven call, each with one defensible number in the result, and run two mocks with a PM who has worked in Indian food delivery or quick commerce. Alongside prep, keep your pipeline warm: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit PM roles, and drafts hiring-manager outreach, so interview practice doesn't come at the cost of applications.

Optimising one side of the marketplace while silently taxing another — the classic is boosting order volume with discounts and never mentioning restaurant margin or delivery cost. Treating delivery partners as a cost line instead of a supply side with its own churn and incentive dynamics. Answering Instamart questions with food-delivery logic; dark-store economics are a different equation. Quoting delivery-time or order-volume numbers as fact — hedge with "I'd validate with your data." Ignoring peak-load reality: any dispatch or batching answer that doesn't mention what happens at 3x demand is incomplete. STAR stories with no numbers, or growth stories where you can't explain the unit-economics cost of the growth.