Interview guides · Geotab

Geotab Data Scientist Interview Questions & Guide 2026

Timed data scientist practice for Geotab: short SQL and probability sets run end to end, then scored against a rubric.

The 60-second brief

The Data Scientist role at Geotab is pivotal in harnessing vast amounts of data to drive meaningful insights and innovation. This position not only influences product development but also enhances user experience by providing actionable intelligence derived from data analytics. As a Data Scientist, you will work on real-world challenges that affect fleet management, vehicle telematics, and overall transportation efficiency, making your contributions essential to the strategic objectives of Geotab.

Coding rounds for this role are usually data-manipulation shaped rather than data-structure shaped: group-bys, joins, time windows, ranking within a partition. Confirm the format before spending a week on graph traversal.

Focus areas

Evaluate forecasts at the lag ordering actually uses
Separate true demand from censored, stocked-out sales
Trace an on-time miss to one node

Overview

In this role, you will engage with cross-functional teams, leveraging your analytical skills to improve existing products and create new solutions that cater to customer needs. You'll be involved in complex datasets, employing advanced machine learning algorithms and statistical methods to extract valuable insights that inform decision-making processes. The opportunity to work on impactful projects, in a rapidly evolving industry, makes this role both exciting and critical for Geotab’s mission to leverage data for better transportation solutions.

The Geotab interview process

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

HR Screening

Whoever 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

Technical Assessments

Before anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.

What to demonstrate

Whether an ambiguous term becomes a specific column and filter before any computation happens
Whether you read the schema for keys and cardinality rather than only for column names
Whether the result answers the question at the grain it was asked at, per user or per session or per day

How to prepare

Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over

Final Interviews

A day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.

What to demonstrate

Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method

How to prepare

Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times

Where candidates lose points

Computing average inventory from period-end snapshots

Shipments cluster before period close, so the month-end on-hand position is systematically the lowest point of the month; turns computed against it are biased high and days of supply biased low, frequently by ten to twenty percent, and the bias grows precisely when close-period push is strongest. The same shape of error appears when a daily snapshot is joined to shipment events on date equality: a SKU with several legs on one day fans the snapshot out and multiplies the valued inventory. Average across every daily snapshot in the window for the denominator, and join snapshots to events with an explicit as-of condition and a row-count check at each grain before aggregating.

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.

Sizing estimates built on unnamed, unrevisable assumptions

Write each assumption as a named number you can change, then show the arithmetic so the interviewer can challenge one input instead of the whole answer. Finish by saying which assumption the result is most sensitive to, which matters more than the point estimate.

Stopping an experiment the moment it crosses significance

Fix the sample size or duration before launch, or use a method built for continuous monitoring such as a sequential test, always-valid confidence intervals, or group-sequential boundaries. Repeatedly checking a fixed-horizon p-value against 0.05 pushes the real false-positive rate well above 5 percent.

Questions & practice

Describe your process for validating the results of a model.

Medium · machine learning and modelling

Approach

Say how the offline result would be validated online before it is trusted.
Frame the prediction: the label, the moment of prediction, and the action it triggers.
Pick an evaluation metric that matches the cost of each error type, not a default.

Follow-up

How would you choose the decision threshold, and who owns that choice?
What would you monitor after launch to know the model is still valid?

Describe a machine learning project you've worked on and the impact it had.

Medium · machine learning and modelling

Approach

Say how the offline result would be validated online before it is trusted.
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.

Follow-up

How would you choose the decision threshold, and who owns that choice?
Where could label leakage enter this setup?

Reconstruct replenishment cycles from a daily inventory series

Medium · event sessionisation · state reconstruction · lead time

For one sku-location you have a daily series: inventory_date, on_hand_qty, in_transit_qty, on_order_qty, allocated_qty, shipped_qty, demand_qty, reorder_point_qty, stockout_flag. There is no purchase-order table. Infer the replenishment cycles: a cycle opens on the first day inventory position falls to or below reorder_point_qty, and closes on the first subsequent receipt. Receipts must be inferred from the series itself. Return one row per cycle with trigger date, receipt date, inferred lead time in days, demand during the cycle and stockout days, then report mean and standard deviation of the inferred lead time.

