Interview guides · J.B. Hunt Transport

J.B. Hunt Transport Data Scientist Interview Questions & Guide 2026

Data scientist interview prep for J.B. Hunt Transport: original practice on experiment design, SQL and metric reasoning, with worked solutions.

The 60-second brief

As a Data Scientist at J.B. Hunt Transport, you operate at the intersection of massive-scale logistics data and cutting-edge analytical modeling. Your work directly impacts how one of the largest supply chain solutions companies in North America optimizes its freight movement, fleet maintenance, and capacity planning. By transforming complex datasets into actionable insights, you help drive efficiencies that keep the economy moving.

A large share of questions open as "how would you measure X", where the real work is choosing the metric, fixing its denominator, and defining the population it applies to. Any computation comes last and is frequently not required at all.

Focus areas

Separate true demand from censored, stocked-out sales
Trace an on-time miss to one node
Size safety stock under variable lead times

Overview

The role is both challenging and intellectually stimulating, requiring you to navigate high-stakes problems in a fast-paced environment. You will collaborate with cross-functional teams, including engineering and operations, to build predictive models that solve real-world transportation hurdles. Success in this role requires not only technical proficiency but also the ability to communicate how your models provide tangible business value to non-technical stakeholders.

Given the company's roots in Fayetteville, Arkansas, you should be prepared to discuss how your technical solutions specifically address the unique complexities of large-scale logistics and transportation networks.

The J.B. Hunt Transport interview process

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

Initial Screening

Data Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.

What to demonstrate

Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
Whether you name what you have not done instead of stretching to cover every line of the posting
Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage

How to prepare

Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live

Technical Dives

Much of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.

What to demonstrate

Whether the query you write matches the plan you just described
What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly

How to prepare

Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock

Behavioral Rounds

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 to demonstrate

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.

Where candidates lose points

Attributing demand variability to the node where it is observed

Order variance amplifies as it moves upstream: batching to a truckload, minimum order quantities, forecast-driven ordering and promotional pull all convert smooth end demand into lumpy replenishment orders, so a plant can see a coefficient of variation several times that of the underlying consumption. Diagnosing the plant's schedule instability as a plant problem then produces interventions that cannot work, because the generating process sits one or two echelons downstream. Measure the bullwhip ratio explicitly (variance of orders placed by a node over variance of demand it received) at each echelon, and fix the ordering rule at the node where the ratio jumps rather than the node where the pain is felt.

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.

Reading an observational correlation as a causal effect

Name the confounder you are most worried about and the design that would remove it: an experiment, a difference-in-differences with a checked pre-period trend, an instrument, or a regression discontinuity. When none is available, state which direction the bias likely runs and bound the claim accordingly.

Interpreting a change before checking data quality and logging

Spend the first pass on row volume by day, null rates, duplicate keys, and whether the step change lands on a release or tracking-migration date. A discontinuity that coincides with a deploy is an instrumentation hypothesis before it is a behavioural one.

Questions & practice

How do you approach feature selection when dealing with high-dimensional data?

Medium · statistics and probability

Approach

Translate the result into the decision it informs, in one plain sentence.
Quantify uncertainty explicitly rather than reporting a point estimate alone.
Write down the assumption the method needs before you use the method.

Follow-up

Which assumption here is most likely to be violated in practice?
How would you explain this result to someone who does not know statistics?

Can you explain the difference between supervised and unsupervised learning in the context of freight forecasting?

Medium · statistics and probability

Approach

Quantify uncertainty explicitly rather than reporting a point estimate alone.
Write down the assumption the method needs before you use the method.
Say what the estimate is of, and over what population it generalises.

Follow-up

What sample size would you need to detect an effect half this size?
How would you explain this result to someone who does not know statistics?

If a model's accuracy drops significantly after deployment, what steps do you take to diagnose the issue?

Medium · machine learning and modelling

Approach

