Interview guides / Zoox / Data Scientist
Zoox · Data Scientist
Updated · 2026-09-22

Zoox Data Scientist
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

This guide prepares a Data Scientist candidate at Zoox using original exercises built around product and business analytics data problems. PracHub assigns that framing to shape the practice; it is not a claim about Zoox's business or its interviews.

The boundary with engineering varies enough to be worth asking about directly. Some seats end at the analysis and the writeup; others carry feature pipelines, scheduling and alerting, which decides whether production data plumbing belongs in your prep at all.

Equal space on the page is a layout choice and carries no weighting. Rank these checkpoints by which one you are worst at and spend your time there, because nothing here reports what any particular team weights.

Separate novelty effects from durable behaviour changeSize an experiment before anyone launches itTurn a vague request into a measurable question

43 min read

Practice 12 Data Scientist prompts
5Company bank questionsSnapshot · Sep 22, 2026 PT
6Candidate experiences ↗Read their reports
12Practice promptsAcross five skill areas
3With worked solutionsIncluded in the practice prompts

The skills that carry the most weight are SQL across mismatched grains, experiment design, and the judgement to say what a result does not support. Event, session, subscription-period and exposure data all live at different grains, and the standard failure is a join that fans revenue across rows or an inner join that deletes exactly the population the question was about. Experiment work is judged less on whether a test statistic was computed correctly than on whether the randomisation unit matched the interference structure, whether the horizon was fixed in advance, and whether the analysis population was the exposed set rather than the assigned set. Above all of this sits communication: a correct analysis delivered as a table of numbers with no stated decision is treated as unfinished.

The work in general product and business analytics is mostly deciding what a number should mean and then defending that decision. A typical week contains a metric that moved and nobody can explain, an experiment readout where the headline is flat but three segments look interesting, a request to define success for a feature that ships next month, and a forecast or sizing input for a planning cycle. Very little of it arrives as a well-posed question; the first deliverable is usually a restatement of the question in terms that have a numerator, a denominator and a window. The output is a decision about shipping, pricing, spending or stopping, and it has to survive somebody else recomputing it from the same tables.

What makes it hard is the absence of a physical constraint to anchor definitions. A supply chain has units that either arrived or did not; a product funnel has whatever the tracking plan happened to record, sessionised by a rule somebody chose, joined on an identity that resets when a browser clears its cookies. Two competent analysts can produce different conversion rates from the same warehouse and both be right, which means the defensible answer is the one whose assumptions are written down. On top of that, the effects being measured are small: a genuine improvement to a mature funnel is often a fraction of a percentage point in absolute terms, comfortably inside the noise of a week, so most of the skill is in variance control and sizing rather than in modelling.

Where to focus your preparation

01

Metric definition and metric-tree construction

editorial

Preparation area covering the translation of a loosely worded goal into a metric with a stated numerator, denominator, window and exclusion rule, and the assembly of those metrics into a tree where each layer explains the one above it.

What to demonstrate

  • Whether a proposed metric is actually computable from the available tables, and whether the candidate says so when it is not
  • Whether the candidate names the window, the lag before publication and the excluded populations rather than leaving them implied
  • Ability to explain how a metric would be gamed and to name the specific guardrail that catches that behaviour
  • Judgement about the grain a metric belongs at, particularly the distinction between a per-user and a per-account question

How to prepare

  • Write out each metric in the tree above from memory, including its lag rule, until the definitions are recall rather than reconstruction
  • Take three vague goals such as 'improve engagement' and produce two defensible metrics for each, with the argument for choosing between them
  • Practise stating the failure mode of a ratio metric whose denominator is the thing that moved, and how you would detect that in the data
  • Rehearse the difference between a count, a rate and a rate-of-rates, and which of the three survives being rolled up across periods
PracHub interview preparation framework ↗
02

Warehouse SQL across event, session, subscription and exposure grains

editorial

Preparation area for queries that span an append-only event log, derived sessions, billing periods and experiment exposures, where a naive join fans out revenue and an inner join removes exactly the rows that carry the answer.

