Zomato and Swiggy Interview Questions 2026: SDE Rounds, Data Questions, and Product Sense

Zomato and Swiggy SDE interview process (broadly similar):

1. Resume screen: both companies hire from IITs, NITs, and strong product company backgrounds. LeetCode profile (100+ solved, 50+ medium), previous product company experience, and food-tech or logistics adjacent projects all help.

1. Online Assessment: 2-3 coding problems (LeetCode medium-hard, 90 minutes). Zomato occasionally includes a SQL question. Swiggy may include a data interpretation question.

1. Technical Coding Rounds (2 rounds, 45 minutes each): arrays, strings, trees, graphs, DP. Same pattern as other Indian unicorns.

1. Machine Coding Round (common at Swiggy; less common at Zomato): build a simplified version of a food delivery feature: 'design the data model and core logic for a restaurant menu plus ordering system', 'build a simplified delivery partner allocation system with driver selection logic'.

1. System Design Round (SDE-2 and above): 'design Swiggy's delivery time prediction system', 'design the search and ranking for a restaurant discovery feature', 'design a surge pricing system for delivery partners'.

1. Data and Analytics rounds (for data roles): SQL (complex window functions, retention analysis queries), metric definition questions ('how would you measure the health of our supply-demand matching?'), and guesstimates.

1. HR/Culture Round: Zomato values hustle, scrappiness, and speed. Swiggy values customer obsession, ownership, and execution.

Zomato and Swiggy most common coding topics:

Arrays and strings:

• 'Maximum sum rectangle in a 2D matrix' (extend Kadane's to 2D)
• 'Longest subarray with sum K' (prefix sum + hashmap)
• 'Minimum window substring' (sliding window with character frequency)

Trees:

• 'Binary tree to doubly linked list conversion'
• 'Diameter of binary tree' (for each node, max path through it = left height + right height)
• 'Boundary traversal of binary tree'

Graphs:

• 'Find if a path exists in a grid from start to end' (BFS with obstacles)
• 'Minimum time to rot all oranges' (multi-source BFS)
• 'Word search in 2D grid' (backtracking DFS)

Dynamic Programming:

• 'Maximum sum of non-adjacent elements (house robber)'
• 'Partition equal subset sum' (0/1 knapsack variant)
• 'Maximum profit with at most K transactions' (stock buy-sell with K transactions)

Zomato-specific: graph and shortest-path questions appear more often (restaurant-to-location routing is a domain-relevant graph problem). Swiggy-specific: real-time and stream-processing-related questions (how to handle a continuous stream of driver location updates efficiently).

Data analyst questions at Zomato and Swiggy:

1. SQL window function questions: 'Find restaurants with the highest revenue growth month-over-month in Bangalore.' WITH monthly AS ( SELECT restaurantid, city, DATEFORMAT(orderdate, '%Y-%m') AS month, SUM(ordervalue) AS revenue FROM orders WHERE city = 'Bangalore' GROUP BY restaurantid, month ), growth AS ( SELECT restaurantid, month, revenue, LAG(revenue) OVER (PARTITION BY restaurantid ORDER BY month) AS prevrevenue FROM monthly ) SELECT restaurantid, month, revenue, prevrevenue, (revenue - prevrevenue) / prevrevenue * 100 AS momgrowth FROM growth WHERE prevrevenue IS NOT NULL ORDER BY mom_growth DESC LIMIT 10;

2. Metrics questions: 'Delivery time increased by 15 minutes on average this week. How do you investigate?' Diagnosis framework: is it all cities or one specific city? all times of day or peak hours? all restaurant types or specific categories (high-prep-time restaurants)? is the increase in cooking time, dispatch time (time for a driver to accept), or last-mile time? did any operational change happen this week (new restaurant onboarding wave, driver incentive change, new city launch)?

3. Metric design question: 'Design a metric to measure the quality of our delivery partner allocation algorithm.' Candidate metrics: median time from order confirmed to driver assigned (lower is better), percentage of orders assigned within 3 minutes (higher is better), driver travel distance per delivery (lower indicates better matching), driver utilisation rate (active delivery time / total online time). Composite metric: an SLA score combining assignment time and delivery distance.

Food delivery system design questions:

1. 'Design a real-time delivery partner allocation system': Demand side: orders created by customers, stored in PostgreSQL, published to Kafka. Supply side: delivery partner location updates every 30 seconds to a geospatial index (Redis with GEOADD/GEORADIUS commands or PostGIS). Allocation: when a new order is created, find the nearest available delivery partners within 2km via geospatial query; rank by distance and expected travel time; offer the order to the top partner via a mobile push notification. Acceptance: partner accepts, order assigned. If no response in 60 seconds, offer to the next partner. Scale consideration: a city with 100K active orders per day and 20K drivers means approximately 1-2 allocation events per second; fully achievable with a single Redis geo index and a small Kafka consumer group.

2. 'Design a delivery time estimation (ETA) system': Input features: restaurant preparation time (historical average per restaurant per time-of-day bucket), delivery distance (straight-line + road factor), current traffic conditions (Google Maps API or cached traffic snapshots), driver's current location, time of day, day of week. Model: gradient boosting (XGBoost or LightGBM) trained on historical order completion times. Online serving: features fetched from a real-time feature store (Redis), model served via FastAPI endpoint with P99 under 100ms. Retraining: weekly retraining on the last 30 days of completed orders.

3. 'Design surge pricing for delivery partners during peak hours': Signal: ratio of active orders to available delivery partners in a given zone. Tiers: 1x (normal), 1.25x (moderate surge), 1.5x (high), 2x (extreme). Zone granularity: 1x1km hexagonal zones using Uber's H3 library. Update frequency: zone prices recalculated every 5 minutes. Customer display: surge multiplier shown prominently on the checkout screen before order placement. Partner incentive: partner earnings increase proportionally, attracting more drivers to high-surge zones.

Product sense questions (for PM and senior SDE interviews at Zomato/Swiggy):

1. 'How would you improve the restaurant discovery experience on Swiggy?' Structure: clarify the user segment (casual browser vs specific-craving searcher vs repeat-order user), current state assessment, hypothesise problems (search is too broad; no personalisation for dietary preferences; discovery limited to top 10 results), generate solutions (personalised ranking by user history + stated preferences, filter by dietary requirements, surface hidden gems with good ratings but low visibility), prioritise (impact x confidence x ease), measure (click-through rate on restaurant cards, order conversion rate, first-time restaurant order rate).

2. 'Zomato Gold membership has seen a decline in redemptions. What would you do?' Diagnose first: is the decline in unique users redeeming, or in total redemptions per user? Is it specific restaurants or systemwide? Is it a product awareness issue (users do not know how to redeem) or a value issue (the discount does not feel worth it) or a supply issue (fewer participating restaurants)? Then hypothesise solutions based on the diagnosis.

3. 'How would you design a feature to reduce food waste on the Zomato restaurant side?' User: the restaurant operator (not the end customer). Problem: accurate demand forecasting reduces overpreparation and waste. Solution components: historical order data analysis per restaurant, day-of-week and weather-based demand prediction, real-time order surge alerts for kitchen prep, incentivised 'last order of the day' discount mechanism.