Zepto Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Zepto is one of India's fastest-growing quick-commerce platforms, delivering groceries and essentials in minutes. Machine Learning sits at the core of how Zepto operates, powering demand forecasting at dark stores, delivery time estimation, product recommendations, dynamic pricing, and fraud detection. As of the knok jobradar snapshot, Zepto has 6 open Machine Learning Engineer roles, reflecting active ML hiring even as the broader market shifts.

Candidates report the interview process typically spans three to five rounds. This commonly includes a recruiter screening, one or two technical rounds covering ML concepts and system design, a coding round in Python, and a hiring manager or cultural discussion. The emphasis is heavily applied. Zepto wants engineers who can take a model from a notebook to a production pipeline and measure its real business impact.

1. Walk me through how you would build a demand forecasting model for a dark store with very limited historical data.
2. How would you design a real-time product recommendation system that works within a tight delivery window?
3. How do you detect and respond to data drift in a model running in production at high transaction volume?
4. How do you decide between a simpler model like gradient boosting and a deep learning approach for a given problem?
5. Describe a time you reduced the latency of an ML inference pipeline. What trade-offs did you make?
6. How would you build a dynamic slot pricing or delivery fee model that balances revenue and customer conversion?
7. Walk me through feature engineering for a fraud detection model in a high-velocity transaction system.
8. How do you evaluate an A/B test for an ML-powered ranking change, and what pitfalls do you watch for?
9. Zepto operates many dark stores across cities. How would you help a model generalise across stores with very different demand patterns?
10. How would you handle class imbalance in a dataset for predicting last-mile delivery failures?
11. Describe your experience with ML infrastructure such as feature stores, model registries, and monitoring tools. What gaps have you seen teams run into?
12. How would you explain a model's prediction to a business stakeholder who is skeptical of black-box AI?

Q: Walk me through how you would build a demand forecasting model for a dark store with limited historical data.

*Situation:* At my previous company, we operated a network of fulfillment nodes where several locations had gone live only recently, leaving very little historical demand data to train on.

*Task:* I was asked to build a forecasting solution that could serve new nodes reliably without waiting months for data to accumulate.

*Action:* I framed it as a cold-start problem and used a hierarchical modelling approach. I trained a global model across all nodes combined, encoding store-level features such as locality type, SKU category, and day-of-week patterns as inputs. For new nodes, the model drew on cluster-level patterns learned from similar, more mature locations. I used gradient boosting with time-series cross-validation to prevent target leakage, and added external signals like local events and weather where data was available.

*Result:* The cold-start nodes reached forecast quality comparable to mature nodes within a few weeks of launch, and the business was able to reduce overstock waste in those locations by a meaningful margin.

---

Q: Describe a time you improved the latency of an ML inference pipeline. What trade-offs did you make?

*Situation:* Our product ranking model ran as a synchronous API call inside the checkout flow, and latency had grown to a level where the mobile team flagged it as a user experience risk.

*Task:* I needed to cut end-to-end inference latency without degrading ranking quality.

*Action:* I profiled the full pipeline and found that most time was spent in feature retrieval, not in the model itself. I worked with the backend team to cache frequently requested feature lookups in Redis with a short TTL, so the model only computed features for genuinely new or updated contexts. I also explored model quantization on the embedding layers and ran offline evaluations to confirm that ranking quality remained within an acceptable range before shipping the change.

*Result:* End-to-end latency dropped substantially, meeting the threshold the mobile team needed. Offline ranking metrics stayed stable and the change went to production without a rollback.

---

Q: How would you explain a model's prediction to a stakeholder who is skeptical of black-box AI?

*Situation:* A supply chain manager at my previous company was uncomfortable using our delivery delay prediction model because he could not understand why specific orders were being flagged as high-risk.

*Task:* I needed to build trust in the model without simply asking him to accept its output on faith.

*Action:* I added SHAP-based explanations to the prediction API so each flagged order came with a plain-language breakdown of the top contributing factors, for example: 'this order is flagged primarily because the destination area has a high historical failure rate on rainy evenings.' I then ran a short workshop with the operations team to walk through real examples and let them challenge the model's reasoning with their own domain knowledge.

*Result:* The team adopted the model into their daily workflow. The manager told me afterwards that the explanations made him more confident in the tool, not less, because he could spot cases where the model had caught something his team had missed.

For system design questions (recommendations, forecasting, fraud detection): Structure your answer in four parts. First, clarify the business objective and the success metric you will optimise for. Second, describe the data you need and the features you would engineer. Third, pick a model family and justify the choice given the constraints such as latency, explainability, or data volume. Fourth, explain how you would deploy, monitor, and retrain the model. Zepto cares about the full production lifecycle, not just the modelling step, so spend real time on the monitoring and retraining discussion.