Set a baseline first, so any model has something honest to beat.
Pick an evaluation metric that matches the cost of each error type, not a default.
Say how the offline result would be validated online before it is trusted.

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 your process for debugging a model that is underperforming in production.

Medium · machine learning and modelling

Approach

Check what information would not exist at prediction time, and exclude it.
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?
What would you monitor after launch to know the model is still valid?

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

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.
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.
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.
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.
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)

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.
Group by sku_id, location_id, week and sum demand_qty and forecast_qty_lag7 into weekly totals.
Add abs_err = (forecast - demand).abs() and signed_err = (forecast - demand) on the weekly frame.
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.
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?

Write a function to clean and aggregate a dataset containing shipment records.

Medium · sql and data manipulation

Approach

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

Follow-up

How does the query change if the join becomes one-to-many?
What breaks if events arrive late or out of order?

Landed cost per delivered unit by lane without fan-out

Medium · fan-out · many-to-many · cost per unit

fct_shipment_leg holds one row per leg: shipment_id, leg_seq, origin_location_id, destination_location_id (NULL when the stop is a customer address rather than a network node), direction, mode, shipped_units, stop_count, leg_status, and linehaul_cost_cents, fuel_surcharge_cents, accessorial_cost_cents and expedite_premium_cents. fct_order_line carries shipment_id, NULL until shipped. Compute monthly landed cost per delivered unit by lane for direction in ('outbound','interfacility'), keying the lane on origin and destination with customer stops bucketed. Do not route through fct_order_line to get units. State the multi-stop allocation basis and what shipped_units means on a leg.

Approach

Keep the entire computation at leg grain. Numerator is the sum of the four cost columns, denominator is SUM(shipped_units), both over legs with leg_status = 'delivered' and the two directions. The order table is not needed and joining it can only damage the number.
Bucket destination_location_id IS NULL into an explicit customer_stop lane key with COALESCE, because a NULL never equals anything and will otherwise drop the row from a join or split it silently in a GROUP BY comparison.
Say out loud whether shipped_units is units on board or units dropped at that stop. Under units on board, summing the legs of a multi-stop load counts a unit once per leg it rides and understates cost per unit; under units dropped, the leg sum is a true shipment total.
Declare whether multi-stop cost is allocated by weight or by cube, since dense and bulky freight rank lanes in opposite orders under the two bases and the lane league table is not readable without it.
Roll months up by re-summing cost and units and dividing once. Averaging leg-level cost per unit weights a one-pallet LTL leg the same as a full truckload.

Worked solution (25 min)

Filter fct_shipment_leg to leg_status = 'delivered', direction IN ('outbound','interfacility'), and the month range.
Build lane_key from origin_location_id and COALESCE(destination_location_id::text, 'customer_stop').
Aggregate per month and lane_key: total_cost_cents as the sum of the four columns, total_units as SUM(shipped_units), leg_count as COUNT(*).
Divide once: cost_per_unit_cents = total_cost_cents / NULLIF(total_units, 0).
Cross-check the grand total against an unaggregated SUM over the same filter, and record the allocation basis and shipped_units semantics in the output header.

Expected result: One row per month and lane with total_cost_cents, total_units, leg_count and cost_per_unit_cents, computed only from fct_shipment_leg, where leg_count equals a plain COUNT(*) over the identical filter.

Verify it yourself

SUM(shipped_units) over the leg set equals a standalone aggregate with no joins. Routing through fct_order_line makes it larger, which is the fan-out showing itself.
Lane cost totals sum to the unfiltered month total for those directions and statuses.
Legs with destination_location_id NULL appear in the output under the customer bucket rather than going missing.

Follow-up

Cost per unit rose 8 percent while contracted linehaul rates were flat. Which columns do you cut first, and what does a rise in accessorials rather than linehaul point to?
How do you separate a rate change from a mix change across mode and service_level?
If cost genuinely had to be attributed to an order line, how would you allocate a leg's cost, and what does your rule do to a line that shipped one heavy item on an otherwise full truck?

