Interview guides · Aurora Energy Research

Aurora Energy Research Data Scientist Interview Questions & Guide 2026

Data scientist prep for Aurora Energy Research: practice defining a supply chain and logistics metric, picking its guardrails and defending the tradeoff.

The 60-second brief

As a Data Scientist at Aurora Energy Research, you play a crucial role in harnessing data to drive insights that shape the energy sector's future. This position is integral to developing data-driven products and solutions that inform stakeholders about market trends, policy impacts, and operational efficiencies. Your analytical skills will not only support internal teams but also impact clients who rely on your insights to navigate complex energy markets.

Scope your preparation by the data you would actually touch, because the title will not tell you. A seat that lives in event logs and weekly readouts rewards fluency in aggregation and metric definitions; a seat that owns a model in production rewards fluency in train/serve skew, retraining cadence and drift monitoring. The fastest way to find out which one you are interviewing for is to ask what the team shipped last quarter and what it gets paged about.

Focus areas

Evaluate forecasts at the lag ordering actually uses
Join daily snapshots to shipment events safely
Trace an on-time miss to one node

Overview

You will work alongside a talented team that values collaboration and innovation. The problems you tackle will be dynamic, ranging from predictive modeling to optimization challenges, directly influencing the strategic direction of the company's energy research initiatives. The complexity of energy markets, combined with the scale of data at your disposal, makes this role both challenging and rewarding.

Candidates can expect to engage with real-world data that informs significant decisions across the energy landscape, making your contributions vital to the success of both Aurora Energy Research and its clients.

The Aurora Energy Research interview process

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

Initial Screening

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What to demonstrate

Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice

Technical Interviews

This round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.

What to demonstrate

Whether your row counts survive each join, and whether you notice on your own when they do not
Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
Reaching a defensible answer inside the window instead of a refined one after it

How to prepare

Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither

Case Studies

A case has a fixed clock, and a good deal of what is being scored is how you spend it. Thirty to forty-five minutes buys one pass across the whole problem or a deep read of one part of it, and choosing between those is the work rather than a compromise forced on you. Announce the shape early: the structure you are using, the branch you think carries the decision, and what you are setting aside. An answer that is thorough for the first third and silent on the recommendation reads worse than one that is rougher throughout and lands.

What to demonstrate

Whether a visible structure appears in the opening minutes and survives the rest of the case
Whether the depth goes to the branch that carries the decision, rather than the branch you find most comfortable
Whether you say what you are leaving out and why, instead of quietly omitting it and hoping nobody asks

How to prepare

After each practice case, write down the branches you chose not to open and the reason for each, then check whether you said any of them out loud while the case was running. A branch you only cut privately reads to the interviewer as one you missed.
Redo a case you have already worked in half the time, deciding in advance which single branch you keep, then compare which version a listener would find more useful.
Write a two-sentence opening you can reuse, holding the restated question and your plan for the available time, and deliver it within the first ninety seconds of every practice run.

Behavioral Interviews

This round decides whether you owned a decision or watched one happen nearby. Interviewers for data roles listen for the point where the analysis stopped being a report and started changing what someone did, so build each story around that hinge: what was going to happen by default, what you found, and what happened instead. The most common weakness is a story that ends at delivery. If you can name the decision your work changed and the number that moved because of it, most follow-ups become easy.

What to demonstrate

Whether the decision was yours to influence, or whether you are narrating a team outcome in the first person
The counterfactual: what would have been done without your analysis, and why that default was worse
How far your involvement ran past the handoff, and whether you checked that the change did what you predicted

How to prepare

Pick three projects and write one sentence for each naming the decision-maker, the choice in front of them, and what they chose after seeing your work. If you cannot name a person and a choice, the story is not ready for this round.
Reconstruct the baseline for your strongest project from the original query or dashboard rather than memory, so the before-number survives a follow-up asking where it came from.
Prepare an honest version of a project where your recommendation was overruled, including what you did with the analysis afterwards.

Discussions with Team Leaders

Because the format is not fixed, prepare the reasoning rather than the ritual. Nearly every version of this round draws on the same underlying material: a design you can defend, a metric you can define exactly, an analysis whose assumptions you can state out loud. Only the wrapper changes, whether that is a take-home, a live case, a deep dive on past work, or a rough estimate on a whiteboard. Answers rehearsed to fit one shape stall the moment the shape differs. Practise naming the assumption behind a number, then saying how much the conclusion moves if that assumption is wrong.