Approach

Derive the receipt signal from the stock balance rather than looking for a column that does not exist: on_hand today equals on_hand yesterday plus receipts minus units shipped, so implied_receipt = on_hand_qty.diff() + shipped_qty, and a positive value means goods arrived.
State what else can make that quantity positive: a cycle-count adjustment, a customer return, or a scrap reversal. Corroborate each candidate receipt with a matching fall in in_transit_qty on the same or adjacent day, and discard the ones with no corroboration.
Debounce arrivals. A load split across two dock shifts produces positive implied receipts on consecutive days; collapse runs of receipt days separated by less than a chosen gap into a single arrival and make the gap an explicit parameter.
Compute inventory position as on_hand + in_transit + on_order - allocated, not on hand alone, or every day after a trigger looks like another trigger and the cycle count explodes.
Walk the series once with an explicit state variable (awaiting-trigger, awaiting-receipt) rather than trying to vectorise the pairing. The state machine is what makes cycles non-overlapping, and it is what a reviewer can check line by line. Be clear that cycles defined this way do not tile the calendar: the stretch from a receipt until the position next falls to the reorder point sits inside no cycle.

Worked solution (35 min)

Sort by inventory_date, assert no duplicate dates and no calendar gaps, and compute position = on_hand_qty + in_transit_qty + on_order_qty - allocated_qty.
Compute implied_receipt = on_hand_qty.diff() + shipped_qty and mark receipt days where it is positive and in_transit_qty fell.
Collapse consecutive receipt days into single arrivals using a gap threshold of one day.
Iterate the series with a two-state machine, emitting a cycle row when a trigger is followed by an arrival, and carrying an open trigger forward across days.
For each cycle sum demand_qty and stockout_flag between trigger and receipt, then compute mean and standard deviation of the lead times across cycles.

Expected result: A cycle table with non-overlapping intervals ordered in time, each with receipt_date strictly after trigger_date, plus two scalars: mean inferred lead time and its standard deviation across cycles. The cycles cover only the trigger-to-receipt stretches, so they will not add up to the length of the series; the post-receipt stretches where stock is still above the reorder point are outside every cycle by definition.

Verify it yourself

Assert no two cycles overlap and that every receipt_date is strictly later than its trigger_date.
Partition the calendar into four exhaustive categories and sum demand_qty over all of them: cycle days (trigger to receipt), post-receipt gap days (receipt to the next trigger), the head before the first trigger, and the tail after the last receipt. The total must equal total demand_qty. Summing cycles plus head and tail alone under-counts by exactly the gaps, which is the arithmetic proof that cycles do not tile the series.
Confirm the day counts of those same four categories sum exactly to the number of days in the series. A shortfall means two cycles overlap or a boundary day is double-counted. Cycle count times mean cycle length is not a substitute for this check, since it ignores the gaps.
Confirm total inferred receipts across the window approximately equals total shipped_qty plus the change in on_hand_qty from first day to last.

Follow-up

Two orders are open at once because the trigger fired again before the first arrived. How does your state machine change?
The policy quotes lead time in working days. What do you need from dim_location to convert, and where does the timezone matter?
You now have mean and standard deviation of lead time. Write the safety stock this implies and say which assumption you are least comfortable with.

Explain the time complexity of your solution for a given problem.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Compute rates by summing numerator and denominator separately, never by averaging rates.
Check whether any join is one-to-many before aggregating, or the sums inflate.

Follow-up

How would you verify this result without re-running the same query?
How does the query change if the join becomes one-to-many?

How would you merge two dataframes in pandas?

Medium · sql and data manipulation

Approach

