Waymo Data Scientist Interview Questions & Guide 2026

Interviewing at Waymo

• Practice bank: 33+ questions
• Rounds: 3
• Typical prep: 2–4 weeks
• Interview reports: 2

Interview rounds

Round	Questions
Online Assessment	8
Technical Screen	11
Onsite	14

How hard is the Waymo Data Scientist interview?

Difficulty	Share	Questions
Easy	36%	12
Medium	64%	21
Hard	0%	0

What Waymo actually tests for

Topic	Share	Questions
Analytics & Experimentation	27%	9
Data Manipulation (SQL/Python)	24%	8
Statistics & Math	24%	8
Coding & Algorithms	15%	5
Machine Learning	9%	3

The 60-second brief

As a Data Scientist at Waymo, you sit at the intersection of complex autonomous vehicle engineering, advanced machine learning, and commercial ride-hailing operations. Your primary mission is to help the company make the most informed, data-driven decisions while scaling the Waymo Driver—the world's most experienced driver—across new geographies, vehicle platforms, and weather conditions. Autonomous driving presents a fundamentally unique paradigm in data science, moving far beyond traditional web analytics into dense simulation data, rare event rate estimation, and rigorous on-road performance evaluation.

Waymo candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

What a Data Scientist does at Waymo

Your work directly influences whether software updates, new safety protocols, and large-scale infrastructure footprints are ready for public deployment. Whether you are building incrementality measurement frameworks for digital media, modeling weather patterns and their impact on fleet safety, or optimizing multi-city fleet orchestration, you collaborate hand-in-hand with engineering, product, and operations teams. You will tackle deeply ambiguous problems by scoping technical priorities, establishing novel statistical methodologies, and translating complex data signals into actionable strategies for senior leadership.

Expect an environment that is deeply data-driven, intellectually rigorous, and fast-paced. You will be expected to balance scientific depth with business pragmatism, ensuring that every metric and evaluation framework you design directly supports Waymo's core mission of safety, compliance, and commercial scale. Succeeding in this role requires a rare blend of advanced statistical intuition, robust programming capabilities, and the cross-functional communication skills needed to drive alignment across diverse technical teams.

The Waymo interview process

Waymo candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

Recruiter Screen

Most candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.

What it evaluates

• Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
• Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
• The substance of the questions you ask back, which an experienced screener reads as a level signal

How to prepare

• Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
• Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
• Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered

Technical Screen

A handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.

What it evaluates

• Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
• Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
• Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.

How to prepare

• Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
• Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
• If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows

Onsite Loop

Where a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.

What it evaluates

• Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
• Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
• Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
• Whether you ask what decision is actually on the table before explaining anything

How to prepare

• Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
• For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
• Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else

Technical Assessments

This 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 it evaluates

• 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

Behavioral Evaluations

Most of the weight in this round sits on the disagreement questions. Data work routinely produces an answer someone senior did not want, and the interviewer is trying to learn what you do in that hour. Both failure modes are common: folding as soon as a director pushes back, and treating the pushback as ignorance to be corrected with a better chart. A strong answer usually contains a specific thing the other person knew that you did not, and describes how you found out whether it changed the conclusion.

What it evaluates

• Whether you can state the other side's argument accurately before you explain why you disagreed
• What you treated as evidence during the disagreement, such as a rerun under their assumption or a holdout check, rather than persuasion technique
• Whether you distinguish being overruled from being wrong, and can give an example of each

How to prepare

• Write out one disagreement where you turned out to be wrong, and say what in the data misled you. Candidates prepare the story where they were right, and the follow-up asks for the other one.
• For your main disagreement story, be ready to say what result would have made you drop your position. If no such result exists, you were not arguing from the data.
• Practise stating the opposing position out loud in one sentence the stakeholder would accept, then continue the story.

Questions Waymo candidates report

Product sense and metrics

When the prompt says a number moved, the first question is whether it moved. Instrumentation changes, a redefinition, a backfill, a release that drops events, bot traffic and a plain holiday all produce the same shape as a real behaviour change. Confirm the move survives those before you reason about users at all. After that, localise instead of speculating: cut by platform, geography, tenure and acquisition source, and ask whether the aggregate fell because a segment changed or because the mix of segments changed. Weak answers list ten plausible causes. Strong ones order the cuts so each result eliminates several at once.

