FedEx Data Scientist Interview Questions & Guide 2026

The 60-second brief

As a Data Scientist at FedEx, you sit at the intersection of global logistics, massive-scale data, and operational excellence. Your work directly influences how the world moves, impacting critical areas such as supply chain optimization, demand forecasting, route efficiency, and predictive maintenance for a massive fleet. You are not just building models; you are solving real-world, high-stakes problems that keep a global network functioning 24/7.

Learn the economics of the product category before the loop. Marketplaces, subscription products and ad-supported products turn on different core quantities (match rate and liquidity, retention and churn, fill rate and yield) and fail in different characteristic ways.

Focus areas

• Size safety stock under variable lead times
• Trace an on-time miss to one node
• Evaluate forecasts at the lag ordering actually uses

Overview

The role is defined by both the complexity of the data and the scale of the impact. Whether you are analyzing time-series data to predict package volume or developing algorithms to solve complex optimization challenges like the Travelling Salesman Problem, your contributions directly improve the speed, cost-effectiveness, and reliability of FedEx operations. You will often collaborate with engineering and operations teams to bridge the gap between theoretical modeling and production-level deployment.

Where to focus your preparation

Treat the sections below as preparation areas and confirm the format with your recruiter.

Preparation focus

No round sequence has been reported for this company, so work the categories below and confirm the format with your recruiter.

What to demonstrate

• Breadth across SQL, experimentation and product reasoning
• Ability to state assumptions before choosing a method

How to prepare

• Drill the practice exercises below and time yourself
• Prepare three quantified stories about decisions you drove

Where candidates lose points

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.

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.

Building features from data that postdates the prediction time

Check every feature against the timestamp at which the model would actually score, and drop anything computed from a window that includes or follows the label event. For a forecasting use case, split train and test by time rather than at random, and split by entity when the same entity recurs.

Solving silently instead of narrating the reasoning

Say which branch you are taking and why you chose it over the alternative, for example checking the denominator first because it changes what the comparison means. A correct answer that arrives with no visible path scores below a rigorous one that needed a hint.

Questions & practice

Can you explain the concept of CI/CD in the context of machine learning models?

Medium · machine learning and modelling

Approach

1. Check what information would not exist at prediction time, and exclude it.
2. Say how the offline result would be validated online before it is trusted.
3. Frame the prediction: the label, the moment of prediction, and the action it triggers.

Follow-up

• What would you monitor after launch to know the model is still valid?
• Where could label leakage enter this setup?

Weighted forecast error at the lag ordering actually consumes

Easy · wmape · forecast bias · aggregation grain · pandas

You are given fct_inventory_daily as a DataFrame with inventory_date, sku_id, location_id, demand_qty and forecast_qty_lag7. Replenishment is decided weekly per SKU per node, so score the forecast at that grain over a trailing 8 weeks. WMAPE is the sum of absolute weekly errors over the sum of weekly demand; weighted mean percentage error is the same ratio with the error left signed. forecast_qty_lag7 is null before a series existed. Return one row per location_id carrying both statistics, the shared denominator, and the count of rows excluded. No forecasting library.

Approach

1. Decide the null rule before writing any aggregation: a sku-location-week where any constituent day has a null forecast must be dropped whole. Signed error here is forecast minus demand, so summing 7 days of demand against the 5 days of forecast that survived leaves the numerator short by two days of forecast and drives the ratio negative, which reads as systematic under-forecasting the model never committed.
2. Aggregate demand_qty and forecast_qty_lag7 to sku x location x week first, then difference. Differencing daily and summing the absolute values afterwards answers a different question, since intraday timing error cancels inside a week and the ordering decision never sees it.
3. Build week buckets from inventory_date with a fixed anchor (a Monday-start ISO week or a rolling 7-day offset), and use the same buckets for both series so no partial week sits at either end of the 8-week window.
4. Compute the two statistics by summing numerator and denominator to the location level and dividing once. Never average sku-level ratios: a C-class item with 3 units of weekly demand would otherwise carry the same weight as an A-class item with 3,000.
5. Return the denominator and the excluded row count as columns, not as a printed aside, so a reader can tell a genuinely accurate node from one with almost no scored history.

Worked solution (20 min)

1. Filter to the trailing 8 complete weeks by inventory_date, then drop any sku-location-week containing a null forecast_qty_lag7 and record how many rows that removed.
2. Group by sku_id, location_id, week and sum demand_qty and forecast_qty_lag7 into weekly totals.
3. Add abs_err = (forecast - demand).abs() and signed_err = (forecast - demand) on the weekly frame.
4. Group by location_id and sum abs_err, signed_err and demand_qty; divide the first two by the third to get wmape and wmpe.
5. Attach the denominator and the excluded count, and sort by denominator descending so the nodes that matter read first.

