Meesho Data Scientist Interview: Questions & Prep (2026)

Meesho is one of India's largest social commerce platforms, built for resellers and buyers in Tier 2 and Tier 3 cities. Data Scientists here work on problems that directly move the needle for sellers and buyers, including pricing recommendations, demand forecasting, fraud detection, personalised recommendations, and supply chain efficiency.

As of July 2026, knok's job radar shows Meesho has 63 open Data Scientist positions, placing it among the more active hirers in this space. The interview process candidates report typically runs through several stages: an initial screening with a recruiter or senior DS, one or two technical rounds covering statistics, SQL, and machine learning, a case study or product-sense round, and a final conversation with the hiring manager. Process details can change, so treat these as typical patterns rather than guarantees.

Meesho's interview style leans heavily on business context. You will rarely get a pure algorithm puzzle. Instead, expect to connect every data science choice back to reseller growth, buyer retention, or platform health.

Candidates who have interviewed at Meesho typically report questions from the following areas.

1. Seller pricing recommendation: 'How would you build a model to recommend the right selling price for a new reseller joining Meesho?'

1. Reseller churn prediction: 'Design a system to identify resellers likely to go inactive in the coming month. What features would you use and how would you validate the model?'

1. A/B testing design: 'Meesho launches a new reseller onboarding flow. Walk me through the full experiment design, from hypothesis to decision.'

1. SQL window functions: 'Given an orders table (order_id, seller_id, buyer_id, order_date, order_value), write a query to rank sellers by total revenue for the last quarter, returning only those with at least five unique buyers.'

1. Metric design: 'What metrics would you track to measure the overall health of Meesho's reseller ecosystem? How would you detect early warning signs before a metric drops visibly?'

1. Recommendation cold start: 'How would you design a product recommendation system for Meesho's home feed? What changes when a new user has no purchase history?'

1. Fraud detection: 'How would you spot fraudulent orders on a platform where many buyers and sellers know each other personally and transactions look legitimate on the surface?'

1. Demand forecasting for festive sales: 'Build a demand forecast for Meesho's fashion category ahead of Diwali. What data, model, and evaluation metric would you choose, and why?'

1. Borderline significance: 'You run an A/B test and get a borderline p-value. Your stakeholder says ship it anyway. What do you do?'

1. Early reseller success signals: 'What signals from a reseller's first week of activity would best predict their long-term retention on the platform?'

1. Class imbalance: 'Fraud events are rare on this platform. How do you handle severe class imbalance when training a classifier, and how do you choose the right evaluation metric?'

1. New category expansion: 'Meesho is considering entering a new product category. How would you use data to evaluate whether this is a good business decision?'

Q: Design a system to identify resellers likely to go inactive in the coming month.

*Situation:* At my previous company, we noticed a segment of registered sellers steadily reducing order volume with no automated outreach triggered before they fully dropped off.

*Task:* I was asked to build a churn prediction model so the growth team could intervene before sellers went permanently inactive.

*Action:* I started by defining 'churn' clearly with the business team: a seller with zero orders for a set window after prior activity. Then I pulled features spanning login frequency, order volume trend, average order value, product listing updates, and support ticket history. I trained a gradient boosting classifier, tuned the decision threshold to favour recall since catching more at-risk sellers mattered more than precision here, and validated on a holdout time period. I packaged scores into a daily dashboard so the outreach team could act within hours of a fresh prediction run.

*Result:* The model identified a consistent at-risk cohort each week. The growth team's targeted messages led to a measurable lift in seller reactivation, tracked in the business's weekly seller-health report. The model became a standard input to the retention workflow.

---

Q: You run an A/B test and get a borderline p-value. Your stakeholder wants to ship the change.

*Situation:* At a previous role, we ran a test on a checkout UI change for two weeks. The result came back borderline, just short of our pre-agreed significance threshold.

*Task:* The product manager was under deadline pressure and wanted to ship, but I was responsible for the experiment's integrity.

*Action:* First, I checked whether the test was underpowered by reviewing our pre-test sample size plan. The test had run shorter than originally intended because traffic dipped mid-run. I explained to the PM that a borderline result from an underpowered test is not the same as a positive result: shipping risked no real improvement while adding engineering maintenance cost. I proposed two options: extend the test for one more week to reach the planned sample, or ship to a small slice of users and monitor the core metric tightly before a full rollout.

*Result:* We extended the test. The extended run crossed the significance threshold clearly and we shipped with confidence. The PM later agreed that waiting avoided a potential rollback that would have cost more time than the delay itself.

---

Q: How would you design a product recommendation system for Meesho's home feed for new users?

*Situation:* Early in my career I joined a team building personalisation for a marketplace where a large share of new users had zero purchase history, making collaborative filtering useless out of the gate.

*Task:* I needed a recommendation flow that was useful from the very first session without requiring past behaviour.

