At Uber, the driver-facing ecosystem is one of the most complex, dynamic, and high-stakes environments in the technology world. As a Data Scientist focusing on Uber Drivers, you sit at the intersection of marketplace economics, behavioral science, and large-scale machine learning. Your primary mission is to optimize the driver experience, ensure marketplace liquidity, and build intelligent algorithms that balance driver supply with rider demand.
This role is critical because the driver side of a two-sided marketplace is highly sensitive to external variables, from local events to macroeconomic trends. You will work on sophisticated systems that influence driver onboarding, incentive structures (such as surges and quests), routing efficiency, and churn prevention. The decisions you make directly affect the livelihoods of millions of drivers globally and dictate the operational success of Uber's core business.
Whether you are modeling driver lifetime value, designing algorithms to predict ETAs, or diagnosing why driver cancellations spiked in a specific city, your work will require a rare combination of deep statistical rigor and sharp business intuition. You will not just query data; you will design the rules of the marketplace.
Recruiter Screen
reportedData Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.
What to demonstrate
- Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
- Whether you name what you have not done instead of stretching to cover every line of the posting
- Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage
How to prepare
- Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
- Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
- Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live
Technical Screening
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
Virtual Onsite Loop
reportedA day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.
What to demonstrate
- Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
- Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
- Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method
How to prepare
- Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
- Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
- Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
- Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times
Behavioral Bar Raiser
reportedBehavioural answers from data candidates get audited in a way that answers from other roles do not. When you say a model lifted retention, the next question is the denominator, the window, and how you knew the lift was not seasonal. So attach the measurement to each claim while you tell it: what the metric was before, over what period, and against what comparison. Numbers with no baseline read as rounded-up memory, and one unsupported figure tends to make the rest of the story sound rehearsed.
What to demonstrate
- Whether each impact number arrives with a baseline, a window and a comparison, or as a bare percentage
- Whether you can name the method that attributed the effect to your work (an experiment, a staged rollout, a seasonal control) or concede the link was correlational
- Whether the magnitudes stay internally consistent when the interviewer multiplies them against the scale you described earlier
How to prepare
- For each story, write the impact line as metric, value before, value after, window, and how attribution was established. Any line missing two of those five is a follow-up you will answer badly.
- Re-derive one headline number from the source table rather than the deck that reported it. Resume numbers drift upward across retellings.
- Decide in advance which figures you cannot share, and prepare the ratio or relative change you can give instead, so a confidentiality limit does not read as evasion.
7 candidate reports. Individual accounts describe a particular role and hiring cycle.
Uber Drivers Software Engineer interview: recursive strings and trees
I had two separate interviews built around DSA problems. The first was a recursion-based string-manipulation question. The second moved to trees and asked for a tree coding solution. Both interviews added follow-ups after the main question, so finishing the initial problem was not the end of it. Those extensions raised the difficulty and made the rounds feel more demanding than the opening prompt…
Read full experienceUber Drivers Software Engineer interview: five coding interviews and non-selection
I went through essentially the full process and wasn't selected. It took almost a month, which felt reasonably quick to me despite how challenging it was. There were five coding interviews. I don't have many details about the individual questions, but the number of coding rounds made the process feel intense and more selective than I'd expected. After the "not selected" result, I was left with th…
Read full experienceUber Drivers Data Scientist interview: framing consumer fraud risk
The first round was about risk. I completed one SQL task and then answered a question about a confusion matrix. The follow-up on consumer fraud risk was what threw me. When I explained the risks as I saw them, they did not seem impressed, and that feedback came across quite directly. I did not move to later stages. It felt as though the bar was not only technical correctness. How I framed fraud r…
Read full experienceUber Drivers Account Executive interview: aptitude and phone screen
I had a direct process that began with a recruiter-style check. The early screening asked about my client-facing work and how I had handled vendor relationships, including relationships with different alcohol vendors. An aptitude-style step followed, then a phone interview focused on my experience and gave me more information about what the role would involve. These early rounds felt average in d…
Read full experienceUber Drivers Data Scientist interview: SQL bottleneck in a timed test
My first step was a 60-minute test with 17 questions: two medium SQL questions and 15 aptitude questions. The aptitude questions felt easier, as though I could get through most of them in under half the time. I spent longer on the SQL section and could not fully solve everything. By the end, I was hoping that the partial progress would be enough to move forward, but I did not get an interview aft…
Read full experiencePracHub editorial advice for the preparation topics above.
Treating abandoned requests as missing rather than censored
Consumers who give up before matching are censored observations, so the mean time-to-match computed over matched requests understates true waiting and improves mechanically whenever abandonment rises. A change that makes people quit sooner will look like a latency win. Use survival methods with abandonment as the censoring event, or never report time-to-match without reporting abandonment next to it.
Conditioning the analysis on completed orders
Wait-time distributions, price elasticities and rating models fit only on completed orders are conditioned on an outcome that the intervention itself changes. The requests that never matched, or that the consumer abandoned, are the population a liquidity fix targets, so excluding them biases every estimate toward the status quo and can flip the sign of a price elasticity. Any query starting FROM fct_order is already inside this trap; start from fct_request and left join.
Reading experiment results before checking the arm split
Compare observed arm counts against the intended allocation ratio, not an assumed even split, and set the alarm far below the conventional 0.05: at 0.05 roughly one healthy experiment in twenty trips it, which is why sample-ratio checks usually run at p < 0.001 or stricter. The test's power scales with sample size, so it misses a real diversion on a small experiment and fires on an imbalance too small to move the estimate on a very large one. A flag means go find the assignment or logging fault before reading any outcome, not report a mismatch.
Reporting a mean for a heavy-tailed metric without saying what it hides
For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How would you write an algorithm to find the expected value of driver …
How would you write an algorithm to find the expected value of driver earnings given a variable probability distribution of trip distances and surge multipliers?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Translate the result into the decision it informs, in one plain sentence.
- Say what the estimate is of, and over what population it generalises.
Follow-up
- Which assumption here is most likely to be violated in practice?
- How would you explain this result to someone who does not know statistics?
Simulate dispatch cascades and the censoring of wait time
A request is offered to one provider at a time. Each offer resolves 12 seconds after it is sent, and each provider accepts independently with probability 0.55. After six declines the request is marked no_supply. Independently, the consumer abandons at time A drawn from an Exponential distribution with mean 90 seconds; abandonment before a pending offer resolves ends the request unmatched. Simulate 200,000 requests and report: the share matched, the mean time-to-match over matched requests, and the mean over requests that would have matched with abandonment switched off. Give a Monte Carlo standard error for the share.
Approach
- Vectorise the cascade: draw K with np.random.default_rng().geometric(0.55), mark K > 6 as no_supply, and draw A = rng.exponential(90) independently; the match condition is K <= 6 and A > 12*K. Looping request by request is the difference between two seconds and two minutes of runtime.
- Compute both means on the same draws so the comparison is paired and the difference is not itself a Monte Carlo artefact.
- Recognise the structure driving the answer: abandonment censors long cascades harder than short ones, so conditioning on matched requests is not a neutral filter, it is a filter correlated with the quantity being measured.
- Quote the share to three decimals only: the standard error of a proportion is sqrt(p(1-p)/n), roughly 0.0009 at n = 200,000, so further digits are noise.
- Check against the closed form P(match) = sum over k of 0.45^(k-1) * 0.55 * exp(-12k/90) for k = 1..6; a simulation with no analytical check is an untested function.
Worked solution 30 min
- k = rng.geometric(0.55, size=200_000); a = rng.exponential(90.0, size=200_000); t = 12.0 * k.
- supplied = k <= 6; matched = supplied & (a > t).
- share = matched.mean(); se = sqrt(share * (1 - share) / 200_000).
- observed_mean = t[matched].mean(); latent_mean = t[supplied].mean().
- Compare share against the closed form 0.7911 and print the gap in standard errors.
Follow-up
- A change ships that makes consumers abandon sooner. What happens to your reported mean time-to-match, and how would you report latency so that this cannot look like a win?
- How would you estimate the same quantity from production data, where you never observe the latent match time of an abandoned request?
Sessionise a provider heartbeat stream into supply sessions
You are given pings: provider_id, market_id, event_at_utc, status in ('idle','en_route','engaged','offline'), one row per app heartbeat, nominally every 30 seconds but with gaps. Reconstruct the supply-session table. A session starts at the first non-offline ping and ends at an explicit offline ping, at a market change, or when the gap to the next ping exceeds 10 minutes. Produce session_id, provider_id, market_id, online_at, offline_at, online_seconds, engaged_seconds, en_route_seconds, idle_seconds and end_reason, with the three state components summing to online_seconds exactly in integer seconds.
Approach
- Sort by (provider_id, event_at_utc), then build a new_session boolean: first ping of a provider, previous status equals 'offline', market_id changed, or the gap from the previous ping exceeds 600 seconds. A cumsum over that boolean is the session key, and it removes any need for a per-provider Python loop.
- Attribute duration to intervals, not to pings: each ping owns the seconds until the next ping inside the same session, and the final ping owns a capped 30 seconds. Because the state seconds are the intervals themselves, they sum to online_seconds by construction rather than by a correction step.
- Encode the three terminations distinctly. Gap timeout ends at last_ping + 30s with end_reason 'app_background_timeout'; an explicit offline ping ends at that ping with 'manual_offline'; a session with no terminating event before the data ends is 'session_still_open' with offline_at NaT.
- On a market change, close the old session at its last ping in the old market and open the new one at the first ping in the new market; the seconds in between belong to neither session, and the output should say so rather than quietly padding one side.
- Aggregate with a single groupby on the session key, pivoting the per-interval state into the three second columns, then assert the sum identity and that consecutive sessions for one provider never overlap.
Follow-up
- A provider is engaged on a 40-minute order and the app backgrounds mid-order. What does your 10-minute rule do to that session, and what does it do to utilisation?
- Utilisation divides engaged by online. Which of your three end_reason cases biases it most, and in which direction?
Given a table of daily driver earnings, write a query to calculate the…
Given a table of daily driver earnings, write a query to calculate the rolling 7-day average of active driver supply by city.
Approach
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
Write a Python function from scratch to calculate the cumulative sum o…
Write a Python function from scratch to calculate the cumulative sum of an array without using Pandas or built-in cumulative functions.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Write a query to identify drivers who have completed more than 50 trip…
Write a query to identify drivers who have completed more than 50 trips in their first week, joining driver onboarding tables with trip dispatch logs.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Collapse supply sessions into shifts with a ten-minute gap rule
fct_supply_session has one row per provider per continuous online segment: session_id, provider_id, market_id, online_at_utc, offline_at_utc (NULL while the session is open), online_seconds, engaged_seconds, end_reason. Collapse rows into shifts. Consecutive sessions for the same provider and market belong to one shift when the next online_at_utc falls within 10 minutes of the latest end seen so far in that shift. Treat an open session as ending at the window end. Return provider_id, market_id, shift_start, shift_end, session_count, and summed online_seconds and engaged_seconds.
Approach
- COALESCE offline_at_utc to the window end before anything else, so an open session participates in the chain instead of producing NULL comparisons that evaluate to UNKNOWN and quietly start a new shift.
- Compute the running end with MAX(session_end) OVER (PARTITION BY provider_id, market_id ORDER BY online_at_utc ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING). LAG(offline_at_utc) is the reflexive answer and it is wrong whenever one session sits inside the span of an earlier longer one, because the immediately preceding row ends earlier than the running maximum.
- Flag a new shift when the running end is NULL or online_at_utc is later than running_end plus interval '10 minutes'.
- Number shifts with SUM(new_shift_flag) OVER (PARTITION BY provider_id, market_id ORDER BY online_at_utc ROWS UNBOUNDED PRECEDING). The cumulative count of starts is constant inside an island, which is what makes it usable as a group key.
- Group by (provider_id, market_id, shift_id) and take MIN(online_at_utc), MAX(session_end), COUNT(*) and the two second-sums. Sum the stored seconds columns rather than recomputing from timestamps, so the totals stay consistent with how the durations were measured.
Worked solution 30 min
- Pull one busy provider's sessions ordered by online_at_utc and read the timestamps by eye until you find a row whose predecessor ends earlier than the running maximum.
- Add the running-max and flag columns and inspect them beside the raw timestamps for that provider before aggregating anything.
- Add the cumulative sum and confirm shift_id is constant across each island you identified by eye.
- Aggregate, then compare total session_count in the output to the input row count.
Follow-up
- How does the answer change if the same provider can be online in two markets with overlapping times?
- You now want shift-level utilisation. Why is SUM(engaged_seconds)/SUM(online_seconds) over the shift correct while an average of per-session ratios is not?
Rider cancellations suddenly spiked by 12% in San Francisco over the w…
Rider cancellations suddenly spiked by 12% in San Francisco over the weekend. Walk me through the exact metrics you would pull and your structured approach to finding the root cause.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you define and measure the success of a new feature designed…
How would you define and measure the success of a new feature designed to prevent fraudulent ride cancellations by drivers?
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
Walk me through how you would model and optimize the trade-offs betwee…
Walk me through how you would model and optimize the trade-offs between driver wait times and rider pickup times (ETAs) during peak commute hours.
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you measure and control for driver cannibalization when launchi…
How do you measure and control for driver cannibalization when launching a new premium vehicle tier in a highly saturated city?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
How would you design an experiment to test a new driver destination fe…
How would you design an experiment to test a new driver destination feature when standard user-level A/B testing is biased by network effects?
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
Choose one health metric for a single market week
A market lead wants one number on the weekly review slide for one market. They propose gross bookings. Last week in that market a 12.5% surge-driven price rise coincided with completed orders falling 4%, so gross bookings rose 8%. Using fct_request, fct_order and dim_user, propose a replacement. Give numerator, denominator, window and exclusions explicitly, name one guardrail, and say in one sentence why you rejected gross bookings and why you rejected raw signups. Do not propose a dashboard; propose one primary number and one guardrail.
Approach
- Name the decision the number serves before defining it: this slide decides whether the market gets more incentive budget next week, so the number has to move only when the market actually clears more orders at a defensible cost.
- Show arithmetically why gross bookings fails: 1.125 x 0.96 = 1.08, so an 8% rise is consistent with 4% fewer completed orders. A level metric that is price times volume cannot separate the two, and price is a lever the team controls.
- Define the replacement fully: completed orders per active consumer over the trailing 28 days, numerator = count of fct_order rows with order_status = 'completed' and completed_at_utc in the window for that market_id, denominator = distinct consumer_id in fct_request with requested_at_utc in the same window and the same market_id. State the exclusion for the documented 10-second mis-tap requests so the denominator matches the fill-rate definition.
- Attach the guardrail that blocks the cheap route: contribution margin per completed order, because the fastest way to raise orders per active consumer is a credit that never pays back, and the margin metric prices exactly that.
- Flag the known weakness out loud: this rate falls when acquisition succeeds, because new cohorts transact less than tenured ones, so report the denominator next to the rate and read frequency by tenure bucket before calling a decline an engagement problem.
Worked solution 20 min
- Write the decision the slide supports in one line, then list three candidate numbers: gross bookings, completed orders, completed orders per active consumer.
- Test each candidate against the given week: multiply 1.125 by 0.96 and confirm gross bookings rose 8% while the market served fewer orders.
- Write the surviving candidate as numerator, denominator, window and exclusions, naming the exact tables and columns.
- Write the guardrail with the same rigour, sourcing refunds, chargebacks and processing fees from fct_money_movement attributed to the order's completion month.
- Write one sentence beginning 'this breaks if' for the primary metric and confirm the guardrail blocks that route.
Follow-up
- The market runs a two-week promotion. Which of your two numbers moves first, and what would you expect the second to do in week three?
- If you could add exactly one more number to the slide, is it a supply-side metric or a consumer-side one, and what does it buy you?
- How would you handle a week where one large zone was closed for an event?
Median time-to-match improved while pre-match abandonment rose
Median time-to-match, computed as matched_at_utc minus requested_at_utc over fct_request rows where matched_at_utc IS NOT NULL, improved from 74 to 61 seconds in one market. Over the same days, request_status = 'abandoned_pre_match' rose from 6% to 11% of requests created. A dispatch change shipped that week. Using fct_request alone, say whether waiting genuinely improved, give an estimator that is not conditioned on matching, and state the assumption that estimator needs.
Approach
- Name the conditioning first. The statistic is computed only on requests that matched, and abandonment removes the longest waits from that subset before they can be observed, so anything that makes consumers quit sooner shortens the measured distribution mechanically.
- Replace the conditional mean with a fixed-horizon rate at the request grain: the share of all requests created in the window that matched within T seconds, T being the market's SLA. It is unconditional, it moves only when matching actually improves, and it is the SLA fill rate the market already reports.
- If the full curve is needed, estimate the cumulative incidence of matching with abandonment as a competing event, not Kaplan-Meier with abandonment as censoring. KM requires the censoring mechanism to be independent of the match hazard, and here people abandon precisely because they are still waiting, so KM would overstate the improvement.
- Distinguish the two stories that both fit the data: the match hazard rose (dispatch got faster), or consumers got less patient, for instance because a new screen surfaces a worse quote. Look at the abandonment hazard by elapsed second and at the quoted_eta_seconds distribution before and after. Worse quotes with an unchanged wait means people are quitting on the quote.
- Report matched requests per 100 created next to any latency number, every time, and state whether the two movements net to more or fewer matches. That net figure is what the decision depends on.
Follow-up
- Give the two-sentence version for a product review, without using the word censoring.
- Abandonment is flat but 'no_supply' expiries rose instead. Does that change your estimator?
- How would you power a switchback on the fixed-horizon metric given market-hour variance?
Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Breadth pass: query fluency
- Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
- For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
- Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.
Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Breadth pass: statistics and inference
- Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
- Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
- Rewrite the two weakest answers the following morning from memory in full sentences.
Deliverable: Ten graded answers with an honest count of exact hits.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Breadth pass: modelling
- Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
- Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
- Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.
Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Breadth pass: product judgement
- Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
- For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
- Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.
Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Depth, first area
- Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
- Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
- Re-solve the two you failed the same evening with notes closed.
Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.
Practice prompt ↗Practice prompt ↗06Depth, second area, and the seam between them
- Repeat the depth protocol on the second-ranked area with the same six-problem structure.
- Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
- Solve your own combined problem end to end and note where the handoff between the two areas cost you time.
Deliverable: One combined problem, solved end to end, with the handoff failure written down.
Practice prompt ↗Practice prompt ↗07Integration and re-measurement
- Re-run the six prompts from day one under the same clock and compare both correctness and time.
- Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
- Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.
Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.
Describe an analysis you got wrong after a decision shipped
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
Approach
- Choose an error with a real mechanism you can draw in one sentence, not a communication miss; the question is probing whether you understand how your own work fails, and a 'they misunderstood my chart' story answers a different question.
- State the blast radius honestly and numerically: days live, decisions taken, dollars or headcount moved. Vagueness here reads as an error you never actually measured.
- Say how it surfaced, including the unflattering version if someone else found it. Claiming self-detection on an error that a stakeholder caught is the fastest way to lose the room.
- Separate the mechanism from the conditions that let it survive: a wrong formula is one bug, but no reconciliation check and no second reader are the reasons it lived for weeks.
- End on a structural control, not an intention. 'I will be more careful' is not a control; a test that fails the job when two computations of the same metric disagree is.
Follow-up
- How soon after you knew did the decision-maker know, and who told them?
- Has the control you added caught anything since, and how would you know if it had silently stopped working?
- What class of error would that control still miss?
Explain a switchback confidence interval to a non-technical executive
A switchback test of a dispatch-radius change ran 1,152 market-hour blocks across six markets. SLA fill rate moved +1.8 percentage points, 95% interval [-0.4, +4.0], variance clustered at the block. Those markets serve about 250,000 eligible requests a week at 88% fill and 93% completion. An executive with no statistics background wants a ship-or-wait answer inside a five-minute update. Deliverable: the two-minute spoken explanation, your recommendation, and the single condition that would change it. You may not use the words significant, p-value, or confidence interval.
Approach
- Open with the decision and the recommendation, then justify; an executive who hears the caveat first stops listening before the ask arrives.
- Translate both interval bounds into the unit the executive already manages: eligible requests times percentage points times completion rate gives weekly completed orders, so the range becomes 'between about 1,000 fewer and about 9,300 more completed orders a week, best single guess about 4,200 more'.
- Say plainly what the range does and does not rule out: it does not rule out a small loss, and it is wide because the test has 1,152 effective units, not 250,000 consumers. Block-level randomisation is the reason the sample is small, and it is the reason the number is trustworthy at market level.
- Price the two errors against each other: a reversible dispatch parameter with a bounded downside is cheap to ship and cheap to revert, so the decision rule is not 'is the effect proven' but 'is the worst case affordable and detectable'.
- End with the one condition that flips you: name the monitoring metric (provider utilisation and idle time, since a wider radius can raise fill by burning provider hours) and the threshold at which you revert.
Follow-up
- How many more weeks of blocks would it take to halve the width of that range, and is that worth the delay?
- The executive asks 'so is it real or not' - what do you say without reaching for statistical vocabulary?
- What would you monitor post-ship that the experiment itself could not measure?
Disagree with a product lead about the randomisation unit
A product lead wants to ship a faster-dispatch change on the strength of a consumer-level A/B: 400,000 consumers, +6.1% completed orders per consumer, p below 0.001. You believe the design measures the wrong quantity, because treated consumers take the idle providers control consumers would otherwise have matched with. The lead's counter is that the sample is enormous and the p-value tiny. Deliverable: the argument you make including the direction of the bias, the evidence you can produce from existing data in two days, and the design you propose instead with its calendar cost.
Approach
- Concede the internal comparison and dispute the estimand: the test cleanly estimates a between-consumer contrast under a shared supply pool, which is not the market-level effect of shipping to everyone. Sample size does not touch this, because the bias does not shrink with n.
- State the direction and the mechanism: control consumers are degraded by treatment, so the contrast is inflated. The inflation is largest when idle supply is scarce, which is precisely the condition the feature is meant to help, so the test is most wrong where the decision matters most.
- Produce the fingerprint from data already in hand: split the measured lift by market-hour provider utilisation decile. Interference predicts the lift rises with utilisation; a genuine effect that does not steal supply does not have to. Pair it with control-arm fill rate against a pre-period baseline in high-utilisation hours, stating the precondition that this comparison is only informative if the pre-period is seasonally comparable or an untested market is available.
- Propose the switchback concretely: block length longer than a typical order duration so carryover does not leak across the boundary, a burn-in discarded after each switch, randomisation at the market-hour, and variance clustered at the block.
- Price the design honestly in calendar time so the lead can trade it off, and offer an interim: ship to one market with the rest held out, which is slower to read but not biased in the same direction.
Follow-up
- If the lift does not rise with utilisation, what does that tell you, and would you then ship?
- How do you choose block length when order durations have a long right tail?
- What variance reduction still works under interference, and what does it assume?
- 01
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
- 02
A switchback test of a dispatch-radius change ran 1,152 market-hour blocks across six markets. SLA fill rate moved +1.8 percentage points, 95% interval [-0.4, +4.0], variance clustered at the block. Those markets serve about 250,000 eligible requests a week at 88% fill and 93% completion. An executive with no statistics background wants a ship-or-wait answer inside a five-minute update. Deliverable: the two-minute spoken explanation, your recommendation, and the single condition that would change it. You may not use the words significant, p-value, or confidence interval.
- 03
A product lead wants to ship a faster-dispatch change on the strength of a consumer-level A/B: 400,000 consumers, +6.1% completed orders per consumer, p below 0.001. You believe the design measures the wrong quantity, because treated consumers take the idle providers control consumers would otherwise have matched with. The lead's counter is that the sample is enormous and the p-value tiny. Deliverable: the argument you make including the direction of the bias, the evidence you can produce from existing data in two days, and the design you propose instead with its calendar cost.
Is this an official Uber Drivers interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Uber Drivers. Rounds and questions reflect what candidates have reported, not a process Uber Drivers has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Data Scientist interview loop for Uber Drivers?
A: The interview process is highly rigorous and generally rated as difficult. The technical screening is a strict filter for coding speed and accuracy, while the onsite loop tests your ability to handle highly complex, ambiguous marketplace problems under pressure.
PracHub interview research ↗How much preparation time is typically recommended?
A: Most successful candidates spend 3 to 4 weeks preparing. This time should be split between practicing advanced SQL and Python coding, studying spatial-temporal experimentation methodologies, and practicing structured root cause analysis cases.
PracHub interview research ↗What is the working style and culture like within the Uber Drivers team?
A: The team is fast-paced, highly data-driven, and collaborative. There is a strong emphasis on ownership and business impact; successful data scientists are proactive, comfortable with ambiguity, and eager to solve real-world physical logistics challenges.
PracHub interview research ↗What is the typical timeline from the initial recruiter screen to an offer?
A: The entire process usually takes between 3 to 5 weeks, depending on candidate availability and scheduling. Uber's recruiting team is highly organized and typically provides feedback within a few days of each round.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22