Expected result: One row per location_id with wmape, wmpe, demand_denominator and excluded_rows. wmape is non-negative; wmpe carries a sign, positive meaning the node is over-forecast under the forecast-minus-demand convention and negative meaning under-forecast. A node with wmpe near zero and wmape near 0.3 is unbiased but inaccurate.

Verify it yourself

• Recompute WMAPE at daily grain over the identical row set: it must be greater than or equal to the weekly figure, because the absolute value of a sum of daily errors never exceeds the sum of their absolute values.
• Recompute the signed bias at daily grain: it must equal the weekly figure exactly, since signed errors and the denominator both add across days. A mismatch means the two grains are not covering the same rows.
• Confirm abs(wmpe) is less than or equal to wmape at every location; a violation means the two statistics are being computed over different row sets, which is the signature of a partially-dropped week.
• Set forecast_qty_lag7 equal to demand_qty on a copy and confirm both statistics return exactly 0.0.

Follow-up

• The same series is scored at lag 28 and WMAPE roughly doubles. Is that a model problem or an expected property of the horizon?
• A node shows WMAPE of 0.35 and bias of 0.01. What can you and can you not conclude about its inventory position?
• How would you report accuracy for a SKU whose weekly demand is zero in 40 of the 52 weeks?

Simulate service levels under a variable inbound lead time

Medium · safety stock · monte carlo · service level

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.

Approach

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Follow-up

• 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?

Stockout streaks of three days or more per cell

Medium · window functions · gaps and islands · stockout analysis

fct_inventory_daily carries one row per sku_id x location_id x inventory_date for every active pair, including days with nothing on hand, plus stockout_flag marking days where available_qty reached zero. Return every run of consecutive stockout days lasting three days or more: sku, location, start date, end date, run length, and demand_qty summed across the run. Return alongside it, per sku-location, the count of such runs in the window. Verify that the daily row series is contiguous for each pair before relying on date arithmetic, and say what you do about pairs that fail.

Approach

1. Filter to stockout_flag = TRUE, then assign ROW_NUMBER() OVER (PARTITION BY sku_id, location_id ORDER BY inventory_date).
2. Form the island key as inventory_date - rn * INTERVAL '1 day'. Two rows share a key only when their dates are exactly consecutive, so the key cannot weld separate runs together; the exposure runs the other way. A day with no snapshot row inside a true stockout breaks that run into fragments, and any fragment under three days is deleted by the threshold, so the run leaves the output rather than appearing with a wrong length.
3. Prove contiguity before trusting the key: per sku-location compare COUNT(DISTINCT inventory_date) against (MAX(inventory_date) - MIN(inventory_date) + 1), and separately confirm no pair carries two rows on one date, since a duplicate date advances rn without advancing the calendar and shifts every key after it. Pairs that fail get a generated date spine: LEFT JOIN generate_series over the window so each day is labelled stockout, in stock, or no snapshot, then apply a stated rule for the no-snapshot days instead of letting the key make that call silently. The conservative rule is to break the run at the hole and mark both fragments gap_adjacent.
4. Group by sku, location and island key for MIN and MAX date, COUNT(*) as length and SUM(demand_qty) as the demand exposed to the stockout, keeping runs of length >= 3.
5. Aggregate once more per sku-location for the run count, and mark runs touching either window edge as censored, since their true length is unknown from this window alone.

Worked solution (30 min)

1. CTE completeness: per sku_id, location_id compute COUNT(DISTINCT inventory_date) and the date span, and flag pairs where they disagree or where COUNT(*) exceeds COUNT(DISTINCT inventory_date).
2. CTE flagged: SELECT the stockout rows with ROW_NUMBER partitioned by sku_id, location_id ordered by inventory_date.
3. CTE islands: add grp = inventory_date - rn * INTERVAL '1 day'.
4. GROUP BY sku_id, location_id, grp producing MIN, MAX, COUNT() and SUM(demand_qty); filter COUNT() >= 3.
5. Second aggregate over that result for runs per sku-location, plus a censored flag where start equals the window start or end equals the window end.

Expected result: One row per qualifying run with start_date, end_date, length and summed demand_qty, every length at least 3, plus a per-cell run count whose sum across cells equals the number of run rows returned. Length, end_date - start_date + 1 and the island's row count agree by construction of the key, so their agreement is not evidence that the runs are real.

Verify it yourself

