Uber Data Scientist Interview: Questions, Experience & Prep (2026)

Uber is well known for putting analytical rigour at the centre of its hiring. Data Scientists here work directly on pricing strategy, driver supply, demand forecasting, and ride-experience experimentation. If you enjoy a role where your model output visibly changes what a rider pays or how long a driver waits, Uber is a strong fit.

As of July 2026, knok jobradar shows 8 open Data Scientist roles at Uber across India. Candidates report the process typically involves a recruiter screen, a technical round covering SQL and statistics, possibly a take-home or live coding exercise, and a final interview loop. Exact stages vary by team, so confirm the format with your recruiter after the first call.

Current salary bands for Data Scientists in India (knok data):

Uber commonly sits at the higher end of these bands. Check Glassdoor and levels.fyi for publicly reported Uber-specific figures before you negotiate.

These questions are drawn from candidate reports and the types of problems Uber's teams publicly describe. They are representative, not an official list.

1. Walk me through an A/B test you designed end-to-end. What was your primary metric, and why did you choose it?
2. Trip completions in one city drop sharply overnight. How do you diagnose the cause?
3. A product manager wants to launch surge pricing in a new city. How would you measure whether it is working?
4. Explain the difference between precision and recall in plain terms. When would you accept low precision to get high recall?
5. How would you detect fraudulent rides where a driver spoofs their GPS location?
6. Your model scores well in offline evaluation but performs poorly after deployment. What do you investigate first?
7. How do you handle severe class imbalance in a fraud detection or cancellation-prediction model?
8. Write a SQL query to find the top three highest-earning drivers per city over the last 30 days.
9. An experiment shows a statistically significant lift on your primary metric but a dip on a guardrail metric. What do you recommend?
10. How would you build a model to predict which drivers are likely to churn in the next 30 days?
11. Tell me about a time you delivered an insight that a stakeholder pushed back on. How did you handle it?
12. Estimate the number of Uber rides completed in Bangalore on a typical weekday. Walk me through your assumptions.

Q: Walk me through an A/B test you designed end-to-end.

*Situation:* My team at a food-delivery startup noticed that checkout drop-off was high when users saw the total cost for the first time at the payment step.

*Task:* I was asked to test whether showing a cost breakdown earlier in the flow would reduce drop-off without hurting order volume.

*Action:* I defined the primary metric as checkout completion rate, added order value and cancellation rate as guardrail metrics, and calculated the required sample size using standard power-analysis methods. I randomised at the user level to avoid cross-group contamination, ran the experiment for several weeks to capture full weekly usage cycles, and built a live dashboard so the product team could monitor guardrail metrics daily.

*Result:* The variant showed a clear improvement in checkout completion. Order value stayed flat, ruling out the concern that we were just pushing lower-value orders through. The feature shipped to all users.

---

Q: Your model performs well offline but poorly in production. What do you investigate?

*Situation:* A driver-cancellation prediction model I built had strong offline performance, but the operations team reported too many false positives in the first week of rollout.

*Task:* I needed to find the root cause and fix it without retraining from scratch.

*Action:* I first checked whether the production data distribution matched the training data. I found that one feature, completed trips over a rolling window, was being computed differently in the real-time pipeline versus the training pipeline because of a timezone bug. I also checked for target leakage and confirmed there was none. Fixing the feature computation brought offline and online metrics into alignment.

*Result:* After the pipeline fix, the false-positive rate matched offline expectations. I also set up automated distribution-drift checks so this class of bug would surface faster in future.

---

Q: Tell me about a time a stakeholder pushed back on your analysis.

*Situation:* I ran an experiment testing a new driver-incentive structure. Results showed no statistically significant improvement in driver retention, but the ops lead was convinced the new structure was better because 'it felt right' from their field experience.

*Task:* I had to communicate the result honestly while keeping the relationship intact and not dismissing legitimate operational knowledge.

*Action:* I walked through the methodology step by step, showed confidence intervals rather than just the point estimate, and acknowledged that the experiment may have been underpowered for a small sub-segment of drivers the ops lead cared about. I proposed a targeted follow-up experiment on that sub-segment.