What to demonstrate

Whether your justification for a method survives the question 'why not the simpler thing', including when the simpler thing would have worked
Precision under pressure: what exactly counts as an active user, a conversion or a success, over what window, with what exclusions
Whether you carry an argument through to a recommendation instead of stopping at a list of tradeoffs

How to prepare

For each project you plan to mention, write the metric definition in one sentence: numerator, denominator, time window, exclusions. Say it out loud once, because vagueness shows up in speech before it shows up on paper.
Rehearse the same project at three lengths: two minutes, ten minutes, and a deep dive on one technical decision. Cutting live is harder than it sounds.
For your headline result, write down what would have had to be true for it to be wrong, and how you ruled that out.

Where candidates lose points

Treating shipped units as demand

Shipments are censored at available inventory: on a stockout day the recorded quantity is a supply ceiling, not customer intent, and orders that were never placed because the item showed as unavailable leave no row at all. A forecast fitted on that history learns the constraint, under-forecasts the fast movers that stock out most often, and produces the replenishment that causes the next stockout, so the error compounds in one direction rather than averaging out. The fix is to model demand_qty rather than shipped_qty, flag stockout days with stockout_flag and treat them as censored (fit with a censored likelihood, or estimate unconstrained demand from uncensored periods and comparable locations), and to report how much of the history was censored alongside any accuracy number.

Scoring intermittent demand with MAPE

MAPE is undefined whenever the actual is zero, which is most days for a C-class item at a forward-stocking location, and it is asymmetric even where it is defined: under-forecasting is bounded at 100 percent error while over-forecasting is unbounded. Optimising it therefore drives systematic under-forecasting on exactly the items whose stockouts are most expensive, and the bias is invisible in the headline because the zero-actual rows were dropped before averaging. Use WMAPE (sum of absolute errors over sum of actuals), a scaled error such as RMSSE, or a pinball loss at the service quantile the policy targets, and always state the aggregation level and forecast lag, because the same series scores very differently at daily SKU-store level and weekly SKU-region level.

Treating a non-significant result as proof of no effect

Say whether the confidence interval excludes the effect sizes you would have cared about. If it does not, the honest reading is that the test was underpowered, so report the minimum detectable effect the design could have found and what sample size would resolve it.

Answering a product-sense question with a list of features

Answer with a decision and the measurement that would settle it: the hypothesis, the primary metric, the guardrails, and the result that would make you not ship. A feature brainstorm cannot be wrong, which is exactly why it earns no points.

Questions & practice

Can you discuss a project where you used machine learning to solve a problem?

Medium · machine learning and modelling

Approach

Frame the prediction: the label, the moment of prediction, and the action it triggers.
Pick an evaluation metric that matches the cost of each error type, not a default.
Set a baseline first, so any model has something honest to beat.

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?

How would you implement a decision tree from scratch?

Medium · machine learning and modelling

Approach

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

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?

As-of join snapshots to order lines without merge_asof

Medium · as-of join · fan-out · searchsorted

You have fct_order_line (order_line_id, sku_id, ship_from_location_id, actual_ship_at_utc, shipped_qty, shipment_id) and fct_inventory_daily (inventory_date, sku_id, location_id, available_qty). For every shipped line, attach available_qty from the latest snapshot strictly before the ship date for that exact sku and node, plus the shipment's delivery timestamp from fct_shipment_leg (leg_id, shipment_id, delivered_at_utc, leg_status). The output must have exactly one row per input order line. pandas.merge_asof is not available; implement the as-of match yourself.

Approach

Collapse fct_shipment_leg to one row per shipment_id before joining anything. A shipment is one or more legs, so a direct line-to-leg join multiplies every line by its leg count and quietly inflates every sum computed afterwards.
Define the shipment-level delivery as the maximum delivered_at_utc across its legs, and set it null if any leg is not delivered, since the customer has the order only when the last leg lands.
Sort the snapshot frame by (sku_id, location_id, inventory_date) and the line frame by the same key plus ship date, then use np.searchsorted with side='left' on the sorted dates within each key group to find the insertion point; the matching snapshot is the row at position minus one.
Guard the boundary explicitly: an insertion point of 0 means no snapshot exists before that ship date, and the result must be null rather than the first available future snapshot. Count those lines and report them.
Assert the output row count equals the input line count immediately after each merge, before any aggregation. Row-count drift is the only symptom a silent fan-out produces, and it is invisible once the frame has been grouped.