• Every gap between two consecutive returned runs for the same sku-location contains at least one day carrying a snapshot row with stockout_flag = FALSE. A gap made only of days with no snapshot row is a hole rather than a recovery, and those two runs are likely one run the key split.
• The completeness CTE flags zero pairs. Where it flags any, that pair's run lengths and run count are lower bounds and must be labelled as such, not published beside clean pairs as if comparable.
• Total stockout days across all returned runs is less than or equal to the total count of stockout_flag rows in the window.

Follow-up

• The longest runs cluster on X-class A items. What does that combination suggest to look at before touching the safety stock policy?
• How would you estimate lost demand across a run, given that demand_qty records the orders that were placed but not the orders nobody bothered to place?
• The snapshot is taken at each location's local end of day and the pairs span several timezones. What breaks, and what stays true?

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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.

What is your approach to time-series forecasting?

Medium

Approach

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

Follow-up

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

How would you approach the Travelling Salesman Problem?

Medium

Approach

1. State your assumptions explicitly before working the problem.
2. Work from the decision backwards to the evidence you would need.
3. Say what you would check first and why it is the highest-information step.

Follow-up

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

Explain the difference between L1 and L2 regularization.

Medium

Approach

1. Clarify what is being asked and what a complete answer would contain.
2. Work from the decision backwards to the evidence you would need.
3. Say what you would check first and why it is the highest-information step.

Follow-up

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

Size a fill-rate test when only nodes can be randomised

Easy · power · mde · cluster randomisation · design effect

A new allocation rule can only be switched on per node. You have 24 regional DCs, 12 per arm, and eight post-period weeks. The outcome is weekly unit fill rate per node from fct_order_line: SUM(shipped_qty) over SUM(ordered_qty) by requested_ship_date week. Between-node SD of that weekly rate is 4.0 percentage points; within-node week-to-week SD is 1.5 points. Planning wants to detect a 1.5-point lift at 80% power, two-sided 5%. Give the minimum detectable effect for this design and say whether running longer fixes it.

Approach

1. Write the variance at the unit that was actually randomised. The node is the unit, so each node contributes one number and the week rows inside it are not independent observations: the variance of one node's eight-week mean is sigma_b^2 + sigma_w^2/m, and the variance of an arm mean is that quantity over n nodes.
2. Plug in: 4.0^2 + 1.5^2/8 = 16.28 pp^2. MDE = (1.96 + 0.84) * sqrt(2 * 16.28 / 12) = 2.80 * 1.647 = 4.6 pp.
3. Re-run with m taken to infinity to show what duration buys: 2.80 * sqrt(2 * 16 / 12) = 4.57 pp. Between-node variance is 98.6% of the node-mean variance, and extra weeks only shrink the other 1.4%, so doubling the run changes the MDE by under 1%.
4. Invert the formula for the nodes needed to reach 1.5 pp: 2 * 16.28 * (2.80/1.5)^2 = about 114 nodes per arm. That does not exist, so state plainly that the design cannot answer the question as posed rather than reporting an underpowered null.
5. Offer the levers that attack sigma_b rather than time: matched-pair randomisation on pre-period fill rate with ANCOVA on the pre-period node rate (at a pre-post correlation of 0.8 the residual between-node variance is 5.76 and the MDE falls to about 2.8 pp), or a within-node switchback by week if the rule can be toggled.

Worked solution (25 min)

1. Compute the node-level variance of an eight-week mean: 4.0^2 + 1.5^2/8 = 16.28 pp^2.
2. MDE = 2.80 * sqrt(2 * 16.28 / 12) = 2.80 * 1.647 = 4.6 pp.
3. Repeat at 16 weeks: 16 + 2.25/16 = 16.14, giving 4.59 pp, a change of about half a percent.
4. Solve for nodes at the 1.5 pp target: n = 2 * 16.28 * (2.80/1.5)^2 = 114 per arm.
5. Recompute under ANCOVA at a pre-post correlation of 0.8: residual between-node variance 16 * (1 - 0.64) = 5.76, total 6.04, MDE = 2.80 * sqrt(2 * 6.04 / 12) = 2.8 pp.

Expected result: MDE is about 4.6 pp at eight weeks and still about 4.6 pp at sixteen. Detecting 1.5 pp would need roughly 114 nodes per arm, so this design cannot detect the target effect. Pre-period ANCOVA at a correlation of 0.8 brings the MDE to about 2.8 pp, which is better but still above target.

Verify it yourself

• Intraclass correlation is 16 / (16 + 2.25) = 0.88 and the design effect is 1 + (8 - 1) * 0.88 = 7.1; the square root, 2.67, is the factor by which a naive week-level standard error is too small.
• Setting sigma_b to zero must reproduce the ordinary two-sample formula on 96 independent node-weeks per arm.
• The MDE scales as one over the square root of the number of nodes, so quadrupling nodes should halve it; if your arithmetic does not do that, the week term has been misplaced.

