Interview guides · Bloom Energy

Bloom Energy Data Scientist Interview Questions & Guide 2026

Data scientist interview prep for Bloom Energy: original practice on experiment design, SQL and metric reasoning, with worked solutions.

The 60-second brief

As a Data Scientist at Bloom Energy, you play a pivotal role in harnessing data to drive innovation and improve energy solutions that contribute to a sustainable future. Your work involves analyzing complex datasets to uncover insights that influence product development, operational efficiency, and strategic decision-making. You will collaborate with cross-functional teams to solve real-world problems related to energy production and consumption, making your contributions critical to both the company's success and the global push towards clean energy.

Ask early whether the loop includes an asynchronous take-home or a timed live case, because the two are graded on different things. A take-home is read as an artifact: the question you decided to answer, what you did about missing or malformed records, and a conclusion stated plainly enough for someone to act on. A reviewer who cannot rerun your notebook discounts the result whatever score is printed in it. Hold to the stated time box and write down what you would have done with more of it, since the follow-up round is usually a live defence of the same work.

Focus areas

Join daily snapshots to shipment events safely
Price a service-level change in working capital
Separate true demand from censored, stocked-out sales

Overview

In this role, you will engage with advanced analytics, machine learning, and statistical modeling to address challenges in areas such as fuel cell technology, energy management systems, and customer behavior analysis. Your ability to turn data into actionable insights will not only enhance the performance of Bloom Energy’s products but also support the company’s mission of delivering reliable, affordable, and clean energy solutions. Expect to be part of a dynamic environment where your analytical skills will have a direct impact on product quality and user satisfaction.

The Bloom Energy interview process

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

Initial Screening Call

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

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

In-depth Interviews

Rounds outside the standard loop often open with something deliberately under-specified: a loose business problem, an open question about a product area, a dataset described in one sentence. The common failure is surveying, listing six plausible approaches and committing to none of them. The thing that separates a strong answer is scoping out loud. State what you are treating as the goal, name the metric you would move, say what you are choosing not to do and why, then take one path through to an actual answer. An interviewer can follow you down a narrow path. Nobody can grade a menu.

What to demonstrate

Whether you turn an ambiguous prompt into a stated question with a measurable outcome before doing any work
The judgement visible in what you cut, and whether you say why you cut it rather than silently dropping it
Whether you land on a concrete recommendation with its caveat attached, rather than an unranked set of options

How to prepare

Take three vague prompts, such as 'is this feature working', 'why did retention drop', and 'should we expand into a new segment'. For each, write one sentence of goal, one primary metric with its window, and two things you are explicitly not doing.
Practise giving the recommendation first and the reasoning second, in five minutes. Loosely defined rounds are usually time-boxed, and an answer that arrives last often does not arrive.
Keep a running assumption list as you talk, on paper or in the shared doc, so the interviewer can challenge one assumption instead of your whole answer.

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.

Averaging rates across SKU-locations instead of re-summing

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

Dropping rows with missing values without naming the mechanism

Say whether the values are missing at random, missing by a known process, or missing in a way that depends on the outcome, and handle them accordingly. Deleting incomplete rows silently redefines the population whenever missingness correlates with what you are measuring.

Comparing periods without accounting for seasonality or day-of-week

Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.

Questions & practice

What metrics would you use to evaluate the performance of a classification model?

Medium · machine learning and modelling

Approach

Say how the offline result would be validated online before it is trusted.
Check what information would not exist at prediction time, and exclude it.
Set a baseline first, so any model has something honest to beat.

Follow-up

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

Describe a machine learning algorithm you have implemented and the impact it had.

Medium · machine learning and modelling

Approach

Frame the prediction: the label, the moment of prediction, and the action it triggers.
Check what information would not exist at prediction time, and exclude it.
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.

As-of inventory position behind each short-shipped line

Medium · as-of join · window functions · lateral join

For every fct_order_line with line_status in ('shipped_short','backordered','cancelled_no_supply') and requested_ship_date in the last quarter, attach the inventory state that governed it: the fct_inventory_daily row for the same sku_id and ship_from_location_id with the greatest inventory_date strictly before requested_ship_date. Snapshots are taken at the location-local end of day. Return the line, ordered_qty, shipped_qty, and that snapshot's available_qty, blocked_qty, on_order_qty and in_transit_qty, plus the snapshot's age in days. Lines with no prior snapshot must appear with NULLs rather than disappearing from the result.