Check whether any join is one-to-many before aggregating, or the sums inflate.
Compute rates by summing numerator and denominator separately, never by averaging rates.
State the window function and its partition and ordering out loud before writing it.

Follow-up

How would you verify this result without re-running the same query?
What breaks if events arrive late or out of order?

Write a function to find the largest number in a list.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Compute rates by summing numerator and denominator separately, never by averaging rates.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

How would you verify this result without re-running the same query?
How does the query change if the join becomes one-to-many?

Dead stock cells excluding SKUs used as substitutes

Medium · anti-join · null semantics · dead stock

Find dead stock: sku_id x location_id cells whose latest fct_inventory_daily row has on_hand_qty > 0 and which have no fct_order_line with that sku_id and ship_from_location_id in the last 90 days. Also exclude any SKU that filled another line as a substitute in that window; fct_order_line.substituted_sku_id is NULL on every line that was not substituted. Value each cell at on_hand_qty * standard_cost_cents taken from the snapshot, not from dim_sku. Return the cell, days since its last demand line, and value, ordered by value. Treat line_status = 'cancelled_no_supply' as demand.

Approach

Take the latest snapshot per sku-location with ROW_NUMBER() OVER (PARTITION BY sku_id, location_id ORDER BY inventory_date DESC) = 1, or an equivalent MAX(inventory_date) join, and keep rows with on_hand_qty > 0.
Anti-join demand with NOT EXISTS against fct_order_line on both sku_id and ship_from_location_id over the 90-day window, counting every line status including cancelled_no_supply, because unmet demand is still demand and a cell with it is not dead.
Write the substitute exclusion as NOT EXISTS, or force substituted_sku_id IS NOT NULL inside the subquery. NOT IN over a column that contains NULLs evaluates to NULL for every candidate that is not an explicit match, so the predicate is never true and the result set is empty.
Value from the snapshot's standard_cost_cents rather than dim_sku, since the dimension carries only the cost in force today and is revised at period close without back-dating.
Get days since last demand from a LEFT JOIN LATERAL MAX(ordered_at_utc), and report cells that never had a line in a separate bucket instead of as a very large number.

Worked solution (30 min)

CTE latest_snap: ROW_NUMBER over sku_id, location_id ordered by inventory_date DESC, filtered to rn = 1 and on_hand_qty > 0.
CTE last_demand: MAX(ordered_at_utc) grouped by sku_id, ship_from_location_id over all of fct_order_line, with no status filter.
Select from latest_snap LEFT JOIN last_demand, keeping rows where the max is NULL or older than 90 days.
Add AND NOT EXISTS (SELECT 1 FROM fct_order_line o WHERE o.substituted_sku_id = latest_snap.sku_id AND o.ordered_at_utc >= now() - interval '90 days').
Project value_cents = on_hand_qty * standard_cost_cents, order by it descending, and run the same query once with NOT IN to see the empty result for yourself.

Expected result: One row per dead sku-location cell with value_cents computed from the latest snapshot's own cost column, days_since_last_demand (or an explicit never-ordered bucket), ordered by value_cents descending. The substitute exclusion removes some rows; it must not empty the result.

Verify it yourself

Swapping NOT EXISTS for NOT IN on substituted_sku_id collapses the output to zero rows. That is the diagnostic for the NULL semantics, not a data finding.
Total value across returned cells is strictly less than total on-hand value at the same snapshot date.
No returned cell appears in SELECT DISTINCT sku_id, ship_from_location_id FROM fct_order_line over the same 90 days.

Follow-up

The query returns zero rows. Name the two likeliest causes and say which you would test first, with the one-line test.
How do you separate genuinely dead stock from a seasonal item out of season and from a lifecycle_status = 'pre_launch' SKU?
The same SKU is dead at one node and short at another. Write the query that finds that pattern and say what it implies about the policy.

Given a dataset with user behavior, how would you identify key trends?

Medium · product sense and metrics

Approach