Follow-up

• The rule can be toggled weekly. What does a node-level switchback buy you here, and what does it cost you in assumptions?
• If you must ship a decision on 24 nodes, what MDE do you pre-register, and what exactly does a null result license anyone to conclude?

Landed cost per unit rose with every lane flat

Easy · mix shift · simpsons paradox · cost per unit

Landed cost per delivered unit rose from 4.12 dollars to 4.49 dollars month over month, yet cost per unit is flat or lower in every individual lane and no contract rate changed. From fct_shipment_leg (linehaul_cost_cents, fuel_surcharge_cents, accessorial_cost_cents, expedite_premium_cents, shipped_units, mode, service_level, origin_location_id, destination_location_id, leg_status, direction), quantify how much of the 37-cent move is mix and how much is rate, then state what you would do about it. Multi-stop loads are allocated across legs by weight.

Approach

1. Reproduce the headline by summing the four cost columns and shipped_units over legs with leg_status = 'delivered' and direction IN ('outbound','interfacility'), dividing once. Confirm both facts hold on the same row set; if the lane figures came from an unweighted average of lane rates, the paradox is an artefact of the averaging and the work stops here.
2. Write cost per unit as a weighted mean of lane costs, C = SUM(w_i * c_i), where w_i is the lane's share of shipped_units. Compute within = SUM(w0 * (c1 - c0)), mix = SUM(c0 * (w1 - w0)) and the interaction term, and verify they sum to 37 cents.
3. If mix dominates, find which weights moved. Cut w by mode, by service_level and by distance band: parcel and ltl cost multiples of ftl per unit for the same goods, and 'expedite' carries expedite_premium_cents, so a migration of units across those categories raises the blend with no rate moving anywhere.
4. Separate a rate change from a surcharge change by decomposing the numerator as well. Fuel surcharge and accessorials move independently of contract linehaul, so report all four cost components per unit side by side for both months before accepting that rates held.
5. State the action in the units the decomposition produced. A mix problem is solved by load consolidation, order cut-off changes or minimum order quantities. A carrier negotiation only touches the within-lane term, which by hypothesis is the small one.

Follow-up

• Units migrated from truckload to parcel. Is that a transport failure, an order-profile change, or an inventory-positioning failure, and how would you tell them apart?
• You allocated multi-stop cost by weight. Which lanes change rank if you allocate by cube instead, and for what kind of freight?
• How would you build a mix-adjusted cost index that a monthly review can read without redoing this decomposition every time?

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.

How do you handle missing data in large, messy datasets?

Medium · behavioural and stakeholder questions

Approach

1. Name the disagreement or constraint, and how you resolved it with evidence.
2. Pick a story where you drove the decision, not one where you observed it.
3. State the situation in two sentences and spend the rest on your reasoning.

Follow-up

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

Walk through an inventory analysis that turned out wrong

Medium · error postmortem · snapshot bias · inventory turns

Six months ago you published inventory turns by node using the month-end on_hand_qty snapshot from fct_inventory_daily as the denominator, and two DCs cut cover on the strength of it. A finance review later showed month-end is systematically the lowest on-hand point of the month, because shipments cluster before close, so your turns were overstated and days of supply understated. Tell the story: what you built, how the error surfaced, what it cost, what you corrected, and the control that now prevents this class of mistake rather than this specific instance.

Approach

1. Give the facts in order and own the decision, not just the code: you chose the month-end snapshot because it was one row per sku-location and fast, and you did not check whether the sampling point was representative.
2. Quantify the error rather than describing it: recompute the same window against the average of every daily snapshot and state the gap in turns and in days of supply, which in a network with close-period push typically runs ten to twenty percent.
3. Separate the consequence from the mistake honestly: say what the two DCs did, whether service actually degraded, and if it did not, say so instead of inflating the damage to sound accountable.
4. Describe the correction and the notification: who was told, how quickly, and whether the restated number changed the recommendation.
5. Close on the generalised control: a denominator convention written into the metric definition, plus a row-count assertion at each join grain, because the same shape of error appears when a daily snapshot is joined to shipment events on date equality and one shipment with several legs fans the snapshot out.

Follow-up

• How did you decide whom to tell first, and how did you phrase it?
• What made you trust the month-end snapshot in the first place, and what would have caught it in review?

Prioritise transport, plant and commercial in one week

Medium · prioritisation · stakeholder management · decision value

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.

Approach

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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-up

• 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?