• How do you manage competing priorities when multiple engineering teams request custom evaluation frameworks simultaneously?
• Discuss the trade-offs between compute and memory bounds when optimizing large-scale vision-language models for onboard hardware deployment.
• How would you measure the success of an expansion into a completely new dense urban environment with unique traffic patterns?
• How would you design a metric portfolio to measure the ride quality and trustworthiness of the Waymo Driver during a rider-only trip?

SQL and data manipulation

These questions are rarely hard to solve and easy to get subtly wrong in the minutes available, so how you spend the clock is part of the answer. Write the filter and the spine, run it, look at ten rows, then add one layer and run again. That costs seconds and catches the errors that otherwise arrive as a plausible number you cannot defend. Keep the last minute for checks that fit on one line: row count against distinct key count, funnel stages that should only shrink, and nulls where a left join found nothing. Say out loud what you checked.

• Given a table of vehicle telemetry logs, write a query to identify consecutive trips where safety interventions occurred within a specific time threshold.
• Write a query to rank drivers or vehicles by their daily operational uptime and identify top-performing outliers using dense rank functions.

A/B testing and experimentation

Two hard parts of this work share a root, which is being honest about what a procedure actually guarantees. Watching a dashboard and stopping when it turns green is one, because a fixed-horizon test controls its false positive rate only at the horizon you declared, so every extra look is another chance to cross the line; the fix is a method built for continuous monitoring, such as group sequential boundaries or always-valid confidence sequences. The other is what to do when randomisation is not available, where the work is naming the assumption your quasi-experiment buys and showing how you would test it.

• What steps do you take when an experiment fails to reach statistical significance due to high variance in rare safety-critical events?
• How would you design an A/B testing framework for a new pricing strategy in a ride-hailing marketplace where geographical overlap creates severe experimentation pitfalls?

Statistics and probability

Probability questions here tend to be short, and they reward setup over cleverness. Define the random variable in words, say what it ranges over, and only then compute. Two tools cover most of what gets asked. Linearity of expectation lets you break a total into indicators and add them, and it holds whether or not those pieces are independent, which is precisely why it beats enumeration. Conditioning on the first step turns a repeating process into an equation you solve for the answer. Weak answers start multiplying numbers before the sample space is pinned down, then cannot locate where it went wrong.

• How do you approach rate estimation with rare events—such as critical safety interventions—where occurrences are extremely sparse in both real-world and simulation data?

Machine learning and modelling

Choose the evaluation metric from what is done with the score. If a fixed number of items go to human review each day, precision in that top slice is the metric and the score only has to order things correctly. If the score gets multiplied by a value to make an expected-loss decision, it has to be a calibrated probability, and area under the curve says nothing at all about that. Imbalance bites mainly here: resampling and class weights pull predicted probabilities away from the base rate, so anything that needed calibration needs recalibrating afterwards.

• How would you monitor production machine learning models for data drift and automatically trigger alerts for regression events?

Behavioural and stakeholder questions

Ownership questions usually arrive disguised as something else: a project that slipped, a pipeline that failed quietly, a number people had been reading wrong for months. What is being tested is what you did in the window before anyone told you it was yours. Be concrete about the first hour. Who you told, and what you checked before you knew how bad it was. The answer that falls short is the one that jumps from discovery straight to resolution and skips the part where you sized the damage, because sizing it is the decision everything else depended on.

• How do you handle interference and spillover effects between treatment and control groups in a localized urban transportation network?

Practice exercises with worked solutions

The prompts above tell you what gets asked.

Weekly unit fill rate by ship-from node

fct_order_line holds one row per customer order line per ship-from node in its terminal state, with ordered_qty, shipped_qty, requested_ship_date, actual_ship_at_utc, line_status and ship_from_location_id; dim_location carries location_code. Produce weekly first-pass unit fill rate by node. Numerator is shipped_qty on lines shipped on or before requested_ship_date; denominator is ordered_qty on every line requested that week except line_status = 'cancelled_by_customer'. Return node, week, numerator, denominator and rate, plus one network total row. State in the output how substituted lines are counted.

How a strong candidate works it