*Action:* I used a two-tier approach. In the first tier, I served popularity-based recommendations segmented by the user's city and device type, since regional bestsellers tend to convert better than global ones. In the second tier, as soon as a user clicked or spent time on any item, I applied a session-based model trained on click sequences to shift recommendations in real time within that same session. I ran an interleaving experiment to compare this hybrid against a pure-popularity baseline.

*Result:* Session click-through improved over the pure-popularity baseline according to our experiment metrics, and the session-based signals kicked in fast enough that most users received personalised results within their first browsing session.

Lead with the business problem, then the method. Meesho interviewers typically want to hear 'here is the outcome I was optimising for' before you name any algorithm. Saying 'I used XGBoost' without explaining why you chose it over a simpler model signals that you default to tools rather than thinking.

For ML design questions, follow this structure: Define the prediction target clearly. List the features and explain why each one is informative. State the model family and justify it. Name the evaluation metric and explain why it fits the business goal (precision vs. recall tradeoffs matter a lot for fraud and churn). Describe how you would monitor the model after deployment.

For metric and product questions, anchor on Meesho's core stakeholders: resellers, buyers, and the platform itself. A strong answer names a metric for each layer, explains how they interact, and flags any tension. For example, a metric that looks good for resellers might quietly harm buyer experience.

For SQL questions, think aloud. Interviewers care as much about how you break down a problem as whether you get the syntax perfect. Name the joins and aggregations you need before writing code, then walk through the logic step by step.

For experimentation questions, cover the full lifecycle: hypothesis, unit of randomisation, sample size and power calculation, guardrail metrics, test duration, and decision criteria. Candidates who stop at 'run a t-test' typically do not clear this round at Meesho.

Based on what candidates report, Meesho DS interviewers look for a combination of technical rigour and commercial awareness.

Business orientation. Every solution should connect to seller growth, buyer retention, or platform efficiency. Purely academic answers with no link to impact tend to score lower, because Meesho's data teams are expected to influence product and operations decisions directly.

Statistics fundamentals. Probability, hypothesis testing, p-values, confidence intervals, and experiment design come up consistently. These are tested more deeply than at many other product companies because Meesho runs a large volume of experiments across its platform.

SQL fluency. Window functions, subqueries, and multi-table joins are expected at mid and senior levels. Entry-level candidates typically need solid core query skills at minimum.

Structured communication. Interviewers want to follow your reasoning step by step. Jumping to an answer without explaining your logic, or giving a long answer with no clear structure, both work against you.

Honest handling of uncertainty. If you do not know something, saying 'I would validate this assumption with data before committing' is better than guessing. Meesho's culture, like most data-driven companies, values intellectual honesty over projecting false confidence.

Week 1: Foundations

Start with statistics and probability: sampling distributions, hypothesis testing, p-values, Type I and Type II errors, and Bayesian basics. Practice SQL daily, focusing on window functions (RANK, ROW_NUMBER, LAG/LEAD), grouped aggregations, and self-joins. Read Meesho's publicly available product and engineering blog posts to understand the problems the company actually solves at scale.

Week 2: Machine Learning and Case Studies

Practise end-to-end ML design: define the problem, choose features, pick a model, set an evaluation metric, plan for production monitoring. Focus on tree-based models, logistic regression, and recommendation approaches. Do at least two or three mock case studies out loud, ideally with a peer who can push back on your assumptions. Practise translating every technical choice into a business justification.

Week 3: Mock Interviews and Polish

Do full mock interviews under timed conditions. Record yourself answering out loud to catch filler words and unclear transitions. Prepare two or three STAR stories from your own experience that map to Meesho's problem areas: churn, fraud, pricing, or experimentation. Review your strongest projects so you can go deep on any follow-up question.

Candidates report that the case study or take-home round (where it exists) is often the most differentiating stage. Structure your write-up clearly and include a section on model limitations and next steps, not just the method you chose.

Skipping the business framing. Answering 'I would use a random forest' without explaining what outcome you are predicting or why that model fits the business constraint is one of the most commonly reported reasons for rejection at Meesho and similar product companies.

Treating A/B testing as a checkbox. Saying 'I would run an A/B test' is not a complete answer. Interviewers want to hear about randomisation unit, guardrail metrics, minimum detectable effect, test duration, and what you do with an inconclusive result.

Over-engineering the ML solution. Proposing a deep neural network for a problem that a logistic regression handles well signals poor judgment. Start simple, justify complexity only when you add it.

Ignoring model monitoring. Answering only up to model training and skipping production deployment, data drift, and retraining signals leaves a gap that senior interviewers notice immediately.

Weak SQL under pressure. Many candidates prepare ML theory but underestimate the SQL depth expected. Practice writing queries from scratch, not just reading them. Window functions appear in nearly every mid-level SQL round candidates report from Meesho.

Not asking clarifying questions. Walking into a case question and immediately solving for one interpretation, without checking assumptions first, signals rigidity. Interviewers expect you to probe the problem space before committing to an approach.