Restate the decision this analysis has to support, and who acts on the answer.
State what result would change your recommendation, so the answer is falsifiable.
Fix the population and the time window before naming any metric.

Follow-up

Which segment would you cut first, and what would that rule out?
What would you do if the primary metric and the guardrail moved in opposite directions?

How do you prioritize your tasks when working on multiple projects?

Medium · product sense and metrics

Approach

State what result would change your recommendation, so the answer is falsifiable.
Fix the population and the time window before naming any metric.
Decompose the metric into the rates that drive it, and say which one you would check first.

Follow-up

How would you detect that the metric is being gamed rather than genuinely improving?
Which segment would you cut first, and what would that rule out?

How would you design a data pipeline for real-time analytics?

Medium

Approach

Clarify what is being asked and what a complete answer would contain.
Say what you would check first and why it is the highest-information step.
State your assumptions explicitly before working the problem.

Follow-up

How would you know your answer was wrong?
What assumption would you test first?

Price a three-point service target against inventory turns

Medium · service-cost tradeoff · safety stock · cost of capital

Commercial wants the cycle service level on C/Z items raised from 95 to 98 percent at every regional DC. Finance holds you to inventory turns. Using fct_inventory_daily (on_hand_qty, standard_cost_cents, demand_qty, safety_stock_target_qty, reorder_point_qty, stockout_flag), dim_sku (abc_class, xyz_class, shelf_life_days, lifecycle_status) and receipt history for lead times, state the primary metric, the guardrail, and the arithmetic that turns the request into units, cash and a payback claim. Say what the request does not buy.

Approach

Fix the vocabulary before any number, because the two candidate definitions are not even ordered the same way. Cycle service level is the probability of no stockout within a replenishment cycle, Phi(z). Unit fill rate under continuous review with backordering and normal lead-time demand is 1 - G(z) * sigma_dl / Q, where sigma_dl is the standard deviation of demand over the lead time, Q the replenishment quantity and G the standard normal loss function. The two are equal only at Q = G(z) * sigma_dl / (1 - Phi(z)), which is 0.418 * sigma_dl at z = 1.645 and 0.367 * sigma_dl at z = 2.054; above that Q the fill rate is the larger number.
Convert the z change: the 95th and 98th percentiles of the standard normal are 1.645 and 2.054, so safety stock scales by 1.249 at unchanged variability. That is a 24.9 percent rise in the safety component only; cycle stock is untouched, so total inventory rises by less.
Size the variability correctly with the variable-lead-time form, sigma_dl = sqrt(L_bar * sigma_D^2 + D_bar^2 * sigma_L^2), where sigma_L is the standard deviation of the lead time itself. On the long inbound lanes that feed C items the second term usually dominates, and the deterministic-lead-time form understates the requirement.
Cost it: incremental units times standard_cost_cents times an annual holding rate built from cost of capital, storage and an obsolescence term that is materially larger where shelf_life_days is non-null or lifecycle_status is 'phase_out'.
Value it honestly, and size the benefit in the unit the request actually moves. Expected units short per cycle fall from G(1.645) * sigma_dl = 0.0209 * sigma_dl to G(2.054) * sigma_dl = 0.0073 * sigma_dl, a 64.9 percent cut in shortage units. Convert that to contribution only with the margin and repeat-purchase assumptions written on the page, rather than assuming three points of service convert wholly into sales.
Give the conflict its own line rather than smoothing it: turns fall by construction because the denominator rises against unchanged COGS, so propose a differentiated policy by ABC/XYZ cell instead of claiming both numbers improve.

Worked solution (35 min)