Approach

Recognise the join is an inequality, not an equality. The snapshot is an end-of-day state, so the position that governed allocation is the last close strictly before the requested ship date, and the same-date row reflects the outcome rather than the cause.
Implement it with LEFT JOIN LATERAL (SELECT ... WHERE sku_id and location_id match AND inventory_date < requested_ship_date ORDER BY inventory_date DESC LIMIT 1) ON TRUE, or equivalently ROW_NUMBER() OVER (PARTITION BY order_line_id ORDER BY inventory_date DESC) = 1 over a bounded candidate set.
Bound the lateral with a floor such as inventory_date >= requested_ship_date - 14 so the scan does not walk the whole history for each line, and let that floor produce NULLs rather than silently dropping the line.
Keep the join LEFT. Lines at a node with no prior snapshot are a data-quality finding worth counting, and an INNER join converts them into an invisible bias toward nodes with clean snapshot coverage.
Check the row count before and after the join: the output must have exactly one row per order_line_id, and any excess means the as-of match is returning more than one candidate.

Worked solution (30 min)

Filter fct_order_line to the three statuses and the quarter, and record the row count as the target.
Attach LEFT JOIN LATERAL over fct_inventory_daily with the strict inequality, the fourteen-day floor, ORDER BY inventory_date DESC and LIMIT 1.
Project the four quantity columns plus snapshot_age_days = requested_ship_date - inventory_date.
Compare the result row count with the target; investigate any difference before aggregating anything.
Count and group the NULL-snapshot rows by ship_from_location_id to see whether the gap is a node or a SKU launch artefact.

Expected result: Exactly one row per qualifying order_line_id, with snapshot columns drawn from the greatest inventory_date strictly less than requested_ship_date, snapshot_age_days at least 1, and NULL snapshot columns where no prior row exists inside the floor.

Verify it yourself

COUNT() of the result equals COUNT() of the filtered order-line set. Any excess is fan-out from a non-unique as-of match.
MAX(inventory_date) per line is strictly less than that line's requested_ship_date, with no equality cases.
The count of NULL-snapshot rows is small and attributable to specific nodes or newly launched SKUs rather than spread evenly.

Follow-up

Split the output by short_reason_code. Which codes should show available_qty at or near zero, and what does it mean when 'no_stock' lines show healthy availability?
blocked_qty is large on many of these lines. Is that a planning problem, and who owns it?
How would you extend this to the position at the moment of allocation rather than the previous close, and what would you need that the daily snapshot does not give you?

Weekly unit fill rate by ship-from node

Easy · ratio aggregation · service metrics · conditional aggregation

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

Approach

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

Follow-up

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

How would you approach forecasting demand for a new energy product?

Medium · product sense and metrics

Approach

Fix the population and the time window before naming any metric.
Restate the decision this analysis has to support, and who acts on the answer.
Decompose the metric into the rates that drive it, and say which one you would check first.

Follow-up

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

Given a dataset with multiple features, how would you determine which features are the most important?

Medium · product sense and metrics

Approach

Name one primary metric, then the guardrail that stops it being gamed.
Fix the population and the time window before naming any metric.
State what result would change your recommendation, so the answer is falsifiable.

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 do you prioritize tasks when working on multiple projects?

Medium · product sense and metrics

Approach

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.
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?
Which segment would you cut first, and what would that rule out?

If tasked with optimizing a process, what steps would you take to analyze and improve it?

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

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?

What considerations would you take into account when designing an experiment to test a new feature?

Medium · a/b testing and experimentation

Approach

Say whether units interfere with each other, and switch design if they do.
Name the guardrails that would stop a launch even on a positive primary result.
Name the randomisation unit first; it decides the variance and what the test can detect.

Follow-up

How would you handle interference between treated and control units?
What would you conclude if the result is positive but the test is underpowered?

How would you handle missing data in a dataset?

Medium

Approach

Clarify what is being asked and what a complete answer would contain.
Work from the decision backwards to the evidence you would need.
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?

Separate novelty from steady state in a planner tool rollout

Medium · novelty effect · burn-in · exposure time