Suppose we want to optimize route planning to reduce fuel consumption; what data would you need, and how would you build the solution?

Medium · product sense and metrics

Approach

Name one primary metric, then the guardrail that stops it being gamed.
Decompose the metric into the rates that drive it, and say which one you would check first.
Restate the decision this analysis has to support, and who acts on the answer.

Follow-up

What would you do if the primary metric and the guardrail moved in opposite directions?
How would you detect that the metric is being gamed rather than genuinely improving?

How do you prioritize your work when managing multiple data science initiatives?

Medium · product sense and metrics

Approach

Name one primary metric, then the guardrail that stops it being gamed.
Decompose the metric into the rates that drive it, and say which one you would check first.
Fix the population and the time window before naming any metric.

Follow-up

How would you detect that the metric is being gamed rather than genuinely improving?
What would you do if the primary metric and the guardrail moved in opposite directions?

A carrier scorecard the carrier cannot move on its own

Medium · gameable metrics · mix shift · immutable promise

Design the quarterly scorecard that decides carrier award volume. You have fct_shipment_leg (carrier_id, mode, service_level, origin_location_id, destination_location_id, tendered_at_utc, picked_up_at_utc, promised_delivery_at_utc, delivered_at_utc, planned_transit_hours, actual_transit_hours, stop_count, shipped_units, linehaul_cost_cents, fuel_surcharge_cents, accessorial_cost_cents, expedite_premium_cents, leg_status, exception_code). promised_delivery_at_utc is mutable and exception_code is carrier-supplied. Specify the primary metric, the guardrails, the mix control, and what must change in the data model before the first scorecard is published.

Approach

Name the data defect first. A mutable promise column lets the scored party move its own target, so require a tender-time snapshot of the promise, either an immutable column or a promise event log, and label any scorecard built before that exists as advisory.
Split the clock by who controls it: shipper dwell from tendered_at_utc to picked_up_at_utc, carrier transit from picked_up_at_utc to delivered_at_utc. Score transit against planned_transit_hours and report dwell separately, so a late tender is neither laundered into a carrier miss nor available as a carrier excuse.
Treat exception_code as a claim, not a fact. Publish on-time both with and without carrier-coded exceptions; excluding weather then has to be argued in the open, and a widening gap between the two series is itself the signal.
Control the mix. On-time and cost per unit both move with lane, mode, stop_count and service_level, so compare carriers only within lane by mode by service level cells and roll up on a volume weighting frozen from a prior period.
Pair service with delivered cost per unit including accessorials and expedite premium, because on-time bought by upgrading to guaranteed service or by paying expedite is a price increase rather than a carrier improvement.
Publish the award rule before the quarter opens, including the minimum leg count per cell below which a carrier is unranked, so a carrier with nine lucky legs cannot outrank one with nine hundred.

Worked solution (30 min)

Test mutability empirically: count legs whose promise sits implausibly far from tendered_at_utc plus planned_transit_hours, and legs delivered inside planned transit yet still flagged late; both patterns indicate promises edited after tender.
Build the leg fact with dwell_hours, transit_hours, an on_time flag against the tender-time promise, and an exception flag.
Aggregate to carrier by lane by mode by service level, carrying leg counts, on-time with and without exceptions, and delivered cost per unit.
Roll up to a carrier score using volume weights frozen from a prior period, so this quarter's own mix cannot reorder the ranking.
Produce the ranked table with the minimum-leg threshold applied and the excluded cells listed rather than dropped.

Expected result: A specification where the primary is on-time delivery at leg level against the tender-time promise, computed within lane by mode by service level and rolled up on frozen volume weights; guardrails are delivered cost per unit including accessorials and expedite premium, plus the dwell-versus-transit split; a minimum leg count per cell is stated; and a data-model change request covers an immutable tender-time promise and a non-carrier source for exception codes. Until that column exists the scorecard is published as advisory.

Verify it yourself