*Result:* The stakeholder agreed to pause the broad rollout and run the targeted test instead. That experiment did show a positive signal for the sub-segment, which led to a more precise incentive policy.

For metrics and product questions, use a goal-first structure. Start by clarifying what Uber is trying to maximise or protect. Then name the primary metric, a couple of guardrail metrics, and state the trade-offs between them. Uber interviewers value candidates who proactively name guardrail metrics without being prompted.

For diagnosis questions (something broke, find why), use a layered elimination approach.

1. Rule out data or logging issues first. These are the most common culprit.
2. Check for external factors: seasonality, a city event, a competitor promotion.
3. Look at internal changes: a code deploy, a pricing change, a UI update.
4. Segment the data by city, device, driver cohort, or ride type to localise the problem.

For SQL questions, think aloud before you write. Mention window functions (RANK, ROW_NUMBER) and CTEs upfront. Uber questions often involve aggregations over a time window grouped by a geographic or categorical dimension.

For behavioral questions, use the STAR structure (Situation, Task, Action, Result) and keep it concise. Lead with what you did, not what the team did. Uber interviewers report valuing clarity and self-awareness over lengthy storytelling.

Candidates report that Uber Data Scientist interviewers look for three qualities above all else.

Business grounding, not just technical skill. You should explain why a metric matters to a business outcome, not just how to compute it. Saying 'I chose retention rate because it directly ties to lifetime value' lands better than 'I chose it because it was available in our data warehouse.'

Structured thinking under pressure. When given an open-ended problem, interviewers want to see you decompose it clearly before jumping to a solution. Taking a moment to write out your structure signals organisation. Candidates who rush to a model or formula before defining the problem tend to score lower.

Honest reasoning about uncertainty. Uber's experimentation culture means interviewers are comfortable with 'I am not sure, but here is how I would find out.' Candidates who bluff or over-claim tend to get caught when the interviewer probes one level deeper.

A secondary signal is concise communication. Uber teams move quickly. If you take a long time to answer a straightforward question, that can signal a mismatch with the work pace.

Week 1: Strengthen SQL and statistics.
Practice window functions, time-windowed aggregations, and self-joins. Revisit hypothesis testing: p-values, confidence intervals, statistical power, and multiple-testing corrections. You do not need to memorise every formula, but you should explain the intuition clearly and know when each concept applies.

Week 2: Build product sense for Uber's domain.
Spend time understanding how surge pricing, driver supply prediction, and demand forecasting work at a conceptual level. Uber's publicly available engineering blog content describes real projects in accessible language. Practice estimating ride volumes with a structured breakdown: city population, commuter share, app penetration, and average trips per active user per day.

Week 3: Prepare your STAR stories.
Write out several stories covering: an experiment you designed, a model you built and deployed, a disagreement with a stakeholder, an unexpected insight you found, and a failure you learned from. Practice delivering each story clearly and within a couple of minutes.

Week 4: Mock interviews and self-review.
Do a couple of mock technical screens with a peer who will give honest feedback. Record yourself answering a behavioral question and watch it back. Most candidates find they use filler words or trail off more than they realise. Fix this before the real interview, not during it.

Skipping the clarifying question. Uber interviewers often leave deliberate ambiguity in a problem, for example 'design a metric for driver quality' without specifying what quality means. Candidates who assume and proceed miss the chance to show business judgment.

Naming only a primary metric. Any strong DS candidate should immediately think about guardrail metrics. If you name only one metric for a product launch question, you signal limited experimentation experience.

Weak SQL under observation. Many candidates know SQL well but freeze when someone is watching. Practice writing queries out loud. Talk through what each clause does as you go.

Over-explaining the model, under-explaining the impact. Saying 'I used a gradient-boosting model' is less compelling than 'the model reduced cancellation-related costs by a measurable amount, which I can walk you through.' Lead with impact, then describe the technical approach if asked.

Generic behavioral answers. Answers that could apply to any company suggest you have not reflected seriously on your own experience. Uber interviewers probe for specifics. Be ready to name actual metrics, actual timelines, and actual trade-offs from your own work.

No questions at the end. Candidates who have no questions signal low interest or poor preparation. Prepare a few thoughtful questions about the team's current projects or how they define success.