Worked solution (30 min)

Aggregate legs by shipment_id to produce delivered_at_utc as the max, leg_count, and a delivered_all flag from leg_status.
Left join that one-row-per-shipment frame onto fct_order_line by shipment_id and assert the row count is unchanged.
Sort snapshots and lines by the composite key, then compute per-group insertion points with np.searchsorted and subtract one.
Mask positions below zero to null, take available_qty at the remaining positions, and attach it as available_qty_prior.
Validate on a single sku-location pair by printing its snapshot dates and one line's ship date and confirming the chosen date by eye.

Expected result: A frame with exactly as many rows as the input order lines, carrying available_qty_prior (null for lines with no earlier snapshot), delivered_at_utc and leg_count, plus a printed count of unmatched lines.

Verify it yourself

Assert len(output) equals len(fct_order_line) after every join step, not only at the end.
Assert every non-null matched snapshot date is strictly less than the line's ship date, and that no snapshot date for the same key falls between the match and the ship date.
Compare against a slow brute-force loop over 200 sampled lines; the two must agree on every row.
Confirm the unmatched count equals the number of lines whose ship date precedes the first snapshot for their sku-location pair.

Follow-up

The snapshot is taken at the node's local end of day and actual_ship_at_utc is UTC. Where does that break the strictly-before rule and what do you need from dim_location to fix it?
How would you extend this to allocate each leg's linehaul cost back to the order lines it carried?
What changes if a line ships in two partial shipments?

Write a function to calculate the mean and median of a list of numbers.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Check whether any join is one-to-many before aggregating, or the sums inflate.
State the window function and its partition and ordering out loud before writing 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?

Explain how you would optimize a slow-running SQL query.

Medium · sql and data manipulation

Approach

State the window function and its partition and ordering out loud before writing it.
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.

Follow-up

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

Perfect order rate against the original promise in local time

Hard · timezone boundaries · order-grain rollup · semi-join

Compute weekly perfect order rate at order grain. An order qualifies only if every fct_order_line has line_status = 'shipped_full', every line's actual_delivery_at_utc falls on or before original_promised_delivery_date at the ship-from node's local end of day (dim_location.timezone holds IANA names), and no fct_shipment_leg reached through shipment_id carries exception_code in ('damage','address_issue') or leg_status in ('refused','lost'). The denominator is orders whose original_promised_delivery_date lands in the week. Undelivered lines fail. Publish with a fourteen-day lag and declare invoice accuracy as out of scope.

Approach

Convert the event into local time rather than comparing against a UTC-anchored deadline: (actual_delivery_at_utc AT TIME ZONE 'UTC' AT TIME ZONE loc.timezone)::date <= original_promised_delivery_date. Casting the promise date to a timestamp puts the cut-off at UTC midnight starting the promise day, which is up to a full day early and wrong in both directions depending on the node's offset.
Evaluate the three components as booleans at line grain, then roll to the order with BOOL_AND, coercing a NULL actual_delivery_at_utc to FALSE explicitly so an undelivered line fails rather than propagating NULL and dropping the order out of the comparison.
Test the shipment exceptions with EXISTS against fct_shipment_leg, never with a join. One shipment has many legs and one order has many lines, so a join multiplies the order into the denominator and changes the metric.
Aggregate to order grain first, then count qualifying orders over orders promised in the week. The rate is orders over orders; a line-level average is a different and easier metric.
Apply the publication lag by restricting to weeks whose promise dates are at least fourteen days old, and emit the three component pass rates beside the headline so any movement is attributable to completeness, timeliness or exceptions.

Worked solution (40 min)

