Swiggy Analytics Engineer Interview Questions (2026)

1. 1Problem Solving Screen45 minMedium

   One or two medium DSA problems in a shared editor, judged on working code and complexity analysis.

2. 2Problem Solving / DSA Round 255 minHard

   Harder algorithmic round covering trees, graphs, or DP, often with a follow-up that adds a real-world constraint.

3. 3Design Round (LLD/HLD)60 minHard

   LLD machine-coding of a module (e.g. a splitwise-style ledger or rate limiter) for SDE-1/2, or HLD of a delivery-scale system for SDE-3 and above.

4. 4Data / Analytics Round50 minMedium

   SQL on order and delivery datasets plus a metrics case such as diagnosing a drop in Instamart conversion or designing an experiment.

5. 5Hiring Manager Round50 minMedium

   Deep project walkthrough plus situational behavioral questions on ownership, customer focus, and handling conflicting priorities.

6. 6HR Round30 minEasy

   Offer discussion covering compensation structure, ESOPs, notice period, and team allocation.

1. Q1

   Design an A/B test for a new Food Delivery ranking or recommendation change. Define hypothesis, primary metric, guardrails, randomization unit, and launch decision rule

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Context: Swiggy wants to balance demand, restaurant supply, delivery speed, and margin.

   How to answer: A strong answer would define a clear, testable hypothesis, such as 'The new ranking algorithm will increase conversion rate of search results.' The primary metric should directly reflect the hypothesis, like 'Orders per unique user' or 'Conversion rate from search/recommendation view to order.' Guardrail metrics are crucial to ensure no negative side effects, such as 'Average order value' or 'Delivery partner acceptance rate.' The randomization unit should be carefully chosen, typically 'User ID' for personalized experiences, and the launch decision rule should combine statistical significance on the primary metric with satisfactory performance on guardrails over a predefined test duration.

2. Q2

   For Instamart, should randomization happen at customer, session, device, restaurant, or city level? Explain the tradeoffs

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Consider cross-device behavior, interference, marketplace effects, and operational feasibility.

   How to answer: Randomization for Instamart should primarily happen at the customer level to ensure consistent user experience and accurate measurement of user-centric metrics like conversion rate, retention, and average order value. Randomizing at the session or device level risks a single user seeing multiple variants, leading to contamination and biased results. While restaurant or city level randomization might be considered for specific experiments (e.g., supply-side changes, localized features), it introduces higher variance and makes it harder to detect smaller effects, requiring significantly larger sample sizes or more complex analysis to account for network effects.

3. Q3

   Choose primary and guardrail metrics for a Swiggy One experiment aimed at improving order conversion rate. What metrics would prevent a harmful launch?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Include user experience, partner health, revenue, reliability, and long-term retention considerations.

   How to answer: For a Swiggy One experiment targeting order conversion, the primary metric should be 'Orders per User' or 'Conversion Rate (from impression to order completion)' for Swiggy One users. Guardrail metrics are crucial to prevent negative impacts. Key guardrails would include 'Average Order Value (AOV)', 'Delivery Partner Earnings per Order', 'Customer Retention Rate (for Swiggy One)', and 'Complaint Rate (related to order quality/delivery)'. These guardrails ensure the experiment doesn't cannibalize revenue, harm delivery partner livelihoods, or degrade overall customer experience and loyalty.

4. Q4

   During a Genie experiment, the treatment/control split is 52/48 instead of 50/50. How would you diagnose sample ratio mismatch?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Assume assignment logs, exposure logs, and eligibility filters may disagree.

   How to answer: To diagnose sample ratio mismatch (SRM), I would first verify the data source and extraction logic for any obvious errors. Next, I would perform a chi-square goodness-of-fit test to statistically confirm if the observed 52/48 split significantly deviates from the expected 50/50. If SRM is confirmed, I would investigate potential causes such as incorrect randomization unit definition (e.g., user vs. session), implementation bugs in the assignment logic, or issues with data logging and ETL processes leading to incomplete or biased data capture. Finally, I would check for pre-experiment differences in key metrics between the groups to rule out existing imbalances.

5. Q5

   The Restaurant Ads experiment is trending positive after two days. A PM wants to stop early and launch. How do you handle peeking and sequential testing?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Discuss pre-specified stopping rules, alpha spending, business urgency, and risk.

   How to answer: Explain that peeking early invalidates statistical significance and inflates Type I error rates, leading to false positives. Discuss the importance of pre-determining sample size and experiment duration based on MDE, power, and significance level. Propose methods to address PM pressure, such as explaining the statistical risks, showing confidence intervals, or suggesting a 'holdout' or 'staged rollout' approach if early positive trends are very strong and risk is low. Emphasize the need to adhere to the pre-defined experiment plan to maintain scientific rigor and avoid launching features that might not truly be positive.

