Uber Data Scientist interview typically runs 5 rounds: recruiter screen, 2 technical screens, and 3 final interviews. It usually takes about 4-8 weeks and is notably structured, with a bar raiser in the final loop.
$126K
Avg. Base Comp
$311K
Avg. Total Comp
4-5
Typical Rounds
2-4 weeks
Process Length
We've seen Uber consistently favor candidates who can reason through messy marketplace tradeoffs, not just recite textbook methods. Multiple candidates reported questions that pushed beyond standard A/B testing into synthetic control, difference-in-differences, interrupted time series, and especially switchback testing. That tells us the bar here is less about naming the right framework and more about knowing why a framework fits a rides, delivery, or pricing problem. When candidates stumbled, it was usually because they stayed too abstract or couldn't defend the assumptions behind their design.
A recurring theme is that Uber cares deeply about metrics that map to marketplace health. Candidates were asked to define success for ETA changes, batching, surge pricing, driver assignment, and service expansion, and the strongest answers tied primary metrics to operational outcomes like match rate, completed rides, or order volume, then layered in guardrails like cancellations, complaints, retention, and driver earnings. We've also seen interviewers probe failure modes hard: what happens when an experiment looks off, how to verify results, and how to handle endogeneity when pricing and demand move together. That emphasis shows up again in the econometrics-style questions around price elasticity and surge pricing.
The non-obvious separator is clarity under ambiguity. Several candidates noted that the coding itself was not the hardest part; the harder part was framing the problem, stating constraints, and explaining tradeoffs without getting lost. Even behavioral feedback points in the same direction: the bar raiser expects stories that reflect Uber's values in concrete business decisions, not polished leadership language. In practice, our candidates who did best sounded like people who had actually thought about how a marketplace behaves when incentives, supply, and customer experience all interact.
Synthetized from 6 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Uber process.
The process for me started with a recruiter reaching out, and then I went through two technical screening rounds before the final loop. The first screen mixed coding and a case study, and the second was similar in spirit, with a more interactive coding question that felt LeetCode-like but not exactly a standard whiteboard problem. After that, I had three interviews in the final round: one with the hiring manager, one with a bar raiser, and one technical round focused on experimentation. The overall process was pretty structured, and most interviewers were friendly and clear, though one round felt a bit less crisp when I asked clarifying questions.
The technical questions were a mix of Python/SQL manipulation, a simple Python function, and case-style product thinking. In the early screen, I was asked about causal inference concepts like when to use synthetic control, A/B testing, and difference-in-differences. Another case centered on Uber service expansion and metric formation for data science and analytics, and there was also an optimization-style problem around Uber Eats order or driver assignment, where the emphasis was on defining objectives and constraints rather than just jumping to code. In the final technical round, I got a vague A/B testing question about how I would test whether showing driver ETA one minute less actually changes behavior or outcomes. The behavioral parts were standard but still important, with resume walkthroughs and questions about conflict with a manager and working with multiple stakeholders.
Difficulty-wise, this was more demanding than a typical coding screen because it combined algorithmic problem-solving with product sense, experimentation design, and real-world case reasoning. The coding itself was not the hardest part; the tougher part was being able to frame the problem well, explain tradeoffs, and defend the metrics or experimental design under time pressure. I did not get an offer, and the process felt fairly selective overall.
If you’re preparing, I’d focus on causal inference basics, especially synthetic control versus A/B testing versus DiD, and practice explaining how you’d set up experiments for product changes like ETA display. It also helps to rehearse optimization-style case studies where you clearly state objectives, constraints, and what a better algorithm would actually change.
Prep tip from this candidate
Focus on causal inference tradeoffs like synthetic control vs A/B testing vs DiD, because that came up directly. Also practice explaining optimization cases by stating the objective, constraints, and how you’d evaluate whether a better algorithm actually changes the product outcome.
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 Uber
Write a query to select the top 3 departments with at least ten employees and rank them according to the percentage of their employees making over 100K in salary.
| Question | |
|---|---|
| Download Facts | |
| Experiment Validity | |
| User Experience Percentage | |
| Distance Traveled | |
| Weighted Keys | |
| Third Purchase | |
| Bank Fraud Model | |
| Maximum Profit | |
| Encoding Categorical Features | |
| Sum to N | |
| P-value to a Layman | |
| Christmas Dinner Ingredient Optimization | |
| Random Forest Explanation | |
| Random Weighted Driver | |
| Type-ahead Search | |
| Hurdles In Data Projects | |
| Uber User Journey | |
| Sort Strings | |
| Cancellation Fees | |
| Dijkstra implementation | |
| Assumptions of Linear Regression | |
| Testing Price Increase | |
| Dice Rolls From Continuous Uniform | |
| Drawing Balls From Bin | |
| Type I and II Errors | |
| Data Preparation for Imbalanced Data | |
| Max Width | |
| Uniform Car Maker | |
| MLE vs MAP |
Synthesized from candidate reports. Individual experiences may vary.
The process typically starts with an HR or recruiter conversation about your background, resume, and overall fit for the Data Scientist role. In some cases, Uber also shares interview prep materials ahead of time and uses this stage to set expectations for the technical loop.
This first technical screen combines SQL/Python execution with analytics and experimentation thinking. Candidates have reported questions on SQL patterns like joins, window functions, lag/lead, and CTEs, along with basic Python tasks and an applied case study around product metrics or feature launch design.
The second screen is similar in spirit but often more interactive and case-driven. It can include coding, causal inference, A/B testing, confidence intervals, and product or marketplace reasoning, such as how to evaluate a feature change, define metrics, or think through an optimization problem.
The final loop usually includes a hiring manager interview, a bar raiser behavioral round, and one or more technical or business-focused interviews. Topics reported include experimentation failure modes, experimentation design, experimentation-focused metrics, and econometrics or marketplace cases such as surge pricing, price elasticity, Uber Eats batching, or driver ETA changes.
After the final loop, Uber makes a decision based on technical depth, product sense, and behavioral alignment with company values. Candidates reported hearing back relatively quickly in some cases, with outcomes ranging from offer to rejection after panel review.