CTE line_flags: join fct_order_line to dim_location on ship_from_location_id, producing is_full, is_on_time using the AT TIME ZONE conversion with COALESCE to FALSE, and has_exception from an EXISTS over fct_shipment_leg.
CTE order_flags: GROUP BY order_id with BOOL_AND(is_full), BOOL_AND(is_on_time), BOOL_AND(NOT has_exception) and MIN(original_promised_delivery_date) for bucketing.
Aggregate per DATE_TRUNC('week', promise date): COUNT() as denominator, COUNT() FILTER (WHERE all three) as perfect_orders, and the three component counts.
Restrict output to weeks ending at least fourteen days ago.
Re-run the on-time expression once with a naive UTC comparison and record the delta as evidence the conversion is live.

Expected result: One row per week with orders_in_denominator, perfect_orders, rate, and three component pass rates, where the rate is less than or equal to every component rate and weeks inside the fourteen-day lag are absent from the output.

Verify it yourself

perfect_orders is less than or equal to the count passing any single component, for every week.
Switching the deadline to a naive UTC comparison shifts the on-time component by roughly the share of orders at nodes offset from UTC. No change at all means the conversion is not being applied.
The denominator equals COUNT(DISTINCT order_id) over orders promised in the week and does not change when the legs EXISTS clause is removed.
No order_id appears in more than one week.

Follow-up

All three component rates are flat but perfect order fell two points. How is that arithmetically possible, and what does it tell you about where the failures now land?
A node sits at UTC+13 and many orders are promised on the last day of the month. What does that do to your weekly and monthly buckets?
How do you handle an order whose lines ship from two nodes in different timezones, and which node's clock owns the promise?

If given a dataset with anomalies, how would you identify and address these issues?

Medium · product sense and metrics

Approach

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

Follow-up

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

Describe how you would approach a project to forecast energy demand.

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.
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?
What would you do if the primary metric and the guardrail moved in opposite directions?

How do you prioritize your work when facing tight deadlines?

Medium · product sense and metrics

Approach

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

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?

What steps would you take to analyze the impact of a new energy policy?

Medium · product sense and metrics

Approach

Fix the population and the time window before naming any metric.
Decompose the metric into the rates that drive it, and say which one you would check first.
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?
Which segment would you cut first, and what would that rule out?

Describe a complex data manipulation task you have completed.

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.
State your assumptions explicitly before working the problem.

Follow-up

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

Success metric for opening one forward-stocking node

Medium · synthetic control · risk pooling · power

The network will open one forward-stocking location at echelon 3, replenished by an existing regional DC. There is one treated node and about thirty candidate comparison nodes. Using fct_order_line (ordered_at_utc, actual_delivery_at_utc, ship_from_location_id, line_status), fct_inventory_daily (on_hand_qty, standard_cost_cents) and fct_shipment_leg (direction, shipped_units, linehaul_cost_cents, accessorial_cost_cents, delivered_at_utc), define the primary metric, the guardrail that catches the working-capital cost of de-pooling, and the readout design. Say what this sample cannot detect.

Approach

Anchor the primary on what the node is for: P90 order cycle time for the lines it serves, taken over the pooled line-level distribution rather than as a mean of daily percentiles, with never-delivered lines reported as a censored count instead of dropped.
Make the inventory guardrail network-wide, not node-local. Splitting one pooled stock into two locations raises total safety stock at the same service level; under independent demand, equal service and equal lead times the square-root law puts the factor at sqrt(2) on the safety component, so measure parent and new node combined at cost.
Add a freight guardrail across both the new inbound interfacility leg and the outbound legs, because the opening adds a movement that any node-local outbound cost metric will miss entirely.
Choose a design suited to one treated unit: a synthetic control or matched-pair comparison built from donor nodes on pre-period cycle time, volume, SKU mix and lane structure, with the donor pool and matching variables frozen before the readout.
Set the burn-in at two full replenishment cycles, and book the fill-and-build inventory into the cost side rather than letting it contaminate the service read.
State the limit rather than implying precision: with one treated unit there is no cross-unit variance, so a placebo distribution over the donors is the only inferential statement available, and effects smaller than the donor spread cannot be distinguished from node noise.

Worked solution (35 min)

Build a weekly node panel covering at least 26 pre-period weeks: P90 cycle time, line volume, fill rate, on-hand at cost, delivered cost per unit.
Screen the donor pool, dropping nodes that opened, closed or changed parent_location_id inside the window, then fit synthetic weights on pre-period P90 and volume only.
Check pre-period fit, then run placebo assignments across every donor to build the distribution of pseudo-effects.
Estimate the post-period effect from the burn-in end, and compute the working-capital series as parent plus new node combined.
Report the effect against the placebo distribution together with the minimum effect this design could have detected.

