
Meesho Business Analyst interview typically runs 2 rounds: Technical SQL & Problem Solving, Product Sense & Case Study. It usually takes about 1 interview cycle and is highly conversational and unstructured.
$1250K
Avg. Base Comp
$1978K
Avg. Total Comp
2
Typical Rounds
1-2 weeks
Process Length
Our candidates report that Meesho is looking for analysts who can move cleanly from ambiguity to a testable hypothesis. In the SQL round, the strongest signal wasn’t just getting to a self-join; it was anticipating edge cases like circular routes and explaining why a destination filter matters for path validity. That kind of precision shows up repeatedly in Meesho-style problems: the interviewer wants to see whether you can reason about data relationships, not just write a query that runs.
A recurring theme in the product case is that Meesho values analysts who can separate internal breakage from external demand shifts without getting lost in theory. One candidate was pushed to keep narrowing the funnel until the failure point was isolated, then to move outward only after checkout looked clean. That tells us the bar is less about naming frameworks and more about whether you can use them to drive a real investigation: payment failures, fee changes, delivery promises, seasonality, and competitor promotions all came up as concrete checks.
We’ve also seen that Meesho likes candidates who stay responsive when the interviewer changes the facts midstream. The best answers weren’t polished monologues; they were live pivots based on new constraints. In other words, the company seems to reward analysts who can defend a hypothesis, revise it quickly, and keep the analysis tied to what the business can actually act on.
Synthesized from 1 candidate report by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Meesho process.
Round 1: Technical SQL & Problem SolvingThe SetupThis round began with a brief resume walk-through before the interviewer pasted a raw problem statement into a shared coding editor.The Question: "You have a table of flight/travel routes. Find the cheapest cost to travel from a starting point to an ending point, but there's a catch: the traveler cannot take a direct flight. They must make at least one halt. How would you write this?"The Interviewer Interaction & Solution EvolutionMy Initial Clarification: Before jumping into the code, I asked the interviewer to clarify the table schema. I asked if we could assume a standard routes table with origin, destination, and cost. The interviewer confirmed this and added, "Assume all costs are positive, and the routes are directed."My Stated Approach: I explained that since a direct path was barred and exactly one intermediate stop was the minimum requirement, we needed to connect two separate legs of a journey. I told them my strategy was to use a Self-Join on the routes table to map Leg A (Start to Halt) to Leg B (Halt to End).Live Coding: I wrote out the query, joining the table to itself where the destination of the first table matched the origin of the second (r1.destination = r2.origin).I wrote a SQL query: SELECT r1.origin AS start_location, r2.destination AS end_location, MIN(r1.cost + r2.cost) AS minimum_travel_cost FROM routes r1 JOIN routes r2 ON r1.destination = r2.origin WHERE r1.origin <> r2.destination GROUP BY r1.origin, r2.destination; Interviewer Follow-up & My Defense: The interviewer stopped me and asked, "What happens if your query accidentally creates a loop where someone flies from Delhi to Mumbai, and then Mumbai back to Delhi? Does your query handle that?"My Response: I pointed to the WHERE r1.origin <> r2.destination clause I had included. I explained that this explicit filter ensures that the final destination cannot be the same as the starting point, effectively killing any circular, two-leg loops. The interviewer nodded and said, "Good catch. What if there could be multiple halts?" I wrapped up the round by explaining that for $N$ halts, we'd pivot this strategy into a Recursive Common Table Expression (CTE) to dynamically track path depth. Round 2: Product Sense & Case StudyThe SetupThis round was conversational but highly unstructured. The interviewer skipped introductions and went straight into a macro product issue faced by social commerce platforms.The Question: "Let’s look at Meesho. Suppose you look at the executive dashboard and notice that the number of completed orders has been steadily dropping month-on-month. You are the analytics lead. Walk me through exactly what you do."The Interviewer Interaction & Troubleshooting WalkthroughMy Initial Clarification: I started by defining the scope. I asked, "Is this a sudden, sharp drop from last month, or a gradual decline over 3–4 months? And is it affecting both the app and the website?" The interviewer responded, "It’s a gradual, steady decline over the last quarter, across the entire platform."How I Structured the Analysis: I told the interviewer I would break the investigation down into two buckets: Internal Metrics (things we broke or changed) and External Factors (things changing in the market).The Live Back-and-Forth Discussion:Phase 1: Digging into Internal MetricsI told the interviewer I wanted to check the user conversion funnel first: Acquisition $\rightarrow$ Product Search $\rightarrow$ Cart Add $\rightarrow$ Checkout. I hypothesized that if App Downloads were steady but Orders were down, the leak was inside the app.Interviewer Pushback: "Let's say search traffic and cart adds are completely normal. Users are putting things in their carts at the exact same rate as last year. What do you check next?"My Real-Time Pivot: "If cart-adds are steady but orders are dropping, that points directly to a Checkout Funnel failure. I told them I would look at two specific things: First, technical metrics (payment gateway failure rates or UPI drop-offs). Second, operational changes—specifically, if Meesho recently altered its shipping fees, tax displays, or estimated delivery timelines at the final checkout screen, causing high cart abandonment."Phase 2: Transitioning to External FactorsThe interviewer then asked, "What if checkout data looks perfectly clean? No bugs, no fee changes. What's your next move?"My Response: I explained that if our internal machine is running smoothly, the macro environment is shifting. I stated I would investigate Seasonality (comparing this quarter against the same quarter last year to rule out a post-festive slump) and Competitive Poaching.Specific Example I Used: I brought up Shopsy and Flipkart. I explained that if competitors launched aggressive discount campaigns or zero-delivery-fee incentives during these specific months, our price-sensitive user base would naturally shift their buying behavior over to them.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Meesho
Write a query to display the top three users by downloads each day
| Question | |
|---|---|
| Scrambled Tickets | |
| Identifying User Sessions | |
| Target Indices | |
| Ride-Sharing App Schema | |
| Upsell Carousel | |
| Duplicate Product Names | |
| Evaluating Revenue Decline | |
| Parking Application System Design | |
| Empty Neighborhoods | |
| 2nd Highest Salary | |
| Customer Orders | |
| Button AB Test | |
| Rolling Bank Transactions | |
| 500 Cards | |
| Comments Histogram | |
| Experiment Validity | |
| Jars and Coins | |
| Closest SAT Scores | |
| Subscription Overlap | |
| Longest Streak Users | |
| Bagging vs Boosting | |
| Month Over Month | |
| Top Three Salaries | |
| Prime to N | |
| Paired Products | |
| Upsell Transactions | |
| Monthly Customer Report | |
| P-value to a Layman | |
| Hurdles In Data Projects |
Synthesized from candidate reports. Individual experiences may vary.
The process appears to start with a quick resume walk-through before the technical rounds. In the shared experience, the interviewer used this opening to confirm the candidate’s background and then moved directly into the first problem.
This round focused on live SQL coding in a shared editor. The candidate was asked to solve a route-optimization problem using a self-join, handle edge cases like loops, and discuss how the approach would extend to multiple halts with a recursive CTE.
The next round was a conversational analytics case centered on a declining completed-orders metric on Meesho’s executive dashboard. The interviewer pushed the candidate to diagnose the issue step by step, covering funnel analysis, checkout failures, operational changes, seasonality, and competitor pressure.
After the two rounds, the candidate received an offer. No additional onsite, hiring manager, or cross-functional rounds were mentioned in the experience.