For ML fundamentals questions (bias-variance, regularisation, evaluation metrics): Lead with the core concept in one sentence, give an intuitive analogy, then connect it directly to a realistic scenario. Avoid reciting textbook definitions without context. Interviewers want to see that you know when and why a concept matters in practice, not just that you have read about it.

For past experience (STAR format): Keep Situation and Task brief together. Spend most of your time on Action, being specific about what you personally did versus what the team did. Always close with a concrete Result. If you cannot share exact figures for confidentiality reasons, describe the direction and magnitude clearly, such as 'reduced by roughly half' or 'improved by a meaningful margin.'

For trade-off questions: Acknowledge that the right answer depends on constraints, then walk through two or three trade-offs explicitly. A simpler model may be faster to ship and easier to debug, while a more complex one may capture non-linear patterns that genuinely matter for accuracy. Showing that you think like an engineer weighing real constraints sets you apart from candidates who just pick an answer and move on.

Zepto's ML team builds systems that run at high transaction velocity, so they look for a specific profile beyond textbook ML knowledge.

Production mindset: Candidates who can describe not just how to train a model, but how to monitor it, retrain it, and roll it back when it degrades. A model that silently drifts in a fast-moving commerce environment is a real business risk, and interviewers probe for awareness of this.

Speed and pragmatism: Quick commerce means timelines are tight. Interviewers want to see that you can scope a problem, choose a good-enough solution quickly, and ship it, rather than spending months on the theoretically optimal model.

Cross-functional communication: ML at Zepto touches demand planning, logistics, product, and finance. Being able to explain model outputs to non-technical stakeholders and translate business constraints into ML problem definitions is valued at every seniority level.

Data intuition: Candidates who ask sharp questions about data quality, distribution shifts, and labelling challenges stand out. Zepto's data is high-volume and imperfect. Showing comfort in that kind of environment matters more than assuming clean inputs in your answers.

Systems thinking: Especially for senior roles, expect questions that go beyond the model itself to cover feature pipelines, serving infrastructure, and how ML fits into the broader product architecture.

Two to three weeks before the interview:

Start by understanding Zepto's business in depth. Learn how dark stores work, what drives demand variability in quick commerce, and where ML has the most leverage. Any publicly available material that Zepto's engineering or product teams have shared is worth reading carefully. This business context makes your answers far more relevant than generic ML examples pulled from unrelated domains.

Revise core ML concepts: bias-variance trade-off, regularisation, evaluation metrics such as precision, recall, AUC-ROC, and NDCG for ranking, and common pitfalls like data leakage and target encoding. Practice explaining these out loud rather than just on paper, because articulation under pressure is different from passive understanding.

One to two weeks before:

Work through two or three end-to-end ML system design problems relevant to Zepto: demand forecasting with limited data, a real-time recommendation system, and a fraud detection pipeline. For each, use the four-part structure described in the answer frameworks section. Practice until the structure feels natural rather than mechanical.

Brush up on Python and SQL. Candidates report at least one coding round focused on data manipulation, writing clean ML pipelines, or implementing common algorithms. Focus on writing readable code and explaining your thinking as you go, not just on reaching the correct answer.

Week of the interview:

Prepare four or five strong STAR stories from your own experience. Cover at least one story about production impact, one about working with cross-functional stakeholders, and one about handling a model failure or an unexpected data issue. Practice them until they flow naturally in conversation.

If you want help tracking down the right roles while you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you do not have to spend hours on job boards while also doing interview prep.

Treating it like a research interview. Zepto is an applied ML team. Candidates who focus entirely on model architecture and skip deployment, monitoring, and business impact tend to struggle. Always connect your answer back to what actually changes in the product or business.

Using generic examples. Saying 'I built a recommendation system' without specifics is weak. Be ready to describe the data, the features you engineered, the model you chose, and how you evaluated it. Concrete details are what signal real experience.

Skipping trade-off discussion. When asked to choose between approaches, do not just pick one and move on. Walk through the trade-offs. Interviewers are testing your reasoning process, not just your conclusion.

Assuming clean data in system design answers. Treating data quality as a solved problem is a red flag. Zepto's data is high-velocity and imperfect. Proactively discussing how you would handle missing values, outliers, or distribution shifts signals maturity.

Being vague about your personal contribution. In STAR answers, 'we' is fine for context, but your interviewer wants to know what you specifically did. Use 'I' when describing your own decisions and actions.

Not asking thoughtful questions at the end. Candidates who ask nothing at the close of a round miss an opportunity to show genuine interest. Ask about the team's current ML infrastructure challenges, how model success is measured internally, or what the biggest data quality problems the team is actively working through.