What to demonstrate

  • Correct handling of fan-out: pre-aggregating one side in a CTE before joining, and being able to demonstrate what the unaggregated join would have done to the total
  • Deliberate treatment of NULL foreign keys, including signed-out events with no user_id, sessions with consent_state = 'denied' and accounts with no subscription row
  • Fluency with window functions for first-event identification, cohort indexing, running counts and deduplicating overlapping billing periods
  • Whether rates are rolled up by re-summing numerator and denominator rather than by averaging daily or weekly rates

How to prepare

  • Build the full visitor-to-signup-to-activation funnel as one query using left joins forward, so that lost stages stay visible as NULLs instead of disappearing
  • Write MRR at the start and end of a month from fct_subscription_period, handling mid-period plan changes without double-counting the account
  • Practise a retention triangle from dim_user and fct_event with both window bounds enforced, and verify the row count at each grain before aggregating
  • Reconstruct a per-attempt funnel from flow_instance_id, and be able to say what breaks when that id is missing
PracHub interview preparation framework ↗
03

Experiment design, sizing and readout discipline

editorial

Preparation area for choosing a randomisation unit, powering a test before it launches, and reading it out in a way that survives scrutiny, including the cases where the honest answer is that the test could not have detected the effect in question.

What to demonstrate

  • Whether the randomisation unit matches the interference structure, and whether the standard error is computed on that unit rather than on the row
  • Ability to size a test from first principles: for a proportion, roughly 16 p(1-p) divided by the squared absolute lift per arm, at 5% two-sided alpha and 80% power with equal arms
  • Recognition that the analysis population is the exposed set, that assignment without exposure dilutes the estimate toward zero, and that a sample-ratio mismatch invalidates the readout rather than being a footnote
  • Whether novelty and primacy effects are addressed, and whether the candidate distinguishes a metric that recovered from one that was never affected

How to prepare

  • Memorise the proportion sizing shortcut and practise computing a minimum detectable effect from a realistic weekly traffic figure in under a minute
  • Be able to state the design effect for clustered randomisation, variance inflated by 1 + (m-1) rho with m the mean cluster size and rho the intraclass correlation, and what it does to required sample size
  • Practise explaining why a per-session metric randomised on users needs a delta-method or bootstrap standard error rather than a naive one
  • Prepare a short account of variance reduction with a pre-period covariate, including the fact that it removes a share of variance equal to the squared correlation between covariate and outcome
PracHub interview preparation framework ↗
04

Causal inference when randomisation is unavailable

editorial

Preparation area for questions where an experiment is impossible, illegal or already too late, covering the quasi-experimental designs, the assumption each one rests on, and how to argue that assumption is plausible in the case at hand.

What to demonstrate

  • Whether the candidate names the identifying assumption rather than the method, for instance parallel counterfactual trends rather than 'difference-in-differences'
  • Ability to choose between difference-in-differences, a geo or time-based holdout, regression discontinuity and matching on the basis of what the data actually supports
  • Awareness of what matching cannot fix, namely selection on anything unobserved, and willingness to say so instead of presenting a balanced covariate table as proof
  • Whether a placebo or pre-trend check is proposed before the estimate is believed

How to prepare

  • Practise writing the parallel-trends check you would run before a difference-in-differences estimate, and what you would conclude if the pre-period trends diverge
  • Prepare one worked case where a launch was staggered across regions and explain how the staggered timing itself provides the comparison
  • Rehearse the argument for a geo holdout as the cheapest credible read on channel incrementality, including how you would size it on total conversions
  • Be able to state in two sentences why observational channel comparisons overstate the channels closest to conversion
PracHub interview preparation framework ↗
05

Diagnosing a metric movement and landing the decision

editorial

Preparation area for the open-ended case where a number moved and the task is to find out why and say what to do, working from a decomposition rather than from a list of guesses.

