Zomato Data Scientist Interview: Questions, Experience & Prep (2026)

Zomato is one of India's most data-intensive consumer tech companies, with food delivery, quick commerce (Blinkit), and dining discovery running on real-time data at scale. Data Scientists at Zomato work on problems ranging from delivery time prediction and dynamic pricing to restaurant recommendations and fraud detection.

As of July 2026, knok jobradar tracked 9 open Data Scientist roles at Zomato. Roles span multiple experience levels, from entry-level positions to senior scientists leading product experiments.

Candidates report that the interview process typically runs across 3 to 5 conversations. The first is usually a recruiter or hiring manager screening call. Technical conversations follow, covering SQL, probability, statistics, and machine learning concepts. Many candidates also report a case study or product analytics round where you are given a real Zomato scenario and asked to structure your approach end-to-end. A final conversation with a senior stakeholder or hiring manager typically closes the process.

Zomato interviewers are known for grounding questions in actual product scenarios: order metrics, restaurant health, user retention, and supply-demand dynamics. The ability to connect data analysis to business outcomes is as important as technical skill.

These questions come up most often based on candidate reports. They are specific to Zomato's business model and product context.

1. A restaurant's daily order count drops sharply over a few days with no obvious trigger. Walk us through how you would investigate this.
2. How would you design an A/B test to evaluate a new restaurant ranking algorithm on the Zomato home screen?
3. Write a SQL query to find the top 5 restaurants by revenue in each city over the past month. Assume you have tables for orders, restaurants, and cities.
4. How would you build a model to predict estimated delivery time for an order at the moment it is placed?
5. What metrics would you track to measure the overall health of Zomato's food delivery business, and how would you prioritize them?
6. How would you detect fraudulent orders or fake restaurant reviews on the platform?
7. How would you design a restaurant recommendation system for a user who has ordered fewer than 5 times?
8. Your A/B test shows a new checkout feature increases order frequency but reduces average order value. What decision do you make and why?
9. How would you measure and reduce churn among Zomato Pro subscribers?
10. Walk us through how you would calculate customer lifetime value (CLV) for a Zomato user from scratch.
11. You have a highly imbalanced dataset where the event you want to predict (such as an order complaint) is a rare occurrence. How do you approach building a classification model?
12. Zomato is entering a new city. What data would you collect, and what models would you build to prioritize which restaurants to onboard first?

Use the STAR format for behavioural and product questions. Here are three examples tailored to Zomato-style interviews.

Q: Tell me about a time you used data to improve a key business metric.

*Situation:* At my previous role, our team noticed that new users were placing a first order but rarely returning within the first week.

*Task:* I was asked to understand the drop-off pattern and recommend a data-driven intervention.

*Action:* I ran a cohort analysis segmenting new users by their first-order experience, including delivery time, order value, and cuisine type. I found that users whose first order arrived late were significantly less likely to reorder. I built a logistic regression model to flag newly acquired users at risk of churning based on their first-order signals.

*Result:* The CRM team used the model output to trigger a personalized follow-up message the next day. Post-campaign analysis showed a meaningful improvement in early repeat order rates compared to the control group.

---

Q: Describe a time your analysis changed a business decision.

*Situation:* The product team was planning to remove a filter feature from the restaurant listing page, assuming it was rarely used.

*Task:* I was asked to validate or challenge this assumption before the feature was deprecated.

*Action:* I pulled usage logs and found that while the filter was used by a small share of users overall, those users had a significantly higher average order value and order frequency. I segmented further and found they skewed toward premium customers in metro cities. I presented the finding with a revenue impact estimate anchored to publicly reported conversion benchmarks.

*Result:* The product team reversed the decision and instead prioritized improving the filter's UI. This is a case where the data told a different story than the assumption, and being specific about the user segment made the argument convincing.

---

Q: Tell me about a time you worked with incomplete or messy data.

*Situation:* I was building a delivery time prediction model and discovered that GPS coordinates for delivery partners were missing for a large share of historical records during peak hours.

*Task:* I needed to clean the data, impute values, or find an alternative approach that would maintain model accuracy.

*Action:* I investigated the missingness pattern and found it was not random. It correlated with specific delivery zones and time windows, which itself became a useful signal. I imputed missing coordinates using the median location for the partner's active zone during that time window, documented my assumptions clearly, and added a data quality flag as a model feature so the model could account for uncertainty.

*Result:* The model performed well on the held-out test set, and the data quality flag turned out to be predictive in its own right. I also raised the GPS data collection issue with the engineering team for a proper fix.

