Uber Analytics Engineer Interview Questions (2026)

1. 1Recruiter Screen30 minEasy

   Role targeting, level calibration and process expectations.

2. 2Technical Phone Screen60 minMedium

   One or two medium DSA problems (CodeSignal or live) with emphasis on correct, runnable code and edge cases.

3. 3Onsite Coding I60 minHard

   Practical problem such as building a rate limiter or an in-memory index, judged on working code and API cleanliness.

4. 4Onsite Coding II60 minHard

   Algorithmic problem often with a geospatial or streaming flavor, pushed to optimal complexity.

5. 5System Design60 minHard

   Design a real-time marketplace system (dispatch, ETA, surge) with hard follow-ups on scale, geo-sharding and failure modes.

6. 6Behavioral / Hiring Manager Round45 minMedium

   STAR stories mapped to Uber's cultural norms: ownership, bold bets, customer obsession and conflict handling.

1. Q1

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

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

   Context: Context: Uber wants to match rider demand and driver supply while controlling wait times and cancellations.

   How to answer: A strong answer will define a clear hypothesis, such as 'The new ranking algorithm will increase completed rides per user without negatively impacting driver earnings or user retention.' The primary metric should directly reflect the business goal, like 'completed rides per unique user' or 'gross bookings per unique user.' Guardrail metrics are crucial and include 'driver acceptance rate,' 'driver earnings per hour,' 'user cancellation rate,' and 'user retention (D7/D30).' The randomization unit should be 'user-ID' to ensure a consistent experience, and the launch decision rule will involve statistically significant positive movement in the primary metric, no significant negative movement in guardrails, and a pre-defined minimum effect size for launch.

2. Q2

   For Uber Reserve, should randomization happen at rider, session, device, driver, or city level? Explain the tradeoffs

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: Randomization for Uber Reserve should primarily happen at the rider level to ensure independent observations and minimize contamination, as the product is rider-centric. Session or device level randomization could be considered for specific UI/UX tests but risks contamination if a rider uses multiple devices/sessions. Driver-level randomization is inappropriate as Reserve is a rider-initiated feature. City-level randomization is suitable for macro-level policy changes or market-wide feature rollouts, but requires many cities and risks higher variance.

3. Q3

   Choose primary and guardrail metrics for a Uber Eats experiment aimed at improving request-to-complete rate. What metrics would prevent a harmful launch?

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: A strong candidate would identify 'request-to-complete rate' (or a direct proxy like 'successful order rate') as the primary metric, as it directly reflects the experiment's goal. For guardrail metrics, they should consider both user experience and business health. Key guardrails would include 'average delivery time' and 'customer cancellation rate' to ensure service quality isn't degraded, and 'average order value' or 'total gross bookings' to confirm business revenue isn't negatively impacted. They should also mention 'driver utilization/earnings' as a crucial stakeholder metric.

4. Q4

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

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: A strong candidate would first identify the need to check for proper randomization. This involves verifying the assignment mechanism (e.g., hash function, bucketing logic) and ensuring no external factors interfered. They would then statistically test the observed split against the expected 50/50 using a chi-squared test or z-test for proportions, looking for a statistically significant deviation. Finally, they would investigate potential root causes like implementation bugs, user ID changes, or pre-existing differences in user populations.

5. Q5

   The Airport Trips 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 TestingUber-specific

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

   How to answer: Explain that peeking early can inflate Type I error rates, leading to false positives and launching features that are not truly beneficial. Discuss the need for pre-defined stopping rules, either based on a fixed duration or sequential testing methodologies like O'Brien-Fleming or Group Sequential Designs. Emphasize communicating the risks of early stopping to the PM, advocating for patience to reach statistical significance at the planned duration, or using methods that account for multiple comparisons. Highlight the importance of pre-registration of the experiment plan to maintain scientific rigor.

6. Q6

   A new Uber for Business feature shows a large week-1 lift in request-to-complete rate, but the effect fades by week 4. What could explain this and how would you design the test duration?

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: The fading effect could be due to novelty effect, where users initially engage more with a new feature, but their behavior normalizes over time. Another explanation could be seasonality or external factors coinciding with the initial launch. To design the test duration, I would consider the typical user lifecycle and the time it takes for user behavior to stabilize, aiming for at least 4-6 weeks to capture long-term effects and account for potential novelty. I would also analyze historical data for similar feature launches to inform the expected stabilization period.

7. Q7

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

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: Network effects in a marketplace A/B test mean that the treatment group's behavior can directly influence the control group's experience, leading to interference. This typically biases the experiment results towards the null hypothesis, underestimating the true treatment effect if the effect is positive (e.g., increased supply benefits everyone). Conversely, a negative treatment effect (e.g., reduced supply) could appear less severe or even beneficial to the control group, overestimating the true negative impact. The bias arises because the control group is not experiencing a true 'status quo' but rather a modified status quo influenced by the treatment.

8. Q8

   request-to-complete rate is a low-frequency event for Uber Reserve. How would you set up an experiment with enough power without waiting too long?

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: To power an experiment for a low-frequency event like Uber Reserve's request-to-complete rate, one should first identify suitable proxy metrics that are higher frequency and highly correlated with the ultimate goal. These could include 'request rate', 'driver acceptance rate', or 'trip start rate' for Reserve trips. Additionally, consider increasing the experiment's sample size significantly, potentially by expanding the eligible user base or extending the experiment duration if absolutely necessary and within time constraints. Utilizing a more sensitive experimental design, such as CUPED or A/B/n testing with multiple variations, can also help detect smaller effects with less data.