What to demonstrate

  • Whether the first move is to verify the metric itself, covering instrumentation changes, a late-arriving data partition, a client release and a definition edit, before any product hypothesis
  • Whether the decomposition is systematic, splitting the metric into its factors and then across segment, platform, geography, tenure and channel rather than sampling hypotheses at random
  • Ability to size the contribution of each candidate cause, so that a segment moving sharply but carrying two percent of volume is correctly set aside
  • Whether the answer ends in a recommendation with its uncertainty stated, and whether the candidate says plainly when the data cannot yet support one

How to prepare

  • Rehearse a fixed opening sequence: confirm the movement is real and outside normal weekly variation, confirm the pipeline and tracking plan did not change, then decompose
  • Practise the multiplicative decomposition of a funnel metric so that a drop can be attributed to a specific stage rather than to the funnel in general
  • Build the habit of quantifying every candidate cause in the units of the headline metric, so contributions can be ranked and the remainder made explicit
  • Practise delivering the finding in three lines, the movement, the cause with its share, and the decision, before any supporting detail
PracHub interview preparation framework ↗

From candidates who interviewed

6 candidate reports. Individual accounts describe a particular role and hiring cycle.

Software Engineer

Zoox Software Engineer interview: a written assignment and unclear evaluation

Take-home Project → Technical ScreenOutcome: rejected

The interview loop felt long and demanding. After a recruiter contacted me, I spoke with several hiring managers and moved into more technical work. The biggest commitment was an extensive assignment with a detailed written report and, if selected, a presentation to a panel. I felt the workload was disproportionate, especially when I couldn't see clearly how the work would be assessed. After fini…

Read full experience
Robotics Engineer

Zoox Robotics Engineer interview: validation-testing problem solving

HR Screen → Other

About a week after a recruiter conversation, I had a virtual interview with the hiring manager. I first walked through my background, then we discussed how I handle problems during validation testing: what I do when behavior is unexpected, how I debug, and how I decide which check to run next. It was a focused conversation rather than a puzzle marathon. The questions stayed close to my day-to-day…

Read full experience

Where candidates lose points

PracHub editorial advice for the preparation topics above.

01

Counting on an identity key that changes underneath the metric

visitor_id is per browser and per device, and it resets on cookie clearance, private browsing and platform privacy changes, so the distinct-visitor count drifts upward for reasons unrelated to reach. Any rate with visitors in the denominator therefore decays over time even when behaviour is constant, and any rate with visitors in the numerator inflates. The stitching at signup makes it worse in both directions: a user who signed up on mobile and returns on desktop is two visitors and one user, while a shared device is one visitor and several users. Decide which key each metric is counted on, write it into the definition, and when comparing a period before and after a platform privacy change, expect a level shift in every visitor-keyed metric and do not attribute it to the product.

02

Reading a pooled rate that moved because the mix moved, not because any behaviour changed

A pooled conversion rate is a weighted average, and a shift in the weights can move it in the opposite direction to every one of its parts. A paid campaign that brings low-converting traffic drops overall signup conversion even if desktop, mobile web and app conversion each rose that week, which is Simpson's paradox and it is the single most common cause of an inexplicable dashboard move. The discipline is to decompose before explaining: recompute the rate holding last period's segment weights fixed, and compare that counterfactual to the actual, so the mix effect and the rate effect are separated numerically rather than argued about. Segment on the dimensions that actually reweight, which in this domain are almost always device_type, referrer_channel, country and new versus returning.

03

Answering a product-sense question with a list of features

Answer with a decision and the measurement that would settle it: the hypothesis, the primary metric, the guardrails, and the result that would make you not ship. A feature brainstorm cannot be wrong, which is exactly why it earns no points.

04

Accepting a metric definition without asking about the denominator

Pin down the denominator, the eligibility filter and the time window before computing anything: conversion rate per session, per user, per eligible user and per new user are four different numbers with different behaviour. Restate the definition in one sentence and get agreement before you analyse.

Questions & practice

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

9 technical prompts3 include a worked solution

Simulate the false positive cost of repeated peeking

medium
simulationpeekingtype i error