• Anchor the query at order-line grain filtered on requested_ship_date, never at shipments: a line that was never filled has no shipment row, and starting from shipments deletes exactly the failures the metric exists to count.
• Build the numerator as a conditional SUM over the same row set, SUM(CASE WHEN actual_ship_at_utc IS NOT NULL AND its ship date <= requested_ship_date THEN shipped_qty ELSE 0 END), so short and backordered lines stay in the denominator instead of vanishing behind a WHERE clause.
• Exclude only line_status = 'cancelled_by_customer'. A line cancelled for lack of supply is a service failure and belongs in the denominator at full ordered_qty.
• Group by node and by DATE_TRUNC('week', requested_ship_date), then build the network row by re-summing numerator and denominator across nodes, not by averaging the node rates.
• Declare the substitution rule explicitly in one column or one comment: lines with substituted_sku_id NOT NULL count toward the numerator only if substitution is an accepted fill in the service definition.

Expected result (20 min): One row per node-week with numerator, denominator and rate = numerator / denominator, plus a network row whose rate equals SUM(numerator) / SUM(denominator) across nodes and which will generally differ from the mean of the node rates.

Check yourself

• Rate never exceeds 1. If it does, shipped_qty is being counted on lines whose ordered_qty was filtered out of the denominator.
• Denominator per node-week matches a separate plain SUM(ordered_qty) with no CASE logic in it.
• Dropping the largest node moves the network rate. If it does not move, the total is an average of rates rather than a re-summed ratio.

Follow-ups

• actual_ship_at_utc is UTC but requested_ship_date is a local calendar date at the node. How does the comparison change for a node at UTC+9, and which direction does the error run?
• Fill rate rose two points while a node's short_reason_code mix moved from 'no_stock' toward 'credit_hold'. Is that a supply improvement?
• How would you hold SKU mix fixed so the network number is comparable month over month?

Simulate service levels under a variable inbound lead time

Daily demand for one SKU at one node is Poisson with mean 40. Replenishment lead time is 7 days with probability 0.7, 10 days with 0.2, and 14 days with 0.1, drawn independently per order. The policy is continuous review: order Q = 400 whenever the inventory position drops to the reorder point. Size safety stock two ways for a nominal 95 percent target, once as z times sigma_D times sqrt(mean lead time) and once with the variable-lead-time term. Simulate both and report achieved cycle service level and achieved unit fill rate.

How a strong candidate works it

• Compute both safety stock numbers analytically before simulating, so the simulation is a check on arithmetic you already understand rather than the source of the answer.
• Track inventory position (on hand plus on order) for the reorder trigger and on hand separately for the stockout test. Triggering off on hand alone re-orders while stock is already in transit and silently changes the policy you are measuring.
• Define the two outcomes precisely and separately: cycle service level is the fraction of replenishment cycles containing at least one unit of unmet demand, while fill rate is total units shipped from stock over total units demanded. They answer different questions and z targets only the first.
• Before running anything, bound the achievable service level by hand from the lead-time mixture. Each lead-time branch is a separate Poisson demand, so cycle service level is the probability-weighted sum of P(Poisson(40 x L) <= reorder point) across the three branches, and a reorder point that cannot cover the 14-day branch caps the policy at 0.9 no matter how the simulation is tuned.
• Run enough cycles that Monte Carlo error is small against the gap you are trying to see. The standard error of a service level is sqrt(p*(1-p)/n_cycles), about 0.005 at p = 0.7 with 10,000 cycles, so the 20-point gap between the two policies is unambiguous and a 1-point one is not.
• Let unmet demand be lost rather than backordered, state that choice, and note that switching to full backordering raises measured fill rate for the same policy.

Expected result (35 min): Naive safety stock is 30 units and the variable-lead-time figure is 150 units, a factor of five. At Q = 400 with lost sales, the naive policy achieves a cycle service level of about 0.70 and the correct policy about 0.90, so the naive policy misses the nominal 0.95 by roughly 25 points and the correct one by 5. The naive ceiling is arithmetic, not simulation noise: with a reorder point of 362 the 7-day branch is essentially always covered, the 10-day branch survives with probability P(Poisson(400) <= 362) = 0.029, and the 14-day branch never does, so cycle service level cannot exceed 0.7 + 0.20.029 + 0.10 = 0.706, and reorder-point undershoot of about 20 units under daily demand arrivals pulls it to roughly 0.70. The correct policy tops out near 0.90 for the same structural reason: a reorder point of 482 covers the 10-day branch almost completely (P = 0.99997) but not the 14-day one (P = 0.0004), so that 0.1 of probability mass is near-pure loss. Fill rate is higher than cycle service level under both, about 0.92 against 0.70 and about 0.98 against 0.90, because expected units short per cycle (roughly 33 and 10) are small against Q = 400.