Compute D_bar and sigma_D per sku-location at the review-period grain the policy actually uses, and L_bar and sigma_L from receipt history in the same time unit.
Compute sigma_dl with the variable-lead-time form, then safety stock at z = 1.645 and z = 2.054; the difference is the incremental units.
Value those units at standard_cost_cents and apply the annual holding rate, showing the obsolescence component separately for shelf-life and phase-out SKUs.
Read the fill rate both policies actually deliver by evaluating 1 - G(z) * sigma_dl / Q per cell at the Q in force, and report the Q/sigma_dl distribution so the cells near the crossover are visible rather than averaged away.
Recompute inventory turns: trailing-52-week COGS over the average of daily on-hand at cost, averaged across every daily snapshot rather than month-end positions.
Write the payback line: incremental annual carrying cost against incremental contribution from avoided shortage, with the shortage-to-lost-sale conversion stated as an assumption rather than buried in a spreadsheet.

Expected result: Safety stock rises by 2.054 / 1.645 = 1.249, so 24.9 percent more safety units at unchanged sigma_dl; total inventory rises by less because cycle stock does not move; turns fall by the ratio of old to new average inventory at cost. The deliverable states incremental units, incremental annual carrying cost, the avoided-shortage contribution required to break even, and a recommendation to apply the increase by ABC/XYZ cell rather than across the portfolio. It also states what the three points do not buy: they cut expected units short per cycle by 64.9 percent but they are not three points of fill rate, and on cells where Q is a couple of multiples of sigma_dl the delivered fill rate was already above 98 percent at the old z.

Verify it yourself

The z values are the 95th and 98th standard-normal percentiles; if the ratio is not close to 1.25, the wrong quantiles were used.
Setting sigma_L to zero must collapse the lead-time expression to sigma_D times sqrt(L_bar); if it does not, the formula is wrong.
Evaluate 1 - G(1.645) * sigma_dl / Q on the live C/Z order quantities before sizing anything: cells returning more than 0.98 are already meeting a 98 percent fill target at today's z, and a request that was really about fill rate is asking for inventory that is already bought.
Turns computed on the daily-average denominator come out lower than the same figure computed from month-end snapshots, because period-close shipping makes month-end the trough; a higher number means the denominator is still period-end.

Follow-up

The customer contract specifies fill rate, not cycle service level. How does the answer change, and in which direction?
The same cash could shorten the inbound lane instead. How do you compare the two options on one page?

Unit fill rate fell four points in one region

Easy · fill rate · segment cuts · mix shift

Weekly unit fill rate for one region fell from 96.1 percent to 92.0 percent over four weeks and has not recovered. Network fill rate is flat. You have fct_order_line (ordered_qty, shipped_qty, requested_ship_date, ship_from_location_id, sku_id, line_status, short_reason_code), dim_location (location_type, region_code, echelon) and dim_sku (abc_class, xyz_class, lifecycle_status). Produce the first four query cuts, say what each one rules in or out, and name the single most likely cause together with the evidence that would confirm it. Thirty minutes, SQL plus a short written argument.

Approach

Rebuild the metric by summing shipped_qty and ordered_qty to region level and dividing once, rather than averaging per-SKU-location rates. An unweighted mean of cell rates moves with portfolio mix on its own, so if the drop does not survive re-summing there is nothing physical to diagnose.
Cut by ship_from_location_id first. If one node carries the whole drop the mix of demand across nodes is not the story and the problem is local; if every node fell a little, the cause sits upstream in supply or forecast rather than in any warehouse.
Decompose the region change over abc_class by xyz_class cells into within-cell, mix and interaction terms: delta R = SUM(w0 * (r1 - r0)) + SUM(r0 * (w1 - w0)) + SUM((w1 - w0) * (r1 - r0)), where w is a cell's share of the denominator and r is its rate. A dominant mix term means demand moved toward hard-to-serve intermittent items and no cell actually got worse.
Group the lost units (ordered_qty minus shipped_qty) by short_reason_code. 'no_stock' points at planning, 'pick_shortage' and 'damage_on_pick' mean the stock was physically present and execution lost it, 'allocation_rule' means the units existed and were promised to someone else, and 'credit_hold' is not a supply chain failure at all.
Only then cross the weekly series against the promotion calendar, against SKUs with lifecycle_status = 'pre_launch' cutting in, and against accounts placing their first order in the window. A step change starting in the same week as a promotion or a new-item onboarding is a demand-side event, not a degradation.