Quantify the cost of peeking. Simulate a two-arm experiment with no true effect: each arm accumulates Bernoulli conversions at a base rate of 0.10 up to 40,000 units per arm. Run a two-sided two-proportion z-test at alpha 0.05 at ten equally spaced interim points, and record whether the test ever crossed. Report the false positive rate over at least 10,000 replications, alongside the rate for a single look at the final sample only. Use a fixed seed and report a Monte Carlo standard error on both figures.

Approach
  1. Generate each replication as two cumulative sums of Bernoulli draws, then read the interim points off the cumulative arrays. Regenerating data at each look would make the looks independent, which destroys exactly the dependence the exercise is about: later looks share data with earlier ones.
  2. Use the pooled-variance two-proportion z: p_pool = (x1+x2)/(n1+n2), z = (p1-p2) / sqrt(p_pool*(1-p_pool)*(1/n1 + 1/n2)), reject when |z| > 1.96. State that the normal approximation is fine here because the smallest look has roughly 400 expected conversions per arm.
  3. Vectorise across replications rather than looping: draw a (reps, n) array of uniforms, threshold at 0.10, cumsum along axis 1 and slice the ten look indices. A per-replication loop at 10,000 by 40,000 is unnecessarily slow.
  4. Record the any-cross indicator per replication, take the mean, and compute the Monte Carlo standard error as sqrt(p*(1-p)/reps) so the reported figure comes with its own precision.
  5. Report the single-look rate in the same run as a control. If it does not land near 0.05, the bug is in the test statistic and not in the peeking argument.
Follow-up
  • Re-run with 40 looks instead of 10. Why does the curve flatten rather than continue rising linearly?
  • Among the replications that crossed, what is the mean observed lift, and why is it not zero?
  • What does an O'Brien-Fleming boundary or an always-valid confidence sequence change about this simulation, and what does each cost in power?

Rebuild per-visitor ordering without groupby convenience methods

easyWorked solution
pandasvectorisationwindow logic

You have a DataFrame of 2 million fct_event rows with visitor_id, occurred_at_utc and event_id, unsorted and containing duplicate timestamps within a visitor. Produce three new columns: event_rank, the 1-based position of the event within its visitor ordered by occurred_at_utc; seconds_since_prev, the gap to that visitor's previous event, NULL for the first; and is_first_for_visitor. You may use sort_values, shift, cumsum, numpy and boolean masking. You may not use groupby.transform, groupby.apply, groupby.cumcount, groupby.rank or merge_asof. Break timestamp ties on event_id.

Approach
  1. Sort once by ['visitor_id', 'occurred_at_utc', 'event_id'] and reset the index. The whole exercise reduces to row arithmetic on a sorted frame, and the tiebreak on event_id is what makes the result reproducible across runs.
  2. Mark visitor boundaries with is_first = df['visitor_id'].ne(df['visitor_id'].shift()). This is the single fact every other column derives from.
  3. Compute seconds_since_prev as the diff of the timestamp column, then overwrite it with NaT/NaN wherever is_first is True. The shift crosses the boundary between visitors and will otherwise hand the first row of each visitor the last event of the previous one.
  4. Build event_rank from a running counter that resets at boundaries: take a global cumulative position (np.arange(len(df))) and subtract, per row, the global position at which that visitor started. Get the start position by forward-filling the positions where is_first is True, which is a cumsum-free reset and is O(n).
  5. Verify against the forbidden method once, as a test rather than as the implementation, and confirm the two agree on every row.
Worked solution 20 min
  1. Sort on the three-key tuple and reset_index(drop=True).
  2. Compute is_first via .ne(.shift()), which is True for row 0 because the shifted value is NaN.
  3. pos = np.arange(len(df)); start = pd.Series(np.where(is_first, pos, np.nan)).ffill(); event_rank = (pos - start + 1).astype(int).
  4. gap = df['occurred_at_utc'].diff().dt.total_seconds(); gap[is_first] = np.nan.
  5. Assert event_rank equals df.groupby('visitor_id').cumcount() + 1 on the sorted frame.