Check yourself

• Set the lead time to a constant 8.3 days and confirm the two formulas return an identical safety stock, since the lead-time variance term vanishes.
• Compare the naive policy's simulated cycle service level against its analytic ceiling, 0.7 + 0.2P(Poisson(400) <= 362) + 0.1P(Poisson(560) <= 362) = 0.706 before undershoot. A simulated figure above that is a bug, usually triggering off on hand instead of inventory position, and three seeds should land a little below it and agree within about one point, consistent with a standard error of about 0.005 at 10,000 cycles.
• Confirm fill rate exceeds cycle service level at Q = 400 under both policies, and treat that ordering as a consequence of Q rather than a law: expected units short per cycle depends on the reorder point and the lead-time demand distribution, not on Q, so holding the reorder point fixed and halving Q leaves cycle service level roughly unchanged while fill rate falls by about the same shortfall over a smaller denominator.
• Confirm simulated demand over the lead time has mean near 332 units and standard deviation near 91.4, which is exactly the quantity the correct formula multiplies by z.

Follow-ups

• With Q = 100 against lead-time demand of 332 units, three or four orders are open at once. What happens to the meaning of a replenishment cycle, and to each of the two service measures?
• Lead time and demand are correlated because the supplier is capacity constrained in peak weeks. What does that do to the formula you used?
• How would you convert the extra 120 units of safety stock into an annual cost the business can weigh against the service gain?

Diagnose a sample ratio mismatch in an order-line test

A promise-date algorithm was randomised 50/50 with the hash taken on order_id. Your analysis table has 180,000 fct_order_line rows in the window: 91,540 control and 88,460 treatment. Lines are excluded when line_status = 'cancelled_by_customer' or when the join to fct_shipment_leg on shipment_id returns no delivered leg. The readout shows treatment up 0.9 points on on-time delivery. Test the split, state what the result implies about the readout, and list the three most likely causes given how this table was built.

How a strong candidate works it

• Run the chi-square goodness-of-fit test against the designed 50/50 split: expected 90,000 per arm, deviation 1,540, so chi-square = 2 * 1540^2 / 90000 = 52.7 on 1 degree of freedom, p around 4e-13. That is not sampling noise, and the readout is not interpretable until it is explained.
• Check the grain mismatch first, because it is the cheapest explanation: assignment is on order_id but rows are lines. A perfectly balanced order split still yields unequal line counts whenever lines per order differ by arm, and a promise-date change that splits or consolidates orders does exactly that. Recount distinct order_id per arm before touching lines.
• Walk the filter chain and recount the ratio at every step: raw assignment log, then all lines, then after the cancelled_by_customer filter, then after the delivered-leg join. The step where the ratio breaks names the cause without any further argument.
• Recognise that both exclusions are post-treatment. Requiring a delivered leg conditions on an outcome the treatment moves, which opens a collider path: whichever arm ships more of the difficult lines retains more slow lines and is penalised for succeeding.
• Do not report the 0.9-point lift. Rebuild the metric with all assigned orders in the denominator and never-shipped orders scored as failures, then re-run and compare.

Expected result (20 min): Chi-square 52.7 on 1 df, p about 4e-13: a genuine sample ratio mismatch, so the 0.9-point result is not reportable. The three causes to check, in order, are that the analysis grain (lines) differs from the assignment grain (orders), that the delivered-leg join drops lines at different rates by arm because shipping is itself an outcome, and that the cancellation filter removes post-treatment rows.

Check yourself

• The z form must agree with the chi-square: a 0.856-point deviation over a 0.118-point standard error is 7.26, and 7.26 squared is 52.7.
• A balanced order-level split alongside an unbalanced line-level split points straight at lines per order, so compare mean lines per order by arm directly.
• Re-running with no post-assignment filters should move the 0.9-point effect; if it does not move at all, the imbalance sits upstream of the metric and the randomiser itself is suspect.

Follow-ups