For metric drop or spike questions: Start by clarifying scope. Is the drop in one city, one restaurant category, one device type, or across the whole platform? Then check for external causes such as public holidays, app outages, or competitor promotions. Next, segment by dimension: city, cuisine, time of day, restaurant tier. Finally, propose a root cause hypothesis and the next data pull that would confirm or rule it out. Candidates who jump straight to 'maybe the algorithm changed' without ruling out external factors first get marked down.

For A/B test design questions: Cover four things in order: the hypothesis you are testing, the randomization unit (user, restaurant, or order), the primary metric and guardrail metrics, and the sample size and duration required. For Zomato specifically, always mention spillover effects. A user exposed to the test on mobile might also visit the website, so intent-to-treat analysis and network effects are worth addressing.

For model-building questions: Follow a product-to-model arc. Start with the business problem and the decision the model will drive. Then define the target variable, the training data, the features, and the model family. End with how you would evaluate the model offline and how you would monitor it after deployment. Zomato interviewers appreciate candidates who think about model freshness and data drift, not just training accuracy.

For SQL questions: Think out loud. State your approach before writing the query. Use CTEs to keep logic readable. Common Zomato SQL themes include window functions for ranking restaurants per city, time-series aggregations for order trends, and multi-table joins on schemas with orders, restaurants, users, and delivery partners.

Based on candidate reports, Zomato Data Science interviewers look for a few specific qualities.

Business first, model second. Candidates who immediately reach for a complex model without first clarifying the business problem tend not to do well. Interviewers want to see that you understand what decision your model will drive and what 'good enough' looks like in a product context.

Clear thinking under ambiguity. Most case questions are deliberately under-specified. Interviewers want to see you ask clarifying questions, state your assumptions out loud, and structure your approach before diving in. Silence followed by a long monologue is worse than a short clarifying question at the start.

Honest handling of trade-offs. Zomato operates at significant scale, so answers that ignore operational costs, latency constraints, or data freshness requirements feel naive. Acknowledge trade-offs openly: a more complex model may be more accurate but harder to debug and slower to retrain.

Communication that non-technical stakeholders can follow. Several rounds may involve product managers or business leads. Practice explaining your approach in plain language. If you say 'gradient boosting,' be ready to explain what it does in one sentence without jargon.

SQL fluency taken seriously. Candidates report that SQL is not treated as a warm-up. Window functions, subqueries, and multi-table joins are fair game, and weak SQL performance can be disqualifying.

Week 1: Foundations and SQL

Practice SQL daily, focusing on window functions, CTEs, and time-series queries. Use publicly available SQL practice platforms. Study Zomato's products in depth: read their publicly available annual reports, understand how the app works across food delivery, Blinkit, and dining, and note the metrics that would matter for each product line.

Week 2: Statistics, Probability, and Experiment Design

Review hypothesis testing, p-values, confidence intervals, and the common mistakes in A/B testing such as peeking, multiple comparisons, and novelty effects. Practice designing experiments end-to-end: hypothesis, randomization unit, metrics, and duration. These topics come up in almost every Zomato DS interview.

Week 3: Machine Learning and Product Cases

Review classification, regression, and recommendation system fundamentals. Focus on model evaluation metrics such as precision, recall, and AUC, and on how to choose between them based on business context. Practice product analytics cases using Zomato scenarios: delivery time prediction, fraud detection, restaurant ranking, and churn prediction.

Week 4: Behavioural Questions and Mock Interviews

Prepare 5 to 6 STAR stories from your past work. Cover at least: a time you improved a metric, a time your analysis changed a decision, a time you dealt with messy data, and a time you disagreed with a stakeholder. Do at least one full mock interview with a peer or on a practice platform before your actual interview.

Skipping the business context. Many candidates jump straight into model details without first framing why the model matters. Always anchor your answer to the business decision it will drive.

Underestimating SQL. Candidates often under-prepare for SQL because they assume it will be basic. Zomato SQL questions typically involve multi-table schemas, ranking with window functions, and time-based aggregations. Prepare accordingly.

Treating one model as the right answer. There is rarely a single correct model for a Zomato case question. Interviewers care more about your reasoning than your conclusion. Explain why you chose a particular approach and what its limitations are.

Ignoring guardrail metrics in A/B tests. Candidates often mention only the primary success metric. Always discuss what you would monitor to make sure the experiment does not unintentionally harm other parts of the business, such as customer satisfaction or restaurant experience.

Not asking clarifying questions. Jumping into a case without asking about scale, available data, or the decision the analysis will drive makes you look like a coder, not a scientist. Asking thoughtful questions is part of the evaluation.

Vague STAR answers. Saying 'I improved the model and the business was happy' is not a STAR answer. Interviewers want to know exactly what you did, what trade-offs you made, and what you learned from the experience.