6. Q6

   A new Delivery Partner App feature shows a large week-1 lift in order conversion rate, but the effect fades by week 4. What could explain this and how would you design the test duration?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Discuss novelty, learning effects, seasonality, and durable impact.

   How to answer: The fading effect suggests a novelty effect or a change in user behavior that isn't sustainable long-term. Initial lift could be due to increased engagement with a new UI/UX, but users might revert to old habits or find the feature less useful over time. It's also possible the initial lift was driven by a specific user segment that quickly adopted the feature, while others didn't, or that external factors confounded the initial week's results. Test duration should account for user learning curves, habit formation, and business cycles, typically 2-4 weeks for short-term metrics, but longer (4-8+ weeks) for habit-forming features or those impacting long-term value.

7. Q7

   In a marketplace-like Food Delivery feature, treatment users may affect control users. How would network effects or interference bias the experiment?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Examples include restaurant supply, content inventory, delivery capacity, or pricing pressure.

   How to answer: Network effects in a food delivery marketplace can lead to interference, where the treatment group's actions impact the control group, violating the Stable Unit Treatment Value Assumption (SUTVA). This typically manifests as 'spillover effects' or 'contamination,' biasing the observed treatment effect. If treatment users (e.g., those with a new delivery algorithm) reduce overall delivery times, control users might also benefit indirectly, leading to an underestimation of the true treatment effect. Conversely, if treatment users strain resources (e.g., limited delivery partners), control users might experience worse service, leading to an overestimation or misattribution of the effect. Recognizing this bias is crucial for valid experiment interpretation and deciding on appropriate mitigation strategies.

8. Q8

   order conversion rate is a low-frequency event for Instamart. How would you set up an experiment with enough power without waiting too long?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Discuss proxy metrics, variance reduction, larger samples, longer windows, and risk of metric gaming.

   How to answer: To address low-frequency events like Instamart order conversion, consider using a longer experiment duration if feasible, or increasing the sample size by expanding the user pool exposed to the experiment. Alternatively, shift the primary metric to a higher-frequency proxy metric that correlates strongly with order conversion, such as 'add-to-cart rate' or 'view-product-details rate'. For very low-frequency events, consider using a 'sequential testing' approach to stop the experiment early if a significant effect is observed, or a 'switchback' (A/B/A/B) test for continuous evaluation in a production environment.

9. Q9

   Design a geo or city-level experiment for Swiggy One. When is this better than user-level randomization, and what are the analytical downsides?

   MediumStatistics & Experimentation RoundA/B TestingSwiggy-specific

   Context: Use matched markets, pre-period balancing, spillover checks, and fewer experimental units.

   How to answer: A geo/city-level experiment for Swiggy One would involve randomizing entire cities or geographic regions to either a control group (no Swiggy One) or a treatment group (Swiggy One available). This approach is superior to user-level randomization when there's a high risk of 'spillover effects' – where the treatment experienced by one user influences the behavior of another user not in the treatment group, such as through word-of-mouth or competitive responses. The primary analytical downsides include reduced statistical power due to fewer experimental units (cities vs. users), increased sensitivity to imbalanced city characteristics, and longer experiment durations to observe significant effects.

10. Q10

    The Genie experiment lifts order conversion rate overall, but only for new users and only in one meal_slot. How would you evaluate heterogeneous treatment effects?

    HardStatistics & Experimentation RoundA/B TestingSwiggy-specific

    Context: Balance pre-planned segments with exploratory slicing and multiple testing risk.

    How to answer: A strong candidate would first acknowledge the overall positive lift but immediately highlight the need for segmentation by user type (new vs. existing) and meal_slot. They would propose using interaction terms in a regression model (e.g., OLS or logistic regression for conversion) to formally test for heterogeneous treatment effects (HTE). This involves creating interaction variables like `treatment * new_user` and `treatment * meal_slot_X` and assessing their statistical significance. Finally, they would discuss the implications for rollout strategy, recommending a targeted launch to the identified segments rather than a full-scale rollout.