EXPECTED RESULTThree columns on the sorted frame: event_rank starting at 1 for every visitor and increasing by 1 with no gaps, seconds_since_prev null exactly where is_first_for_visitor is True, and is_first_for_visitor summing to df['visitor_id'].nunique().
Follow-up
  • The frame does not fit in memory. How does your approach change if you can only process one visitor-partitioned chunk at a time?
  • occurred_at_utc is client-supplied and sometimes runs backwards within a visitor. Does your seconds_since_prev go negative, and should it?
  • How would you extend this to reset the counter at every change of surface as well as visitor?

Split a pooled conversion drop into rate and mix

medium
mix shiftdecompositionpandas

You have weekly visit-to-signup counts by segment: a DataFrame with week, device_type, referrer_channel, visitors and signups. The pooled rate fell 0.84 percentage points between two consecutive weeks while several individual segments rose. Write a function that, for a caller-supplied list of segment columns, splits the pooled change into a rate effect, a mix effect and an interaction term that sum exactly to the observed change. Return those three scalars plus a per-segment contribution table sorted by absolute contribution, so the largest single driver can be named.

Approach
  1. State the algebra before coding: the pooled rate is r = sum over segments of w_s * r_s, with w_s the segment's share of the denominator. Then r1 - r0 decomposes exactly into sum(w_s0 * (r_s1 - r_s0)) for rate, sum((w_s1 - w_s0) * r_s0) for mix, and sum((w_s1 - w_s0) * (r_s1 - r_s0)) for interaction. The identity is per-segment, so it holds for any numbers you put in the four slots.
  2. Pivot both weeks onto a common segment index with an outer join so a segment that appeared or vanished is kept rather than dropped, then decide what rate to give a segment with no visitors in one of the weeks, and document the choice. The identity stays exact either way because the missing week's weight is 0, but the attribution does not. Filling the missing rate with 0 sends an appearing segment's entire w_s1 * r_s1 into the interaction term, since w_s0 = 0 makes both the rate term and the mix term (w_s1 - w_s0) * r_s0 identically zero; a vanishing segment then splits as -w_s0 * r_s0 in rate, -w_s0 * r_s0 in mix and +w_s0 * r_s0 in interaction.
  3. The convention used below instead imputes the missing week's rate as that week's pooled rate. A vanishing segment then lands wholly in mix at -w_s0 * r_s0, with rate and interaction cancelling; an appearing segment puts w_s1 * r_pooled0 in mix (volume arriving at the average rate) and only w_s1 * (r_s1 - r_pooled0) in interaction (its rate differing from that average). Impute by which week the segment is missing from, never by argument order, or the swap identities below stop holding.
  4. Guard the division where visitors is 0 so no NaN enters the vectors, because a single NaN poisons every sum. A segment with zero visitors in both weeks contributes exactly 0 and can be dropped; a segment missing from only one week does not contribute 0, and where its contribution lands is settled by the convention above, not by the guard.
  5. Compute the three components as vectors over segments, then sum. Keep the vectors, because the per-segment contribution table is what turns the decomposition into an explanation.
  6. Assert that the three components sum to the observed pooled change within floating-point tolerance. This identity is exact, so a mismatch means an implementation bug, not a modelling judgement.
Follow-up
  • The mix effect accounts for 0.71 of the 0.84 point drop, driven by paid_social volume. What is your recommendation, and what would change it?
  • Why is a two-way split into a counterfactual rate and a residual also exact, and when would you prefer it to the three-way version?
  • Segmenting on device and channel leaves a large interaction term. What does that tell you about the choice of segments?

Suggested practice checklist

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.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Design 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 ↗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 ↗Worked solution ↗
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 ↗
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 ↗Worked solution ↗
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 ↗
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 ↗Worked solution ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

Rigour against a deadline

Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.

Walk through an analysis you got wrong and what changed

easy
postmortemdata qualityself-assessment

Describe an analysis of yours that turned out to be wrong after somebody had already acted on it. You have four minutes. The account must name the defect mechanically, the join, the filter, the window or the identity key, rather than describing it as a communication problem. It must also say who did what because of the wrong number, how the error surfaced, how long it stood, and what control you put in place so that class of error cannot reach a decision again. Do not pick an error nobody acted on.