Re-running the roll-up with the current quarter's own volume weights changes the ranking only through mix; a large gap proves the mix control is load-bearing and must stay.
On-time with and without exception exclusions should track each other over time; a carrier whose two series diverge across a quarter is coding its way up.
Dwell hours plus transit hours equal tender-to-delivery elapsed time on every leg; any leg where they do not has a timestamp ordering defect and belongs in quarantine, not in the score.

Follow-up

A carrier's on-time is flat but its accessorial charge per leg has doubled. What do you check first?
How do you score a lane where one carrier holds all the volume and no comparator exists?

Plant schedule instability generated two echelons downstream

Hard · bullwhip · echelon attribution · variance

A plant reports that the replenishment orders it receives swing far more than end-customer demand, and asks for a larger finished-goods buffer. You have fct_order_line for customer demand at store and forward-stock nodes, fct_inventory_daily (on_order_qty, demand_qty per sku-location-date), dim_location (echelon, parent_location_id) and dim_sku (units_per_case, cases_per_pallet). Measure amplification at each echelon, identify the node whose ordering rule generates it, and price the buffer request against fixing that rule. Deliverable: a per-echelon amplification table and a recommendation.

Approach

Build two series per node at a fixed weekly bucket per SKU: the quantity the node ordered from its parent_location_id, and the demand it received from its children or from customers. Both series must cover the same SKU, the same weeks and the same node set, or the ratio between them means nothing.
Compute amplification per node as Var(orders placed) / Var(demand received), and report the squared coefficient-of-variation form alongside it. Mean volumes differ by an order of magnitude between echelons, so a raw variance ratio is not comparable across nodes of different size while the CV-squared ratio is scale-free.
Read the table echelon by echelon and find where the ratio steps up. The generating node is where it first exceeds one by a wide margin, not the node that feels the pain: amplification observed at the plant is the product of every ratio below it along that chain.
Name the mechanism at that node rather than asserting bullwhip generically. Minimum order quantity and lot-size multiple, the review period, batching up to a full truckload, and forecast-driven ordering that reacts to its own safety stock recalculation each leave a distinct signature in the order-size histogram.
Price both options rather than choosing one. The buffer request converts to units, then to cost at standard_cost_cents and to carrying cost at the applicable cost of capital. The rule change converts to more frequent, smaller replenishment and therefore more freight per unit. Present the trade with both numbers attached.

Follow-up

Orders cluster on exact truckload multiples. Would you break the batching rule, and what does that cost in freight per unit?
How would you test an ordering-rule change when there are twelve nodes, they draw on the same stock and the same outbound loads, and one replenishment cycle is three weeks?
Part of the plant's variance is its own production batching. How do you separate inbound amplification from what the plant creates for itself?

Suggested practice checklist

For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.

Day 1 — Metric anatomy

For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.

Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.

Day 2 — Diagnosing a drop without guessing

Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.

Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.

Day 3 — Should we build it

Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
Write the counter-metric that would make you kill the feature even if it wins on the primary metric.

Deliverable: A one-page product memo ending in a decision rather than a list of considerations.

Day 4 — The places aggregate numbers lie

Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.

Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.

Day 5 — Technical maintenance, aimed at metrics

Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.

Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.

Day 6 — Turning engineering work into data science stories

Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.

Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.

Day 7 — Mock case and gap list

Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
Listen back and mark every moment you proposed a solution before the success metric existed.
Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.

Deliverable: A recorded case plus a rewritten opening 90 seconds.

Explaining a method to someone who will not follow the maths

Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.

Tell me about a time you had to work with a difficult stakeholder to deliver a project.

Medium · behavioural and stakeholder questions

Approach

State the situation in two sentences and spend the rest on your reasoning.
Name the disagreement or constraint, and how you resolved it with evidence.
Quantify the outcome, including what you would not claim credit for.

Follow-up

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

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

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.
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.
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.
Describe the correction and the notification: who was told, how quickly, and whether the restated number changed the recommendation.
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?

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?