An override assistant was given to 18 of 36 planners, randomised at the planner and held for 14 weeks. WMAPE at lag 7 improves 6% relative in weeks 1-3, 2% in weeks 4-8, and is flat after. Downstream unit fill rate does not move until week 6, then gains 0.8 points. Decide whether the early forecast gain is novelty, whether the late service gain is real, and specify the readout window you would pre-register next time.

Approach

Separate the two candidate stories before touching the data. Novelty is a behavioural effect that fades as a planner stops attending to a new tool; a real effect that is being diluted as easy wins are exhausted looks identical in calendar time. With one simultaneous launch, exposure time and calendar time are collinear and the two are not separable, which is itself the honest first answer.
Get identification from staggered exposure where it exists: index the effect by weeks since first exposure and compare a late cohort's week-2 effect against an early cohort's week-2 effect. Matching at equal exposure age but different calendar dates isolates novelty; a pattern that aligns on calendar week instead points at seasonality or a demand-side shock.
Put the two outcomes on their own clocks. Forecast error can respond in the week an override is made, but fill rate cannot respond until the changed order has been placed, received and consumed, which is one lead time plus one review period. A six-week onset is the expected physics of the replenishment loop, not evidence of a delayed behavioural effect.
Check the mechanism rather than the curve: count override actions per planner per week. Falling override volume alongside a falling effect is novelty. Steady override volume alongside a falling effect means the overrides stopped paying, because the largest corrections were taken first, and that is a different and more durable finding.
Pre-register a readout window that starts after a burn-in of at least two replenishment cycles for any service metric, states the forecast window separately, and defines the primary on post-burn-in weeks only.

Worked solution (30 min)

Build a planner-by-week panel with arm, weeks since exposure, WMAPE at lag 7, unit fill rate, and override counts.
Estimate the effect by weeks since exposure and, separately, by calendar week, and plot both against each other.
If exposure was staggered, compare cohorts at matched exposure age; if it was simultaneous, state that novelty is not separable in this design and name the design change that would have separated it.
Compute the system lag directly: median inbound lead time from fct_shipment_leg where direction = 'inbound', plus the review period, and compare it against the observed six-week onset.
Write the pre-registration: forecast metrics from week 1 on their own clock, service metrics from the first week after two replenishment cycles, primary defined on the post-burn-in span.

Expected result: The decaying forecast gain cannot be attributed to novelty from a single simultaneous launch; separating it requires staggered exposure or the override-volume mechanism check. The six-week onset in fill rate is consistent with the replenishment lag and is not evidence against a real effect. The pre-registered readout is a post-burn-in window of at least two replenishment cycles for service, with the forecast metric reported on its own clock.

Verify it yourself

The onset week for fill rate should approximately equal median lead time plus the review period; service moving faster than that means something other than the tool is moving it.
Override volume per planner per week distinguishes the two decay stories on its own and needs no modelling.
An A/A replay on the pre-period, cut the same way by week, should show no week-shaped pattern; a pattern there means the weekly decomposition is picking up seasonality rather than exposure.

Follow-up

Planners cover each other's portfolios during absence and sit in the same weekly review. What does that do to a planner-level randomisation?
Weeks 1-3 contained a promotion. How would you test whether the 6% is a promotion effect rather than novelty, using only data you already have?

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 a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.

Day 1 — Design one test end to end on paper

Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
State in advance what you will do if the primary metric is flat while a secondary metric is significant.

Deliverable: A one-page test design with a decision rule written before launch.

Day 2 — Power arithmetic until it is automatic

Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.

Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.

Day 3 — Variance and the unit-of-analysis problem

Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.

Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.

Day 4 — Validity threats you can actually test for

Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.

Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.

Day 5 — When randomization is not available

Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.

Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.

Day 6 — The readout query

Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.

Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.

Day 7 — Present it to someone who will not read the appendix

Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
Rewrite your opening line so the recommendation lands before any methodology.

Deliverable: A one-page readout whose first line is the recommendation.

Rigour against a deadline

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

Tell me about a time you received constructive feedback and how you responded.

Medium · behavioural and stakeholder questions

Approach

Quantify the outcome, including what you would not claim credit for.
Name the disagreement or constraint, and how you resolved it with evidence.
Close with what you would do differently, concretely.

Follow-up

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

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?

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?