A Data Scientist at Turo plays a pivotal role in driving the growth and efficiency of the world’s largest peer-to-peer car-sharing marketplace. Operating a two-sided platform presents highly complex, mathematically rich challenges that directly impact host profitability, guest conversion, and overall marketplace health. Data scientists at Turo do not work in isolation; they build the foundational economic and machine learning engines that power millions of real-time decisions daily across the globe.
The team's work spans the entire model lifecycle, from initial research and causal inference to deploying production-ready Python code and monitoring model performance. Key focus areas include dynamic pricing, demand forecasting, supply-demand matching, search optimization, and fraud detection. By translating unstructured, ambiguous business problems into rigorous statistical frameworks, data scientists help optimize the delicate balance between vehicle supply and traveler demand.
For anyone joining Turo, the position offers a rare combination of high-impact product ownership and deep technical complexity. Whether you are optimizing pricing recommendations for over 200,000 vehicles or designing experiments to measure marketplace spillover effects, your models will directly shape the financial outcomes of a global community of hosts and guests.
Phone Screen
reportedWhoever runs this call is usually not a practitioner. They take notes, and a hiring manager skims those notes later, so the real question is whether your work survives being written down by someone outside the field. Test every project sentence against that: could a non-specialist repeat it correctly without knowing what a propensity score is? Carry a plain-language version of each project and one reason you want this particular role that you could not copy onto another application. Vagueness at this stage reads as inexperience, even when the underlying work was genuinely deep.
What to demonstrate
- Whether a non-specialist can restate your projects accurately, since their paraphrase is what reaches the hiring manager
- Whether your reason for wanting the role points at the work itself rather than the company's reputation
- Whether your language signals the level being screened for: what you decided yourself versus what you were handed
How to prepare
- Write a two-sentence, jargon-free version of each major project: the question nobody could answer, and the decision your work changed. Read it to someone outside data and have them repeat it back
- Point your 'why this role' answer at something concrete in the job description or the product surface you would be working on, and keep it to two sentences
- Have two questions ready about measurement: which metric the team is held to, and who acts on an analysis once it lands
Take-Home Case Study
reportedThe clock is part of the test. Three to six hours is not enough to do everything the dataset supports, so the submission mostly reveals how you spend a fixed budget against an open question. A reviewer sees which paths you took and, by absence, which you abandoned. Work that runs out of time inside the analysis ships a thin conclusion, while work that cuts scope early protects the last hour for writing. The most reliable way to lose here is to leave the scoping decision implicit, so it reads as something you missed rather than something you chose.
What to demonstrate
- Whether the scope you settled on is presented as a decision with a reason, rather than left for the reader to infer from what is missing
- Whether the depth of the work is consistent with the stated time budget, instead of several half-finished directions left open
- Whether the closing section reads as something written on purpose rather than assembled from whichever cells survived
How to prepare
- Run a timed rehearsal on a public dataset with a hard stop, holding the final sixty minutes for writing no matter where the analysis has got to
- Before opening the data, list the questions it could plausibly answer, pick one, and keep the discarded ones as a short note on what you did not attempt and why
- Commit a one-line finding after each analysis step so the writeup is assembled from recorded results rather than from memory at midnight
Technical Debrief
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 Loop Interviews
reportedA loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.
What to demonstrate
- Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
- Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
- Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience
How to prepare
- Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
- For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
- Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
Turo Data Scientist Interview Experience — Solid Through ML and Coding, Tripped Up by Business and Stats
Sharing a rejection experience from Turo. The interview process itself was actually pretty good — I could tell that if I'd gotten in, I would have learned a lot. Unfortunately I still got rejected. Round 1 was an HR screen. It was mostly going through my resume, and based on what was on there they'd ask some ML-related questions, like what's the difference between XGBoost and LightGBM. Round 2 wa…
Read full experienceTuro Software Engineer Interview Experience — Four Onsite Rounds, Verbal Offer in Under a Month
Background I got a referral, and as soon as the role opened they scheduled a call directly. (My personal takeaway: right now applying early matters more than being strong.) Timeline: 01/13 Applied 01/15 Recruiter call 01/15 OA 01/28-01/29 Four rounds of virtual onsite 02/06 Verbal offer Interview Experience Recruiter call Simple questions about my background, how long I've been working, what this…
Read full experiencePracHub editorial advice for the preparation topics above.
Pooling across markets with a shifting mix
Aggregate take rate, order frequency and fill rate all move when the market mix moves, because a fast-growing newly launched market has lower prices, lower frequency and different supply density. A company-level metric can decline while every individual market improves, which is Simpson's paradox with a launch calendar attached. Report within-market deltas, or fix the mix by weighting to a reference period, and say which one you did.
Reading incentive impact without a cell-level holdout
A bonus in one hour or one zone pulls provider hours and consumer orders from adjacent hours and zones rather than creating them, so a before-and-after read on the treated cell counts displaced volume as incremental and can show a positive result for a spend that produced nothing. Only a randomised holdout at the same granularity as the incentive, or a comparison against untreated cells that share the demand shock, separates increment from displacement. Always state incremental orders per incentive dollar, never total orders in treated cells.
Generalising beyond the population the sample actually supports
State the frame the sample was drawn from and where it diverges from the population you want to talk about: time window, platform, geography, opt-in. If a group is excluded from the frame, either weight to known margins or narrow the claim rather than quietly extending it.
Reporting a p-value with no effect size or interval
Give the estimated difference with a confidence interval in the units the business cares about, then say whether that whole interval is worth acting on. A p-value only addresses whether you can rule out exactly zero; it says nothing about magnitude.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you model price elasticity of demand in a peer-to-peer marketpl…
How do you model price elasticity of demand in a peer-to-peer marketplace where supply is highly heterogeneous?
Approach
- Set a baseline first, so any model has something honest to beat.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Check what information would not exist at prediction time, and exclude it.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
Explain the inner workings of neural networks, and discuss when you wo…
Explain the inner workings of neural networks, and discuss when you would choose them over simpler tree-based models.
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
Net take and margin per market-month without ledger fan-out
You have orders (order_id, market_id, completed_at_utc, order_status, gross_booking_cents, provider_payout_cents, consumer_incentive_cents, provider_incentive_cents, tip_cents) and ledger (ledger_id, order_id, entry_type in charge, refund, chargeback, incentive, payout, adjustment, processing_fee; amount_cents signed positive into the platform; posted_at_utc; settlement_status). For completed orders, produce a market-month frame with net take, margin before support cost, and the order count. Attribute refunds, chargebacks and processing fees to the order's completion month, not the posting month, and drop ledger rows whose settlement_status is 'pending' or 'failed'.
Approach
- Aggregate the ledger to the order grain before touching orders: filter settlement_status, then pivot entry_type into one summed column each. Merging first and summing after multiplies gross_booking_cents by the number of ledger rows on that order.
- Merge the pivoted ledger onto orders with validate='m:1' so an unexpected duplicate raises instead of silently inflating every total.
- Net take = gross_booking - provider_payout - consumer_incentive - provider_incentive over completed orders only; tips are excluded on both sides because they pass through to the provider and never enter platform revenue.
- Add the signed ledger columns rather than subtracting absolute values: refunds, chargebacks, payouts and processing fees are negative under this convention, so margin = net_take + refund + chargeback + processing_fee. Verify the sign on one known order before trusting the aggregate.
- Group by market_id and completed_at_utc month, never posting month; that is the whole point of the attribution rule, and it is why a month's margin is not final until the chargeback window closes.
- Carry completed_orders in the output so per-order margin can be recomputed downstream without averaging an average.
Worked solution 30 min
- led = ledger[~ledger.settlement_status.isin(['pending','failed'])]; wide = led.pivot_table(index='order_id', columns='entry_type', values='amount_cents', aggfunc='sum', fill_value=0).
- comp = orders[orders.order_status == 'completed']; m = comp.merge(wide, on='order_id', how='left', validate='m:1').fillna({col: 0 for col in wide.columns}).
- net_take = gross_booking_cents - provider_payout_cents - consumer_incentive_cents - provider_incentive_cents.
- margin = net_take + refund + chargeback + processing_fee, using the signed ledger columns directly.
- Group by market_id and completed_at_utc.dt.to_period('M'), summing net_take and margin and counting order_id.
Follow-up
- A chargeback posts two months after completion and changes an already-reported month. How do you publish a metric that is not final, and what lag would you quote?
- Should the denominator be matched orders, completed orders, or completed-and-settled orders? Argue for one and name what it hides.
Write a Python function to perform a rolling average of vehicle daily …
Write a Python function to perform a rolling average of vehicle daily rental prices over a 7-day window, handling missing dates appropriately.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Given a dataset of vehicle search queries and subsequent bookings, wri…
Given a dataset of vehicle search queries and subsequent bookings, write a SQL query to calculate the conversion rate by vehicle category and lead time.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Explain how you would optimize a slow-running PySpark or SQL query whe…
Explain how you would optimize a slow-running PySpark or SQL query when joining a massive search log table with a smaller vehicle attributes table.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Contribution margin per completed order without ledger fan-out
fct_order has order_id, market_id, order_status, completed_at_utc, gross_booking_cents, provider_payout_cents, consumer_incentive_cents, provider_incentive_cents, tip_cents. fct_money_movement has ledger_id, order_id, entry_type, amount_cents (signed, positive into the platform), currency_code, fx_rate_to_usd, posted_at_utc, settlement_status. Per market per completion month, report net take, ledger cost from entry_type IN ('processing_fee','refund','chargeback') with settlement_status NOT IN ('failed','reversed'), and contribution margin per completed order, all in USD cents. Attribute every ledger entry to the order's completion month, not its posting month.
Approach
- Aggregate fct_money_movement to one row per order_id in a CTE before touching fct_order, converting inside the SUM as amount_cents * fx_rate_to_usd. Joining the order table to the ledger first multiplies gross_booking_cents by the number of ledger rows on that order, which is routinely four to eight.
- Exclude entry_type 'charge' and 'payout' from the ledger side. The consumer charge is already gross_booking_cents and the payout is already provider_payout_cents, so including them counts both sides twice with opposite signs and moves the margin by an amount that looks plausible.
- Keep the signs. Entries are positive into the platform, so refunds, chargebacks and processing fees arrive negative. Add the ledger sum to net take rather than subtracting it, or the sign flips twice and costs are booked as revenue.
- Compute net take from the order columns as gross_booking_cents minus provider_payout_cents minus consumer_incentive_cents minus provider_incentive_cents. Exclude tip_cents from both sides because it passes through to the provider.
- Group by market_id and date_trunc('month', completed_at_utc) with order_status = 'completed', then divide by COUNT(*) of those orders. Attributing on completion month rather than posting month is what stops a slow chargeback from flattering the month that earned it.
Worked solution 30 min
- Run SELECT order_id, COUNT(*) FROM fct_money_movement GROUP BY 1 and look at the distribution; the maximum tells you the size of the fan-out you are avoiding.
- Build the per-order ledger CTE and assert it returns exactly one row per order_id present in the ledger.
- LEFT JOIN it onto fct_order so orders with no ledger entries survive with a COALESCE'd zero rather than disappearing.
- Aggregate to market by completion month, divide by the completed order count, and compare that count to an unjoined count over the same filter.
Follow-up
- A chargeback posts 80 days after completion. What does that do to a margin number published 30 days after month end, and how do you present the number so it is not read as final?
- fx_rate_to_usd is the rate at posting time, not at completion. In which markets and at what volatility does that choice change the decision?
Explain the concept of survival analysis and how it might apply to und…
Explain the concept of survival analysis and how it might apply to understanding host retention or vehicle availability patterns.
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
- 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?
- Which segment would you cut first, and what would that rule out?
What quasi-experimental methods would you use to measure the impact of…
What quasi-experimental methods would you use to measure the impact of a product change if a randomized A/B test is not feasible?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
If a host complains that their earnings dropped after adopting our rec…
If a host complains that their earnings dropped after adopting our recommended pricing, how would you investigate the root cause?
Approach
- Clarify what is being asked and what a complete answer would contain.
- State your assumptions explicitly before working the problem.
- Work from the decision backwards to the evidence you would need.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Daily peeking and twelve market cuts inflate false positives
A 14-day consumer-level test was powered for one pre-registered primary metric, first-order activation rate. The team reads a dashboard every morning and intends to stop as soon as p is below 0.05, and separately reads the effect inside each of 12 markets. On day 4 the pooled p-value is 0.04 and two markets look significant. Quantify how much type-I error each of those two practices adds under the null. Then specify the readout protocol you would impose: what is tested, when, at what level, and what may be claimed from the per-market cuts.
Approach
- Price the peeking. Under the null the accumulating z-statistic behaves approximately as a Brownian motion, so repeated fixed-alpha testing at equally spaced looks inflates the false-positive rate well above nominal: about 0.14 at 5 looks and 0.19 at 10 looks against a nominal 0.05. Fourteen daily looks put the rate near 0.2, so the day-4 crossing is the expected behaviour of a null test, not evidence.
- Price the subgroups. With 12 independent market tests at alpha = 0.05, the chance of at least one false positive under the global null is 1 - 0.95^12 = 0.46. Two apparent winners out of 12 is what the null produces routinely.
- Fix the peeking with a method that budgets the alpha in advance: group-sequential boundaries with an alpha-spending function, or anytime-valid confidence sequences. O Brien-Fleming spends almost nothing early, so the final-look critical value is barely above 1.96 and the cost of the option to stop is concentrated at the start; Pocock spends evenly and pays a visible penalty at the end. Confidence sequences are wider at every fixed time, which is the price of the right to stop whenever you like.
- Fix the subgroups by declaring one primary metric on the pooled population as the decision rule. Per-market cuts are exploratory and reported with Benjamini-Hochberg at q = 0.10 for false discovery rate, valid under independence and positive regression dependence, or Holm when family-wise control under arbitrary dependence is needed.
- Report per-market effects partially pooled toward the pooled estimate, because the largest of 12 noisy estimates is biased upward. A market whose raw effect is three times the pooled effect is usually the maximum of noise, not a real heterogeneity finding.
- Write the protocol before the test starts: primary metric, horizon derived from the MDE and baseline variance, boundary, guardrails, and an explicit statement that interim significance on a fixed-horizon test is not a stopping rule.
Worked solution 20 min
- State the repeated-looks inflation for the planned number of looks: about 0.14 at 5 looks, 0.19 at 10, near 0.2 at 14.
- Compute the subgroup family-wise rate: 1 - 0.95^12 = 0.46.
- Choose a boundary: O Brien-Fleming spending if early stopping is genuinely required, otherwise a single look at the pre-registered horizon.
- Specify the exploratory layer: BH at q = 0.10 across the 12 market p-values, plus partial pooling of the per-market point estimates.
- Write the protocol down and attach it to the experiment record so the horizon cannot move when an interim number looks good.
Follow-up
- The pooled effect finishes at p = 0.06 on day 14. Under your protocol, what happens next, and what would you refuse to do?
- How does the required sample size change if you adopt an anytime-valid confidence sequence instead of a fixed horizon?
- One market shows an effect three times the pooled effect. What evidence would make you believe that is real heterogeneity?
A fill-rate step change that no dispatch change caused
SLA fill rate rose 2.3 points on a single day in every market at once and held there. A dispatch radius change shipped that same week, but only in three markets. The metric is requests matched within the market's SLA divided by all requests created, excluding requests abandoned within 10 seconds of creation. Decide whether the step is a real improvement, and give the one plot that distinguishes a definition change from a behaviour change.
Approach
- Start from the simultaneity. Marketplace behaviour does not step in every market on the same minute. A change that lands everywhere at once is a code, config or definition change; a real dispatch change appears only in the three markets that received it, and usually with a ramp.
- Plot the numerator count and the denominator count on the same axis instead of plotting the rate. A definition change normally moves exactly one of them by a level shift, and the 10-second exclusion moves the denominator down while leaving the numerator flat, because a request abandoned inside 10 seconds was never matched and so was never in the numerator.
- Backfill one definition across the whole window; do not difference the two definitions day by day. Old and new differ by the 10-second exclusion, which applies on every day of history, so the two series sit apart throughout the window and their gap dates nothing. The diagnostic is single-definition continuity: recompute the entire window under the new definition, then again under the old one. If each single-definition series runs continuously through the step date while the published series steps, the definition changed that day and history was never restated. If the step survives under a consistently applied definition, the data or the behaviour moved and the definition is not the story.
- The gap between the two definitions is still worth plotting, for its level rather than its timing. It should sit near the historical share of requests abandoned within 10 seconds of creation and stay roughly flat across the window. A gap that itself jumps at the step date means the excluded population changed as well, which is a data change wearing a definition change's clothes.
- Read the SLA source. The threshold is per market, so an edit to the SLA config, or a new market silently inheriting a default, shifts the numerator with a flat denominator, which is the opposite signature.
- Only once the step is explained should you evaluate the dispatch change, and then strictly inside the three treated markets against the untreated ones over the same days, both computed under one definition.
Follow-up
- How do you report a metric whose definition changed mid-quarter without restating history as an improvement?
- What would you require of any future metric change so this is unambiguous on day one?
For a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Most data work is done by groups, so an interviewer has to work out which piece was yours. An answer that runs on 'we' for several minutes gets interrupted with a question about what you personally did, and by then the answer sounds defensive even when it is true. Mark your own contribution as you go, and name the parts that belonged to someone else instead of leaving them ambiguous. Keep a few specifics back as well, like the name of the metric or who actually objected, so a probe can be answered with something you had not already said.
Describe a time you had to deal with highly imbalanced data in a class…
Describe a time you had to deal with highly imbalanced data in a classification project. What techniques did you use, and how did you measure success?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- How did you know the outcome was caused by your change?
Choose between three teams' requests with one analyst week
Three requests arrive the same morning and you have one analyst-week. Pricing wants a fee elasticity refresh for a change scheduled in ten days. Supply wants a churn model for approved providers who never opened a session. Finance wants the monthly contribution-margin restatement that attributes refunds and chargebacks in fct_money_movement to the order's completion month rather than the posting month. Deliverable: your ranking, the criterion behind it, the smallest useful version of each, and what you say to the two teams you rank below first.
Approach
- Rank on decision coupling rather than requester seniority or intrinsic interest: what decision hangs on this, on what date does it become useless, and how expensive is it to reverse if the answer is wrong.
- Notice the dependency before the ranking: the margin restatement changes the denominator of every unit-economics answer, including the elasticity work, so doing it second means redoing part of the first task.
- Unbundle each request into its smallest decision-bearing piece. The restatement is a change to the attribution date in one query, about half a day. The elasticity refresh needs a range and its preconditions, about two days. The churn model is the only item with no date and the longest build.
- Replace the churn model with the descriptive cut that may make it unnecessary: approved-provider time-to-first-session conversion by approval cohort and acquisition_channel, from dim_user provider_approved_at_utc against the first fct_supply_session.online_at_utc, one day. If conversion collapses in one channel or one market, the fix is operational and no model is needed.
- Communicate the ranking in writing where all three can see it, with the reason and the trigger that would reorder it, and give each deprioritised team a smaller concrete deliverable rather than a place in a queue.
Follow-up
- The supply lead escalates to your manager - what do you say, and what do you not say?
- What if the fee change's elasticity cannot be estimated observationally over the range they need?
- Which of the three would you drop entirely if you lost two days to an incident?
Handle a request to re-cut a test after the readout
A four-week consumer-credit test reads flat on completed orders per active consumer and negative on contribution margin per completed order, which was the pre-registered guardrail. The sponsor asks for three re-cuts: on gross bookings instead of margin, on a seven-day window instead of four weeks, and excluding one market that 'had an outage'. One of the three is defensible under conditions. Deliverable: which you run, which you decline, the words you use to decline, and what appears in the written readout about all three requests.
Approach
- Sort the three requests by one test: could this have been specified before anyone saw the result, and is it symmetric across arms. That test, not the sponsor's seniority, decides what you run.
- Decline the gross-bookings switch on mechanism rather than on process: the credit operates by spending incentive dollars, and gross bookings excludes incentive spend by construction, so it cannot see the cost the guardrail exists to catch.
- Decline the seven-day window because the credit's payback horizon is longer than the window, so a short read measures the redemption spike rather than the behaviour change, and because the window was chosen after the four-week result was known.
- Run the outage exclusion only under stated conditions: the outage is visible in a metric nobody selected, such as requests per market-hour in fct_request, it hit both arms in the same proportion, and it is timestamped independently of this test. Report it as a sensitivity beside the primary, never as a replacement.
- Put all three requests in the readout with their status and reasoning, which makes the selection visible and removes the incentive to ask again quietly; then give the sponsor a real path forward: the incentive level at which the credit would break even on contribution margin, and a powered follow-up if that level is reachable.
Follow-up
- The sponsor says the guardrail was the wrong metric all along - how do you respond?
- What if the outage is real but hit only the treatment arm?
- How would you have pre-registered exclusions so that this conversation never happened?
- 01
Describe a time you had to deal with highly imbalanced data in a classification project. What techniques did you use, and how did you measure success?
- 02
Three requests arrive the same morning and you have one analyst-week. Pricing wants a fee elasticity refresh for a change scheduled in ten days. Supply wants a churn model for approved providers who never opened a session. Finance wants the monthly contribution-margin restatement that attributes refunds and chargebacks in fct_money_movement to the order's completion month rather than the posting month. Deliverable: your ranking, the criterion behind it, the smallest useful version of each, and what you say to the two teams you rank below first.
- 03
A four-week consumer-credit test reads flat on completed orders per active consumer and negative on contribution margin per completed order, which was the pre-registered guardrail. The sponsor asks for three re-cuts: on gross bookings instead of margin, on a seven-day window instead of four weeks, and excluding one market that 'had an outage'. One of the three is defensible under conditions. Deliverable: which you run, which you decline, the words you use to decline, and what appears in the written readout about all three requests.
Is this an official Turo interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Turo. Rounds and questions reflect what candidates have reported, not a process Turo 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 process at Turo?
A: The interview process is rated as average to difficult. The difficulty stems primarily from the open-ended nature of the take-home case study and the depth of the subsequent technical presentation, where interviewers will drill down into your modeling choices and code architecture.
PracHub interview research ↗What is the time commitment expected for the take-home case study?
A: The take-home is designed to be completed over a weekend. While the technical requirements are straightforward, creating a polished slide deck that clearly communicates your business insights and technical approach can make the project feel somewhat time-consuming.
PracHub interview research ↗What is the hybrid work policy for Data Scientists at Turo?
A: Turo highly values in-office collaboration. This role operates on a hybrid schedule, requiring team members to be in the office three days per week (typically Mondays, Wednesdays, and Thursdays) at their local office location (such as San Francisco).
PracHub interview research ↗What differentiates candidates who receive offers from those who do not?
A: Successful candidates excel at connecting their technical work to business outcomes. They do not just present a model with high accuracy; they explain how that model impacts marketplace health, host retention, and guest conversion, and they present their findings with executive-level clarity.
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
Explore related engineering environments and compare the preparation focus.
Zillow Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Zillow, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Whatnot Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Whatnot candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Uber Drivers Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Uber Drivers, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
TaskRabbit Data Scientist Interview Questions & Guide 2026
Timed practice for TaskRabbit data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.