Zomato Data Scientist Mock Interview and Preparation

After a screening call, Zomato data science candidates typically move through a mix of technical rounds and a business-facing discussion. The blend usually covers:

• SQL and data manipulation: multi-table joins, window functions, cohort and funnel queries on order data.
• Machine learning fundamentals: model choice, bias-variance, evaluation metrics, handling imbalanced classes.
• Applied/case round: frame a real Zomato problem (ETA, ranking, fraud, churn) end to end.
• Statistics and experimentation: hypothesis testing, A/B design, interpreting results.
• Behavioural/stakeholder: how you communicate findings to non-technical partners.

The signal Zomato wants is a scientist who ships models that move a marketplace metric, not someone who only tunes offline accuracy.

Expect problems drawn from Zomato's actual surface area: predict delivery time (ETA) given distance, restaurant prep time, weather and rider load; rank restaurants on the home feed to maximise long-term orders, not just clicks; detect fraudulent refunds or fake ratings; predict which lapsing users will churn and who to target with a coupon.

A strong ETA answer discusses the target definition (promise time vs actual), features across all three marketplace sides, why you might use gradient-boosted trees before deep models, and how error asymmetry matters (underpromising vs overpromising hurts differently). A weak answer jumps to a neural network without discussing the loss function or the business cost of errors.

SQL is often a filter round. Practise window functions (running order counts per user, rank within city), self-joins, and cohort retention queries. A frequent prompt: find users whose average order value dropped month over month. Talk through your query as you write it.

On experimentation, Zomato ships changes via A/B tests, so be ready to design one: pick the metric, compute a rough sample size, choose randomisation unit (user vs city vs session), account for network effects in a marketplace, and interpret a result that is significant but tiny. Know the difference between statistical and practical significance, and how you would handle a metric that improved while a guardrail metric like cancellations worsened.

SQL fluency and clean experiment reasoning are the through-line for most Data Analyst / Data Science Jobs at this bar, so the drills below pay off well beyond a single Zomato loop.

Build depth in three areas and you cover most of the loop. First, rehearse two end-to-end ML cases (an ETA/regression problem and a churn/classification problem) including metric choice and deployment concerns. Second, drill twenty SQL problems focused on windows and cohorts. Third, be able to design and critique an A/B test in five minutes.

• Keep evaluation metrics at your fingertips: precision/recall trade-offs, MAE vs RMSE, AUC, and why each fits a given business cost.
• Prepare a story where your analysis changed a product or operational decision.

Then rehearse speaking it aloud. A free AI voice mock on InterviewPrep builds a Zomato-style data science mock from your CV and a target job description, and scores your answers, pace and filler words, so your explanations stay crisp when a real interviewer is listening.

The most common failure is optimising an offline metric with no line to a business outcome. A model that improves AUC but never ships, or that ignores latency for a real-time ranking surface, wins little credit. Interviewers want to hear how the model plugs into the product: how predictions are served, refreshed and monitored, and what happens when they are wrong.

• Define the target crisply. For churn, state the observation window and the definition of churn before modelling; vague targets undermine everything downstream.
• Respect imbalance. On fraud or fake-rating problems, never quote accuracy; lead with precision-recall and the cost of each error type.
• Sanity-check data. Mention leakage, seasonality (festival and weekend effects on orders), and how you would validate with a temporal split rather than a random one.

Another frequent slip is treating experimentation naively in a marketplace: a user-level A/B test can leak through shared supply, so acknowledge network effects and mention region or switchback designs. Finally, communicate like a scientist who partners with product: state assumptions, quantify uncertainty, and be honest about limitations. Candidates who say "here is what I would monitor after launch and how I would roll back" signal the operational maturity Zomato's data science teams look for.