9. Q9

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

   MediumStatistics & Experimentation RoundA/B TestingUber-specific

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

   How to answer: A geo-level experiment for Uber Eats involves randomizing entire cities or predefined geographic zones (e.g., neighborhoods) to either the treatment or control group. This approach is superior to user-level randomization when there's a high risk of network effects or contamination, such as changes in pricing, delivery fees, or restaurant incentives that impact the local marketplace. However, it introduces analytical challenges including reduced statistical power due to fewer experimental units, increased variance, and potential for confounding variables if cities are not well-matched or if there are significant pre-existing differences.

10. Q10

    The Driver App experiment lifts request-to-complete rate overall, but only for new users and only in one rider_cohort. How would you evaluate heterogeneous treatment effects?

    HardStatistics & Experimentation RoundA/B TestingUber-specific

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

    How to answer: To evaluate heterogeneous treatment effects (HTE), first define the subgroups of interest (new vs. existing users, specific rider_cohorts) and formulate hypotheses for each. Then, perform subgroup analysis by segmenting the data and calculating the treatment effect (lift in request-to-complete rate) and its statistical significance within each subgroup. Employ interaction terms in regression models (e.g., OLS or logistic regression) to formally test for HTE, including terms like `treatment * new_user_flag` and `treatment * rider_cohort_indicator`. Finally, consider advanced methods like Causal Forests or Uplift Modeling for more granular, data-driven discovery of HTE, especially if the initial subgroup definitions are insufficient.

11. Q11

    Treatment improves request-to-complete rate but worsens ETA and cancellation rate for Airport Trips. Walk through a launch recommendation

    HardStatistics & Experimentation RoundA/B TestingUber-specific

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

    How to answer: A strong recommendation would involve acknowledging the trade-offs and proposing a phased rollout or a segmented launch. The candidate should suggest further investigation into the root causes of the worsened ETA and cancellation rates, potentially through qualitative analysis or deeper dive into trip characteristics. A key step would be to quantify the monetary impact of the improved request-to-complete rate versus the negative impact of increased cancellations and ETAs, possibly using a North Star metric like net revenue or driver utilization. Finally, the recommendation should include a clear decision framework for proceeding, such as A/B testing the treatment only on non-airport trips or implementing a dynamic pricing model to mitigate negative effects.

12. Q12

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

    HardStatistics & Experimentation RoundA/B TestingUber-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 eligible Uber for Business (U4B) accounts, monitoring key operational metrics (e.g., error rates, latency, payment failures) and primary business metrics (e.g., trip volume, spend) for anomalies. Holdback involves reserving a small, stable percentage (e.g., 1-2%) of the original population that never sees the experiment, serving as a long-term control to detect novelty effects or sustained negative impacts. Post-launch monitoring requires ongoing dashboards tracking operational health, key performance indicators (KPIs), and guardrail metrics, with automated alerts for significant deviations, ensuring the feature continues to perform as expected and doesn't introduce regressions over time.

13. Q13

    Midway through the Rides test, tracking for Uber Eats changed. How would you decide whether the experiment results are still usable?

    HardStatistics & Experimentation RoundA/B TestingUber-specific

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

    How to answer: First, identify the exact nature and scope of the Uber Eats tracking change and its potential impact on the Rides test metrics. Analyze the timing of the change relative to the experiment's start and the observed metric trends in both control and treatment groups before and after the change. Compare key metrics (e.g., rides completed, revenue per ride, user engagement) for significant shifts or divergences between groups post-change. If the change introduced a systemic bias or increased variance that disproportionately affected one group or the primary metric, the results are likely unusable; otherwise, consider sensitivity analysis or segmenting data.

14. Q14

    Two overlapping experiments on Uber Reserve both affect net revenue per trip. How would you detect and manage interaction effects?

    HardStatistics & Experimentation RoundA/B TestingUber-specific

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

    How to answer: A strong candidate would first emphasize the importance of pre-analysis and experimental design to minimize interaction effects, such as sequential rollout or segmentation. To detect interaction effects post-experiment, they would propose analyzing the combined treatment groups (e.g., A1B1) against individual treatments (A1B0, A0B1) and the control (A0B0) using a multi-factor ANOVA or regression model with interaction terms. If interactions are detected, they would discuss strategies like re-running experiments sequentially, segmenting the user base, or adjusting the interpretation of results to account for the combined impact rather than individual effects.

15. Q15

    Uber's Rides 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 CasesUber-specific

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

    How to answer: A strong candidate would structure their diagnosis by first defining the problem (10% WoW revenue drop in Rides) and establishing a clear hypothesis-driven approach. They would then propose a data-driven investigation, starting with high-level metrics (trips, average fare, cancellation rate, driver supply) and segmenting the data by key dimensions like geography, time of day, user type (new vs. existing), and service tier. Finally, they would outline potential root causes based on these investigations, such as changes in demand, supply, pricing, or product issues, and suggest next steps for validation and mitigation.

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

Strong DSA and scalable system design; prepare analytical/behavioral stories

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

Other roles at Uber

Analytics Engineer interviews at other companies