• The split is clean at order_id but broken at line level. Is the readout salvageable, and at which grain would you report it?
• How would you monitor for this automatically on a test that runs for six weeks, and at what threshold would you halt?

Perfect order rate falls only in the newest two weeks

A weekly perfect order chart holds at 94 percent for eleven weeks, then reads 91 percent and 84 percent in the two most recent weeks. The metric requires every line shipped_full, actual_delivery_at_utc on or before original_promised_delivery_date, and no joined shipment leg carrying exception_code IN ('damage','address_issue') or leg_status IN ('refused','lost'). It is published on a 14-day lag. Using fct_order_line and fct_shipment_leg, decide whether service regressed and specify what the chart should show for incomplete weeks.

How a strong candidate works it

• Start from the structure of the metric: the denominator is fixed at promise date while the numerator requires an event that may not have happened yet, so any week younger than the full delivery-plus-claims window is mechanically depressed. Establish that before hunting for a cause.
• Quantify the incompleteness instead of assuming it. Per promise week, report the share of lines with actual_delivery_at_utc IS NULL and the share of shipments whose legs are still leg_status IN ('tendered','in_transit').
• Build the maturation curve from history. For each of the eleven settled weeks, recompute the metric as it would have looked at 3, 7 and 14 days after the promise date, so a recent week can be compared against a healthy week at the same age rather than against a settled one.
• Only after age-matching, test whether any residual is real by cutting it by ship_from_location_id, mode and exception_code, and asking whether the loss concentrates where a genuine failure would concentrate.
• Fix the chart rather than only the analysis: suppress or grey weeks younger than the publication lag, or publish an age-matched estimate with an interval, and write the rule down so the next reader is not caught by the same shape.

Follow-ups

• Damage claims can arrive up to thirty days later. Does that argue for a longer lag or for a different numerator?
• How would you detect a genuine regression inside the lag window without waiting two weeks for it to settle?
• P90 order cycle time shows the same maturation shape but biased the other way. Why, and which metric is more dangerous to read early?

Tell a sponsor the effect cannot be measured in six weeks

A VP wants a read in six weeks on a forward-stocking policy now live at eight of forty nodes. Replenishment lead time on the affected lanes is five weeks, the eight nodes were chosen by the ops team because they were the worst performers, and the cross-node standard deviation of weekly fill rate is about 3 points. The VP has already told his leadership team that a number is coming. Tell him what you can and cannot deliver in six weeks, and propose the design and timeline you would commit to instead.

How a strong candidate works it

• Do the power arithmetic in front of him rather than asserting the test is underpowered: comparing eight treated against thirty-two untreated node means with a between-node standard deviation of 3 points gives a standard error near 3 times the square root of one eighth plus one thirty-second, about 1.2 points, so the minimum detectable effect at 80 percent power and a two-sided 5 percent test is roughly 3.3 points. Any real effect smaller than that comes back as a null you cannot interpret.
• Name the burn-in problem separately: with a five-week lead time, six weeks covers barely one replenishment cycle, so whatever you measure is the transition rather than the new steady state, and the transition usually looks worse than the policy is.
• Name the selection problem third: nodes picked because they were worst will improve toward the network mean without any policy, so a simple before-and-after at those nodes is biased upward and will over-claim.
• Offer what is genuinely deliverable in six weeks: an implementation read, meaning whether the policy is actually in force at the eight nodes, whether inventory positions moved as designed, and whether any leading indicator such as short_reason_code mix is moving, framed explicitly as operational verification and not an effect estimate.
• Propose the real design with dates: extend to sixteen weeks covering roughly three cycles, use a difference in differences against matched comparison nodes chosen on pre-period fill rate and volume, cluster variance at the node, and pre-register the burn-in window that will be excluded.
• Help him with the commitment he already made: give him the exact wording for what he reports at week six, so the honest answer arrives as something he can say rather than as a refusal.

Follow-ups

• He asks you to add the remaining thirty-two nodes to the rollout next month. What does that do to your design?
• If the effect really is 1 point, is the policy worth keeping, and how would you ever know?

Prioritise transport, plant and commercial in one week

Three requests land in the same week. Transport wants landed cost per delivered unit split by lane and mode from fct_shipment_leg for a carrier bid that closes in nine days. A plant manager wants OEE on two work centres decomposed into availability, performance and quality from fct_production_run for a capital request due next month. Commercial wants a fill-rate root cause from fct_order_line for an account review on Thursday. You are the only data scientist and have about four working days. Give your order, the rule that produced it, and what you say to the two who wait.

