Uber Business Analyst 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, testable hypothesis, such as 'The new ranking algorithm will increase completed trips per user without negatively impacting driver earnings or user experience.' The primary metric should directly reflect the business goal, like 'Trips per user' or 'Gross Bookings per user.' Guardrail metrics are crucial for detecting unintended negative side effects, including 'Driver acceptance rate,' 'Cancellation rate,' and 'Customer support contacts.' The randomization unit for a ranking change should typically be the 'User ID' to ensure a consistent experience. The launch decision rule should involve statistical significance on the primary metric, ensuring guardrails are not negatively impacted, and considering practical significance.

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 network effects. However, depending on the feature being tested (e.g., UI changes vs. pricing algorithms), session or device level might be considered for technical simplicity or to avoid user confusion within a single interaction. Driver-level randomization is suitable if the feature directly impacts drivers, while city-level is reserved for large-scale infrastructure changes or market-specific experiments where spillover effects are significant and unavoidable. The key is to choose the smallest unit that prevents contamination and accurately measures the intended impact.

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: The primary metric should directly measure the experiment's goal: 'Request-to-Complete Rate' (completed orders / requested orders). Guardrail metrics are crucial to ensure no negative side effects. Key guardrails would include 'Average Delivery Time', 'Driver Acceptance Rate', 'Customer Satisfaction Score' (CSAT), and 'Gross Bookings' to prevent regressions in service quality, driver engagement, customer experience, or overall revenue. A harmful launch would be prevented if any guardrail metric shows a statistically significant negative impact, even if the primary metric improves.

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: First, verify the SRM is statistically significant using a chi-square test. Then, investigate the randomization logic for potential bugs, such as incorrect bucketing based on user IDs or device properties, or issues with the random number generator. Next, examine the experiment's entry and exit points, looking for differences in how users enter the experiment (e.g., specific app versions, geographic regions, or timing of app usage) or how they might drop out. Finally, analyze pre-experiment metrics and user characteristics for both groups to identify any inherent biases that might have been introduced.

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: A strong candidate would first explain that stopping an A/B test early due to positive trends (peeking) inflates the Type I error rate, leading to false positives. They would then discuss sequential testing methods like Always Valid Inference (AVI) or using an O'Brien-Fleming boundary to allow for early stopping while controlling the Family-Wise Error Rate (FWER). The candidate should emphasize the importance of pre-specifying stopping rules and alpha levels to maintain statistical validity. Finally, they would recommend against early stopping without a pre-defined sequential testing framework, suggesting to let the experiment run its course or re-evaluate the sample size calculation if the effect is truly much larger than anticipated.

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 before returning to baseline behavior, or a learning curve where the feature's benefits diminish as users find workarounds or the novelty wears off. Another explanation could be seasonality or external factors coinciding with the initial launch. To design the test duration, I would recommend at least 4-6 weeks to capture a full business cycle and account for novelty effects, ensuring the observed lift is sustainable. I would also segment users by tenure or usage frequency to analyze if the effect varies across different user groups.

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, specifically negative interference in a marketplace like Uber Rides, would bias the experiment by causing the control group's performance to degrade due to the treatment group's actions. This leads to an overestimation of the treatment effect, as the control group's baseline is artificially lowered. For example, if treatment users get preferential matching or pricing, control users might experience longer wait times or fewer available drivers, making the treatment appear more effective than it truly is. This bias invalidates direct comparisons between treatment and control, requiring more sophisticated experimental designs.

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 address the low-frequency nature of request-to-complete for Uber Reserve, consider using a surrogate metric that is a leading indicator and has higher frequency, such as 'request rate' or 'trip creation rate' for Reserve. Alternatively, expand the experiment's scope to include a broader user base or a longer duration, if feasible and aligned with business goals. For power calculations, focus on the surrogate metric's expected lift and baseline, ensuring the sample size and MDE are appropriately set. If direct measurement is critical, consider a sequential testing approach to stop early if significant effects are observed, or a larger MDE if a smaller effect is not critical to detect.

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 geographic regions into control and treatment groups for a new feature (e.g., a new delivery fee structure or restaurant promotion). This approach is superior to user-level randomization when there's a high risk of network effects, such as changes in driver supply or restaurant demand that impact all users in an area. However, it suffers from lower statistical power due to fewer experimental units (cities vs. users), making it harder to detect small effects and requiring longer experiment durations or larger effect sizes. Analytical downsides also include potential for selection bias if cities aren't truly comparable and increased sensitivity to outliers.

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: A strong candidate would first acknowledge the overall positive lift but immediately highlight the importance of understanding the heterogeneous treatment effects (HTE) to avoid misinterpreting the experiment's true impact and to inform targeted product strategies. They would propose segmenting the data by user tenure (new vs. existing) and then by `rider_cohort` within the new user segment to isolate the specific positive effect. The evaluation would involve statistical significance testing (e.g., t-tests or z-tests) for the request-to-complete rate within these specific segments, potentially using CUPED for variance reduction. Finally, they would discuss the business implications of these findings, such as rolling out the feature only to the affected segment or investigating why other segments did not respond similarly.

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 a phased rollout, starting with a deep dive into the 'why' behind the conflicting metrics. Analyze user segments (e.g., frequent vs. infrequent airport travelers, trip distance) and geographic regions to identify where the treatment performs well versus poorly. Propose a targeted launch to segments or regions where all key metrics show improvement or where the request-to-complete gain significantly outweighs the ETA/cancellation decline, alongside further iteration on the treatment for problematic segments. The recommendation should also include a monitoring plan for key metrics post-launch and a clear definition of success metrics for a full rollout.

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: A strong candidate would outline ramp-up as a phased rollout (e.g., 1%, 5%, 20%, 100%) to monitor key metrics for anomalies before full deployment, especially critical for Uber for Business due to potential large-scale impact. Holdback would involve reserving a small, representative control group (e.g., 1-5%) from the experiment for an extended period post-launch to assess long-term effects and novelty decay. Post-launch monitoring requires establishing a dashboard with pre-defined success metrics (e.g., adoption, engagement, churn, revenue) and guardrail metrics (e.g., latency, error rates, support tickets) with clear alert thresholds, ensuring continuous oversight and rapid response to unexpected issues.

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: A strong candidate would first identify the potential for 'contamination' or 'confounding' due to the Uber Eats tracking change. They would propose analyzing the impact of the change on both the control and treatment groups, specifically looking for a differential effect on key metrics (e.g., ride volume, driver availability, user engagement) related to the Rides test. If the impact is uniform across both groups, the experiment might still be usable, albeit with increased noise. If the impact is differential, or if the change fundamentally alters user behavior in a way that invalidates the original hypothesis, the experiment results are likely unusable and a restart would be necessary.

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-experiment design to minimize overlap, but given it exists, they'd suggest analyzing interaction effects by segmenting data based on exposure to both experiments versus only one. They would propose statistical methods like regression analysis with interaction terms to quantify the effect and its significance. Mitigation strategies would include pausing one experiment, re-designing, or running a factorial experiment if feasible. Finally, they'd discuss the business implications of detected interactions on overall product strategy and future experiment design.

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 business case would start by segmenting the 10% revenue drop by key dimensions like geography (city, region), user type (new vs. existing, rider vs. driver), product type (UberX, Uber Black, etc.), and time of day/week to pinpoint where the drop is most concentrated. Next, it would formulate hypotheses across supply (driver availability, incentives), demand (pricing changes, competitor actions, seasonality, app issues), and operational factors (payment processing, fraud). Finally, it would outline data needed to test these hypotheses, prioritizing those with the highest potential impact and ease of investigation, leading to actionable recommendations.

Practice these with instant AI feedback in a live mock interview → Start a Uber Business Analyst mock

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

Indicative Business Analyst pay in India: ~₹7–26 LPA (role-level range, not a Uber-specific figure).

Other roles at Uber

Business Analyst interviews at other companies