Approach
  1. Recognise what is being probed: whether you can be specific about your own failure without minimising it or performing contrition. The discriminator is whether the defect has a mechanism the listener could reproduce in their own warehouse.
  2. Choose the case by blast radius rather than by comfort. An error nobody acted on tests nothing, and picking one signals that you are managing the interview instead of answering it.
  3. Structure the account in six beats: the number, the decision it drove, the defect, the detection, the correction, the control. Keep the defect to one reproducible sentence, for example an inner join to fct_subscription_period that dropped accounts with no subscription row and so computed retention over payers only.
  4. State the direction of the bias, not only its existence. A filter or join that removes rows usually moves a metric predictably, and knowing which way shows you diagnosed the mechanism rather than patched the symptom.
  5. Be exact about detection and elapsed time. 'A colleague noticed' and 'the row-count assertion failed before publication' are different answers about the same organisation, and the second one is the one your control is supposed to produce next time.
  6. End on the control, its cost, whether it has fired since, and one thing it does not cover.
Follow-up
  • What did the control cost, and has it fired since? If it never has, how do you know it works?
  • How long did the wrong number stand before anyone questioned it, and what does that say about the review path it went through?
  • What is the equivalent mistake you are most likely to make in this role, given the tables you would be working in?

Explain a wide interval to a non-technical executive

medium
communicationuncertaintypricing

A pricing change is under consideration. Your best estimate of its effect on trial-to-paid conversion is a 1.8pp drop, with a 95% interval from a 4.6pp drop to a 1.0pp rise, read from a geo holdout rather than a randomised test. An executive preparing a board slide asks you for 'the number'. You have ninety seconds and one slide, and the words confidence interval, p-value and significance are not usable with this audience. Deliver the slide headline, the single supporting line, and what you say aloud.

Approach
  1. Recognise what is being probed: whether you can carry uncertainty into a decision instead of either hiding it or hiding behind it. The generic answer promises to explain the interval in plain English; the strong one replaces the question 'what is the number' with 'across this range, where does the decision change'.
  2. Find the threshold before you draft anything. Ask what the pricing case assumes, then compute the conversion drop at which the higher price stops adding revenue: price uplift on the conversions kept against the revenue lost from conversions forgone. That single figure is what makes the range legible.
  3. Restate the estimate and both bounds in the unit the audience already reasons in. Convert percentage points into monthly first-paid conversions at current trial volume, then into mrr_cents_constant_fx, so the slide reads as money per month rather than as statistics.
  4. Place the range against the break-even and say which part of it sits on each side. If most of the range clears the threshold, that is a recommendation to proceed with a monitoring plan; if the range straddles it, that is a recommendation to narrow the range first.
  5. Name what would narrow it and what that costs in weeks, then give one recommendation with an explicit condition for revisiting it. Uncertainty stated without a next step is read as indecision and the midpoint gets used anyway.
Follow-up
  • The executive says to give the midpoint and they will manage the risk. What do you do?
  • How does the slide change if the interval were a 4.6pp to 0.2pp drop, with no positive outcomes in range?
  • Why is a geo holdout the credible read here rather than the attributed channel numbers you already have?

Quantify your own impact without claiming the topline you touched

hard
self-assessmentattributioncommunication

You are writing the impact section of your own review. Over the year you ran four experiments, one of which shipped and three of which were flat; you corrected the definition of gross monthly revenue churn so that cancellation is recognised at period_end_utc; and you built a self-serve funnel dashboard. Weekly active accounts rose 14% over the same period. Your reviewer knows the data well. Write the three impact claims you would defend, stating for each what you contributed, what evidence supports it, and what portion of the outcome you are not claiming.