Follow-up

Fill rate is flat nationally but down in this region. What does that tell you about where the stock went, and how would you test it?
Most of the failed units carry short_reason_code = 'no_stock', yet on_hand_qty at the node stayed above reorder_point_qty all month. How is that possible?
Would you publish this rate weighted by units or by revenue, and which team gets a different answer from each?

Suggested practice checklist

Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.

Day 1 — Fix the scope and set a baseline

Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.

Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.

Day 2 — One query pattern, written three times

Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
On the third attempt, write the grain of every CTE as a comment before writing its body.
Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.

Deliverable: Three independent versions of the same query plus a note on what changed between them.

Day 3 — Only the statistics you will be asked to defend

Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.

Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.

Day 4 — One case, and the assumptions holding it up

Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.

Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.

Day 5 — Your own work, timed

Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.

Deliverable: Two timed narratives with one defensible number in the opening line.

Day 6 — The one full rehearsal, in a longer weekend block

Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.

Deliverable: Mock notes naming three failure moments with a specific fix written under each.

Day 7 — Taper

Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
Re-read only your own notes from this week, and open no new material.
Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.

Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.

The project you argued against

Saying no well is a senior skill and it is rarely rehearsed. Think of a time you told someone their analysis was not worth doing, or that the experiment could not answer their question at the sample size available. Explain what you offered instead. Refusal without an alternative reads as obstruction rather than judgement.

What motivates you in your work as a Data Scientist?

Medium · behavioural and stakeholder questions

Approach

Name the disagreement or constraint, and how you resolved it with evidence.
Close with what you would do differently, concretely.
State the situation in two sentences and spend the rest on your reasoning.

Follow-up

How did you know the outcome was caused by your change?
What did you decide not to do, and why?

Tell a sponsor the effect cannot be measured in six weeks

Hard · power · selection bias · quasi experiments · saying no

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.

Approach

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-up

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?

Quantify your own impact on a safety stock change honestly

Hard · impact measurement · confounding · difference in differences

In March you re-sized safety stock at twelve regional DCs using the variable lead time formula. Unit fill rate at those nodes rose from 94.1 to 96.5 percent by June. In the same window a supplier that had been running 71 percent inbound on-time recovered to 93 percent, and Q2 volume is seasonally about 8 percent below Q1. Your manager asks for one sentence on impact for a performance review. Write the claim you are willing to defend under challenge, and explain how you bounded the portion attributable to your change.

Approach

Refuse the naive claim first: the 2.4 point gross movement contains at least three generating processes, and attributing all of it is the sort of claim that collapses the moment someone plots the supplier's on-time series next to it.
Build a comparison group from nodes that did not get the change, check that their pre-period fill rate moved in parallel with the treated nodes for at least two quarters before March, and estimate the difference in differences with variance clustered at the node, since twelve treated clusters is the effective sample size regardless of how many node-weeks there are.
Strip the confounders you can measure directly rather than trusting the design alone: restrict to sku-location cells sourced from other suppliers to remove the recovery, and hold the sku mix fixed across periods so the seasonal volume drop does not enter through mix.
Sanity-check the mechanism, not just the coefficient: if your change worked, the improvement should concentrate in cells whose reorder point rose and in short_reason_code = 'no_stock' lines, and should be absent where the policy did not move. If the gain is spread evenly, something else caused it.
State the result as an interval with the confounders named, and state the cost side too: extra units held at the applicable cost of capital, so the claim is a net one rather than a service headline.
Write the sentence so that it survives someone else re-running it, which usually means a smaller number than the gross movement and a named method.

Follow-up

The comparison nodes are not parallel in the pre-period. What do you do next?
Your bounded estimate is roughly half the gross movement. How do you present that to a manager who already told his boss the larger number?