How a strong candidate works it

• Rank by the decision each request feeds and by whether your input can still change it, not by seniority or by who asked loudest: a bid closing in nine days is a live decision with a large irreversible spend attached, a capital request due next month has slack, and an account review has a fixed date but a smaller reversible decision.
• Check reversibility and blast radius: carrier rates lock for a contract period across every lane, so an error or an absence there is expensive for a year, while the fill-rate story can be revised next week.
• Look for the cheap partial that unblocks someone else: the fill-rate cut by node, by short_reason_code and by week is a few hours of work and covers most of what commercial needs on Thursday, so it does not have to wait behind the bid.
• Sequence with explicit time boxes: the commercial cut first because it is short and date-locked, the lane and mode cost analysis next with the allocation basis for multi-stop loads stated up front, and the OEE decomposition scheduled into the following week with a date the plant manager can hold you to.
• Tell the plant manager directly and early, with a date rather than a maybe, and say what you need from him in the meantime so the delay produces something.
• Escalate the trade-off rather than absorbing it silently: your manager should know a capital request slipped a week, because that is a business choice and not yours alone to make.

Follow-ups

• The plant manager escalates and his director asks you to reorder. What do you do?
• Which of the three would you push back on entirely, and what would you offer instead?

Where candidates lose points

Averaging rates across SKU-locations instead of re-summing

Fill rate, turns, OEE and on-time rate are all ratios whose denominators differ by orders of magnitude between cells, so an unweighted mean gives a slow-moving C item at a small node the same vote as a high-volume A item at a national node. The blended figure then moves whenever the portfolio mix moves, and it can improve in every cell while the company-level ratio worsens, or the reverse, which is Simpson's paradox with a warehouse attached. Always sum numerator and denominator to the reporting level and divide once, and when a rate must be compared across nodes, standardise on a fixed SKU mix before reading anything into the difference.

Sizing safety stock as z times sigma_D times the square root of lead time

That form assumes lead time is deterministic. When lead time itself varies, the standard deviation of demand over lead time is sqrt(L_bar * sigma_D^2 + D_bar^2 * sigma_L^2), and the second term dominates whenever supply is unreliable, so the familiar formula can understate the requirement severalfold for a long, variable inbound lane. Two further preconditions are routinely forgotten: demand is assumed independent across periods, which promotions and order batching break, and z maps to cycle service level (the probability of no stockout in a replenishment cycle), not to fill rate, which additionally depends on order quantity through the unit normal loss function. Quoting a z-derived number as a fill rate overstates achieved service, and the gap widens as order quantity shrinks.

Over-explaining the method and under-explaining the implication

Lead with the answer and what you would do about it, then give the approach when asked. Roughly one sentence of method per three of implication is the right ratio for a stakeholder-facing answer; the interviewer already knows what a regression is.

Analysing at a different unit than the one randomised

Say out loud what was randomised (user, device, account, cluster) and make the analysis unit match, or account for the clustering with cluster-robust standard errors, the delta method, or aggregation up to the randomised unit. Randomising users and then running a test over sessions understates variance and inflates the false-positive rate.

Weakness triage, driven by a day-one diagnostic

Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.

Day 1 — Diagnostic, scored before you study anything

• Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
• Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
• Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.

Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.

Day 2 — Largest gap: find the boundary rather than the subject

• Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
• Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
• Re-solve one of them from memory four hours later, on paper, with nothing open.

Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.

Day 3 — Largest gap: drill the blocking sub-skill

• Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
• Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
• Have someone else read your one-sentence rule and find the precondition you left out.

Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.

Day 4 — Second gap, plus maintenance on your strongest area

• Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
• Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
• Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.

Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.

Day 5 — The gap that is not a skill

• Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
• Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
• Deliver one answer again with a hard 90-second limit to force structure before detail.

Deliverable: Two recordings with a counted improvement in time-to-first-question.

Day 6 — Retest under day-one conditions

• Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
• Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
• Write which single block you would still lose the offer on.

Deliverable: A second scored rubric placed next to the first, with one named remaining risk.

Day 7 — Full loop under interview conditions

• Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
• Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
• Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.

Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.