Expected result: A readout design where the primary is P90 order cycle time for lines shipped from the treated node, estimated against a synthetic control fitted on pre-period P90 and volume; guardrails are combined parent-plus-node on-hand at cost and delivered cost per unit across the added interfacility leg plus outbound; a two-replenishment-cycle burn-in is excluded from the service read and charged to cost; and inference is stated to rest on a placebo distribution over roughly thirty donors, so effects inside the donor spread are declared undetectable.

Verify it yourself

Pre-period fit: the synthetic series tracks the treated node's P90 within the donor-to-donor spread before the opening, otherwise the estimate is not usable and no amount of post-period data repairs it.
The working-capital guardrail is computed on parent plus node combined; computed node-only it always shows an increase and carries no information.
Computing P90 as a mean of daily P90s produces a different and generally flatter series than the pooled line-level percentile; show both once to prove which one the readout uses.

Follow-up

A donor node runs a promotion during the post period. What do you do, and at what point did you have to decide it?
The service gain is real and the cost guardrail is also up. Who decides, and on which number?

OEE fell six points on a constraint work centre

Medium · oee decomposition · mix shift · manufacturing

OEE on a constraint work centre fell from 0.72 to 0.66 over one month and plant leadership has requested maintenance spend. From fct_production_run (planned_production_seconds, run_seconds, unplanned_downtime_seconds, changeover_seconds, ideal_cycle_seconds_per_unit, planned_qty, total_qty, good_qty, scrap_qty, rework_qty, downtime_reason_code, sku_id, run_status) and dim_sku, decompose the six points into availability, performance and quality, then decide whether the performance term is a machine problem or a SKU mix problem. Deliverable: the decomposition and one recommendation.

Approach

Rebuild OEE by re-summing: SUM(good_qty * ideal_cycle_seconds_per_unit) over SUM(planned_production_seconds) for each month. Averaging per-run OEE gives a five-minute run the same weight as an eight-hour run and produces a figure that belongs to no work centre.
Compute the three factors on the identical row set: availability = SUM(run_seconds) / SUM(planned_production_seconds); performance = SUM(total_qty * ideal_cycle_seconds_per_unit) / SUM(run_seconds); quality = SUM(good_qty) / SUM(total_qty). Verify their product equals the re-summed OEE; if it does not, the three calculations are running over different rows.
Attribute the move on the log scale, where the factors are exactly additive: ln(OEE1/OEE0) = ln(A1/A0) + ln(P1/P0) + ln(Q1/Q0). This removes any argument about how to split the cross-terms and gives each factor a defensible share of the six points.
If performance carries the move, separate a slower machine from a harder product mix before recommending anything. ideal_cycle_seconds_per_unit is SKU-specific, so recompute month two's performance holding month one's SKU volume mix fixed. Performance that is flat under a fixed mix means the line runs as fast as ever on slower SKUs.
Interrogate the denominator itself. planned_production_seconds excludes unstaffed hours, so adding or removing a shift changes OEE with nothing physical having changed, and whether changeover_seconds sits inside or outside planned time decides whether a changeover appears as an availability loss at all.

Follow-up

Availability fell and downtime_reason_code is mostly 'material_shortage'. Is that a maintenance problem, and who owns it?
rework_qty is 400 against total_qty of 10,000. Are reworked units counted once or twice in total_qty, and how does each answer change the quality factor?
What guardrail stops a plant from hitting an OEE target by scheduling long runs of its fastest SKU?

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.

Getting an analysis acted on

Work that nobody used is a common and unflattering pattern in data careers, and interviewers probe for it. Have a story about an analysis that changed a decision, and be specific about how you got it in front of the person who could act. Also have one about work that went nowhere, with your reading of why.

How do you handle missing data in a dataset?

Medium · behavioural and stakeholder questions

Approach

Pick a story where you drove the decision, not one where you observed it.
Quantify the outcome, including what you would not claim credit for.
State the situation in two sentences and spend the rest on your reasoning.

Follow-up

How did you know the outcome was caused by your change?
What would you do differently if you ran that project again?

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?

Tell a sponsor the effect cannot be measured in six weeks

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

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

Approach

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

Follow-up

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