11. Q11

    Treatment improves order conversion rate but worsens delivery SLA breach rate for Restaurant Ads. Walk through a launch recommendation

    HardStatistics & Experimentation RoundA/B TestingSwiggy-specific

    Context: Make a decision under conflicting metrics and quantify tradeoffs for stakeholders.

    How to answer: A strong recommendation would involve a phased rollout, starting with a small percentage of users to monitor the trade-off more closely. Analyze the user segments most affected by the SLA breach and those benefiting most from conversion improvement to understand the impact distribution. Quantify the monetary value of the conversion uplift versus the cost of SLA breaches (e.g., refunds, customer churn) to determine the net business impact. Propose mitigation strategies for the SLA breach, such as adjusting ad targeting, optimizing delivery logistics for treatment users, or refining the ad display logic to reduce operational strain, before a full launch.

12. Q12

    How would you design ramp-up, holdback, and post-launch monitoring for a successful Delivery Partner App A/B test?

    HardStatistics & Experimentation RoundA/B TestingSwiggy-specific

    Context: Include ramp stages, persistent holdback, alert thresholds, rollback criteria, and owner accountability.

    How to answer: For ramp-up, I'd start with a small percentage (e.g., 1-5%) of Delivery Partners, monitoring key operational metrics like app crashes, login failures, and order acceptance rates in real-time. Holdback involves reserving a small, representative percentage of the eligible user base (e.g., 1-2%) who will never receive the new feature, serving as a long-term control for potential novelty effects or unforeseen negative impacts. Post-launch monitoring requires continuous tracking of core business KPIs (e.g., delivery time, partner earnings, cancellations) and A/B test metrics, setting up automated alerts for significant deviations, and establishing a clear rollback plan.

13. Q13

    Midway through the Food Delivery test, tracking for Swiggy One changed. How would you decide whether the experiment results are still usable?

    HardStatistics & Experimentation RoundA/B TestingSwiggy-specific

    Context: Compare instrumentation versions, affected traffic share, raw logs, and sensitivity analyses.

    How to answer: A strong candidate would first identify the potential impact of the tracking change on Swiggy One metrics, specifically if it affects the control and treatment groups disproportionately (i.e., a 'differential bias'). They would propose analyzing the pre- and post-change trends for Swiggy One metrics in both groups, looking for a significant divergence post-change. If the change was implemented uniformly across all users and groups, it might introduce noise but not necessarily invalidate the experiment's directional findings for the primary metric, assuming the primary metric is not Swiggy One related. The decision hinges on whether the change introduced a systematic bias between the groups for the key metrics of the Food Delivery test.

14. Q14

    Two overlapping experiments on Instamart both affect contribution margin per order. How would you detect and manage interaction effects?

    HardStatistics & Experimentation RoundA/B TestingSwiggy-specific

    Context: Discuss experiment registry, factorial design, exclusion rules, and interaction terms.

    How to answer: A strong candidate would first emphasize pre-experiment design considerations like sequential testing or mutual exclusivity where possible. If unavoidable, they would propose statistical methods for detection, such as including an interaction term in a regression model (e.g., ANCOVA) with experiment assignments as independent variables and contribution margin as the dependent variable. They would also discuss segmenting the data by the intersection of the two experiment groups (e.g., A1B1, A1B0, A0B1, A0B0) to observe differential effects. Management strategies would include prioritizing one experiment, running a multi-factorial experiment if resources allow, or acknowledging the interaction and interpreting results with caution, focusing on the combined impact.

15. Q15

    Swiggy's Food Delivery revenue suddenly drops 10% week over week. Structure a business case to diagnose the issue and identify the most likely drivers

    MediumProduct Analytics & Business CaseBusiness CasesSwiggy-specific

    Context: Consider traffic, conversion, pricing, mix, supply/inventory, outages, marketing, and seasonality.

    How to answer: A strong business case would begin by segmenting the revenue drop by key dimensions like geography (city/zone), customer type (new/existing), restaurant type (cuisine/chain), and order characteristics (time of day, average order value). Next, identify if the drop is due to fewer orders or lower average order value (AOV), and then deep dive into the contributing factors for each. This involves analyzing user behavior funnels (impressions to order completion), restaurant supply changes, competitor activity, and internal operational issues (app bugs, delivery partner availability). Finally, prioritize potential drivers based on data impact and ease of investigation, proposing specific data points to validate hypotheses.

Practice these with instant AI feedback in a live mock interview → Start a Swiggy Analytics Engineer mock

Prepare coding/SQL and analytical cases; show product/data sense; quantify impact

Indicative Analytics Engineer pay in India: ~₹9–40 LPA (role-level range, not a Swiggy-specific figure).

Other roles at Swiggy

Analytics Engineer interviews at other companies