Approach
  1. Recognise what is being probed: whether you apply to your own work the causal standard you would apply to somebody else's roadmap claim. Nearly everyone who would reject 'accounts that do Y retain better' will write 'I drove a 14% increase' without noticing it is the same error with a friendlier subject.
  2. Sort the work by the kind of evidence it can carry. The shipped experiment is the only item with a randomised estimate, so it is the only one where an effect size is defensible, and you claim the interval rather than the point estimate.
  3. Claim the three flat experiments as decisions prevented and price them. Features not built, or built differently, on evidence, with the engineering weeks reallocated as the number somebody else can verify. A defensible null is a delivered decision and should be written as one.
  4. Claim the definition fix as correctness, not as improvement. The old figure was overstated by a specific percentage and appeared in a specific set of recurring documents; the impact is the change it produced in the forecast built on top of it, not a change in churn itself.
  5. Claim the dashboard on usage and displacement: distinct weekly users of it, and the ad-hoc request count for six months before against six months after. If the request log does not exist, record the claim as unverified rather than estimating it upward.
  6. Disclaim the 14% explicitly and once. State that it cannot be separated from seasonality, other teams' launches and a pricing change, and bound your own contribution from above using the shipped experiment's interval converted into headline units.
Follow-up
  • Your shipped experiment's interval was +0.2pp to +1.4pp on activation. How much of the 14% can that account for, and how do you say so without undercutting yourself?
  • A peer in the same cycle claims the full 14%. What, if anything, do you do about it?
  • If you could only keep two of your three claims, which do you drop, and why that one?
  • 01

    Describe an analysis of yours that turned out to be wrong after somebody had already acted on it. You have four minutes. The account must name the defect mechanically, the join, the filter, the window or the identity key, rather than describing it as a communication problem. It must also say who did what because of the wrong number, how the error surfaced, how long it stood, and what control you put in place so that class of error cannot reach a decision again. Do not pick an error nobody acted on.

  • 02

    A pricing change is under consideration. Your best estimate of its effect on trial-to-paid conversion is a 1.8pp drop, with a 95% interval from a 4.6pp drop to a 1.0pp rise, read from a geo holdout rather than a randomised test. An executive preparing a board slide asks you for 'the number'. You have ninety seconds and one slide, and the words confidence interval, p-value and significance are not usable with this audience. Deliver the slide headline, the single supporting line, and what you say aloud.

  • 03

    You are writing the impact section of your own review. Over the year you ran four experiments, one of which shipped and three of which were flat; you corrected the definition of gross monthly revenue churn so that cancellation is recognised at period_end_utc; and you built a self-serve funnel dashboard. Weekly active accounts rose 14% over the same period. Your reviewer knows the data well. Write the three impact claims you would defend, stating for each what you contributed, what evidence supports it, and what portion of the outcome you are not claiming.

PracHub interview preparation framework ↗

Frequently asked questions

Are these confirmed Zoox interview questions?

No. Every prompt here is an original PracHub practice exercise written for the Data Scientist role and for product and business analytics data problems. This guide does not claim to reproduce Zoox's interview questions, rounds or hiring timeline. Confirm the actual format, team and scope with your recruiter.

PracHub Data Scientist practice ↗
How much SQL is enough for a data scientist interview?

Enough to write a correct multi-table query under time pressure with no reference open. That means joins including anti-joins, aggregation with HAVING, window functions such as ROW_NUMBER, LAG and running sums, date bucketing, and conditional aggregation with CASE inside SUM. Recursive CTEs and query tuning rarely decide a loop. The usual failure is not exotic syntax but silently changing the row count with a fan-out join.

PracHub Data Scientist practice ↗
How do I talk about a project whose impact was small?

Lead with the decision it informed rather than the lift. A well-run experiment that found no effect saved the cost of building the feature, so say that, and say what the result actually changed. Be precise about the inference: what you could and could not conclude, and whether the study was powered to detect an effect size you would have cared about. "We were underpowered" reads as more senior than a large unattributed percentage.

PracHub Data Scientist practice ↗
How do I prepare for a case study with no data in it?

Practise estimation out loud. Take a quantity you cannot look up, decompose it into factors you can bound, state each assumption as you use it, and sanity-check the total against something you do know. The grading is on structure and on whether your assumptions are stated and defensible, not on the number. Get comfortable saying "call it ten million, and the conclusion holds even if I am off by a factor of two."

PracHub Data Scientist practice ↗
Sources & methodology 2 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.

Practice 12 Data Scientist prompts