Interview guides · GE Aerospace

GE Aerospace Data Scientist Interview Questions & Guide 2026

GE Aerospace data scientist prep: probability, sampling distributions, and stating the assumption behind every test you run.

The 60-second brief

A Data Scientist at GE Aerospace sits at the intersection of cutting-edge aviation engineering and advanced data analytics. In this role, you are responsible for transforming massive, complex datasets—ranging from high-frequency jet engine sensor outputs to manufacturing quality metrics and supply chain logistics—into actionable insights. Your work directly impacts flight safety, engine efficiency, and predictive maintenance programs that keep commercial and military aircraft flying safely around the globe.

Nearly every loop contains a round whose deliverable is a recommendation to someone non-technical. Practise stating a conclusion, the confidence attached to it, and the cost of being wrong in each direction, because that triple is the artifact being graded.

Focus areas

Separate true demand from censored, stocked-out sales
Trace an on-time miss to one node
Price a service-level change in working capital

Overview

The scale of data at GE Aerospace is massive. Every flight generates gigabytes of operational data, and your models will help predict component failures before they occur, optimize fuel consumption, and streamline production lines. This means your data pipelines and machine learning models must be exceptionally robust, highly accurate, and designed to operate in a high-stakes, safety-critical environment.

Joining GE Aerospace as a Data Scientist means collaborating with world-class engineers, software developers, and product managers. You will not just build models in isolation; you will deploy them to solve real-world physical and digital challenges, making this one of the most intellectually stimulating and impactful data science roles in the industrial sector.

The GE Aerospace interview process

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

Video Interview/Recruiter Call

Most candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.

What to demonstrate

Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
The substance of the questions you ask back, which an experienced screener reads as a level signal

How to prepare

Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered

Technical Conversations

A handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.

What to demonstrate

Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.

How to prepare

Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows

Panel Interviews

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

What to demonstrate

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

How to prepare

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

Where candidates lose points

Sizing safety stock as z times sigma_D times the square root of lead time

That form assumes lead time is deterministic. When lead time itself varies, the standard deviation of demand over lead time is sqrt(L_bar * sigma_D^2 + D_bar^2 * sigma_L^2), and the second term dominates whenever supply is unreliable, so the familiar formula can understate the requirement severalfold for a long, variable inbound lane. Two further preconditions are routinely forgotten: demand is assumed independent across periods, which promotions and order batching break, and z maps to cycle service level (the probability of no stockout in a replenishment cycle), not to fill rate, which additionally depends on order quantity through the unit normal loss function. Quoting a z-derived number as a fill rate overstates achieved service, and the gap widens as order quantity shrinks.

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.

Naming a model class before naming the deployment constraints

Set out the latency budget, the label delay, the retraining cadence, the interpretability requirement and the number of labelled examples, then pick the model that fits them. A boosted-tree answer to a problem where each decision must be explained to the affected user is a well-executed answer to the wrong question.

Stopping an experiment the moment it crosses significance

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

Questions & practice

What is the difference between L1 and L2 regularization, and when would you use one over the other?

Medium · statistics and probability

Approach

Translate the result into the decision it informs, in one plain sentence.
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

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

Can you explain the bias-variance tradeoff and how it influences your model selection?

Medium · machine learning and modelling

Approach

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

Follow-up

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

Explain how clustering algorithms work, and how you would evaluate the performance of an unsupervised clustering model.

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

Follow-up

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

Recover unconstrained demand from stockout-censored history

Hard · censoring · maximum likelihood · em algorithm

A legacy extract has only inventory_date, sku_id, location_id, shipped_qty and stockout_flag; demand_qty was not populated before a cutover date. On a stockout day, shipped_qty is a lower bound on that day's demand. Model daily demand per sku-location as Poisson and fit its mean by maximum likelihood, treating stockout days as right-censored observations. Return the fitted mean per cell alongside the naive mean of shipped_qty and the censored share. Then validate against the post-cutover window where demand_qty exists.

Approach

Write the likelihood before any code. Uncensored days contribute the Poisson pmf at the observed count; stockout days contribute the survival probability P(X >= y), because all you learned is that demand was at least what you managed to ship.
Solve it as an EM fixed point rather than reaching for a general optimiser: the censored MLE equals the complete-data mean with each censored observation replaced by its conditional expectation, so iterate lambda_next = (sum of uncensored y + sum of E[X | X >= y, lambda]) / n until it stops moving.
Use the closed form for the conditional expectation rather than truncating an infinite sum: for a Poisson, sum over k >= y of k*p(k) equals lambda times P(X >= y-1), so E[X | X >= y] = lambda * P(X >= y-1) / P(X >= y) for y >= 1. That removes the tail-truncation error entirely.
Refuse to fit cells with too little signal. A sku-location with three non-zero days or with every day censored has no identifiable mean; return the naive figure with a flag rather than a confident number.
Validate on the post-cutover window where demand_qty is populated: fit the estimator on shipped_qty and stockout_flag alone, and compare both the censored estimate and the naive mean against the true mean of demand_qty.

Worked solution (45 min)

Split each cell's days into censored (stockout_flag true) and uncensored, and record the censored share.
Initialise lambda at the mean of shipped_qty over all days, which is a strict lower bound on the answer.
Iterate the EM update using scipy.stats.poisson.sf for the survival terms, stopping when the change in lambda falls below 1e-8 or after 500 iterations.
Assemble a per-cell frame with lambda_hat, naive_mean, censored_share, n_days and a converged flag; mark thin cells rather than fitting them.
On the post-cutover window, compute the true mean of demand_qty per cell and report the absolute error of lambda_hat against the absolute error of naive_mean.

Expected result: Per-cell lambda_hat that is greater than or equal to the naive mean of shipped_qty in every cell, with equality exactly when the cell has no censored days. The uplift grows with censored share. On the validation window, lambda_hat has lower mean absolute error against the true demand_qty mean than the naive figure does.

Verify it yourself

Assert lambda_hat >= mean(shipped_qty) for every cell; the EM fixed point guarantees this because E[X | X >= y] >= y, so any violation is an implementation bug.
Re-solve one cell by directly minimising the negative log-likelihood with a one-dimensional optimiser and confirm it agrees with the EM answer to at least six decimal places.
Simulate a cell with known lambda, censor it artificially at a known threshold, and confirm the estimator recovers lambda within Monte Carlo error while the naive mean does not.
Confirm cells with zero censored days return lambda_hat exactly equal to the sample mean, since the likelihood reduces to the ordinary Poisson case.

Follow-up

The fitted mean is 18 percent above the naive mean for A-class items and 2 percent above for C-class. Why would you expect that ordering?
The residual variance is three times the fitted mean. What does that break and what distribution would you move to?
A stockout is often caused by a demand spike that day. What does that do to your estimate and can you correct it?

What are the primary differences between NumPy arrays and standard Python lists in terms of performance and memory?

Medium · sql and data manipulation

Approach

Check whether any join is one-to-many before aggregating, or the sums inflate.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Say which table is the grain you start from, and join outward from it.

Follow-up

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

Given a sample dataset of engine sensor readings, how would you perform exploratory data analysis (EDA) to find anomalies?

Medium · sql and data manipulation

Approach

Compute rates by summing numerator and denominator separately, never by averaging rates.
State the window function and its partition and ordering out loud before writing it.
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?
How would you verify this result without re-running the same query?

Walk us through how you would optimize a slow-running SQL query or database transaction.

Medium · sql and data manipulation

Approach

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.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

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

Write a Python script to merge two complex datasets and filter out outliers based on rolling statistical averages.

Medium · sql and data manipulation

Approach

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

Follow-up

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

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.

Worked solution (20 min)

Filter fct_order_line to requested_ship_date inside the window and line_status <> 'cancelled_by_customer'; count the rows removed by that filter and keep the count.
Compute num = SUM(CASE WHEN actual_ship_at_utc::date <= requested_ship_date THEN shipped_qty ELSE 0 END) and den = SUM(ordered_qty) in the same SELECT.
GROUP BY ship_from_location_id, DATE_TRUNC('week', requested_ship_date) and join dim_location for location_code.
Add the network row from a second aggregate over the same base set: SUM(num) / SUM(den).
Report the excluded-line count and the substitution rule beside the rate so the number is auditable.

Expected result: One row per node-week with numerator, denominator and rate = numerator / denominator, plus a network row whose rate equals SUM(numerator) / SUM(denominator) across nodes and which will generally differ from the mean of the node rates.

Verify it yourself

Rate never exceeds 1. If it does, shipped_qty is being counted on lines whose ordered_qty was filtered out of the denominator.
Denominator per node-week matches a separate plain SUM(ordered_qty) with no CASE logic in it.
Dropping the largest node moves the network rate. If it does not move, the total is an average of rates rather than a re-summed ratio.

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?

Price a three-point service target against inventory turns

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

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

Approach

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

Worked solution (35 min)

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

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

Verify it yourself

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

Follow-up

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

An OEE target that makes the plant run the wrong SKUs

Medium · oee decomposition · guardrails · mix shift

A constraint work centre is put on an OEE target. Using 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, run_status) and fct_inventory_daily (on_hand_qty, demand_qty), define OEE precisely, decide whether planned changeover sits inside or outside the denominator, and name the guardrail that stops the target being met by running long batches of whatever is easiest. Defend the conflict rather than hiding it.

Approach

Write the metric exactly: SUM(good_qty * ideal_cycle_seconds_per_unit) over SUM(planned_production_seconds), re-summed for every roll-up, and show that it factors into availability times performance times quality so a movement is attributable before anyone argues about it.
Settle the changeover question in writing, because it decides gameability. Leaving planned changeover inside the denominator makes OEE fall whenever variety rises, which is the behaviour the target would then buy; excluding it protects mix but hides real capacity loss. Exclude it and carry changeover_seconds as its own reported series.
Use ideal_cycle_seconds_per_unit per SKU and work centre rather than a line average, since a line-average nameplate rate turns performance into a function of which SKU happened to run.
Set the guardrail on demand-weighted schedule adherence, good_qty against planned_qty at SKU level weighted by what the network is short of, paired with finished-goods days of supply for the SKUs that were skipped.
State the conflict plainly: a plant maximising OEE lengthens runs and drops small-volume SKUs, which raises the score and lowers service, so the two metrics are published together and the target is set on the pair, not on OEE alone.
Scope the metric to constraint work centres, because OEE on a non-constraint rewards making inventory nobody is waiting for, and scope is part of the definition rather than a footnote.

Follow-up

Availability rose and performance fell in the same week. Give two explanations and the query that separates them.
Where does rework_qty enter your definition, and what does that choice reward?

Unit fill rate fell four points in one region

Easy · fill rate · segment cuts · mix shift

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

Approach

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

Follow-up

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

Suggested practice checklist

Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.

Day 1 — Diagnostic, scored before you study anything

Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.

Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.

Day 2 — Largest gap: find the boundary rather than the subject

Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
Re-solve one of them from memory four hours later, on paper, with nothing open.

Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.

Day 3 — Largest gap: drill the blocking sub-skill

Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
Have someone else read your one-sentence rule and find the precondition you left out.

Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.

Day 4 — Second gap, plus maintenance on your strongest area

Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.

Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.

Day 5 — The gap that is not a skill

Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
Deliver one answer again with a hard 90-second limit to force structure before detail.

Deliverable: Two recordings with a counted improvement in time-to-first-question.

Day 6 — Retest under day-one conditions

Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
Write which single block you would still lose the offer on.

Deliverable: A second scored rubric placed next to the first, with one named remaining risk.

Day 7 — Full loop under interview conditions

Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.

Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.

The project you argued against

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

How would you interpret a ROC-AUC curve to a non-technical stakeholder?

Medium · behavioural and stakeholder questions

Approach

Name the disagreement or constraint, and how you resolved it with evidence.
State the situation in two sentences and spend the rest on your reasoning.
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?

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?

Defend a finding that the expedite program bought nothing

Medium · defending findings · counterfactual reasoning · landed cost

Over two quarters, expedite_premium_cents on outbound legs in fct_shipment_leg rose from 0.4 to 1.3 percent of landed cost, while perfect order rate moved from 91.2 to 91.5 percent, inside the week-to-week spread. The transport lead who sponsored the expedite program disputes the finding in a review in front of his director, arguing that your window contains a port disruption that would have made service worse without the spend. Present the finding, say what you concede on the spot, say what you hold, and name the evidence that would change your conclusion.

Approach

Restate his objection in its strongest form before answering it, because a counterfactual worsening is a legitimate argument and treating it as an excuse ends the conversation.
Separate what you measured from what you claimed: the data show no detectable service gain, not that expedite has no effect, and the difference is the entire argument.
Test his hypothesis with the data you already have rather than defending in the abstract: split legs by exception_code = 'customs_hold' and by lane, and compare expedited against non-expedited legs on the same lanes in the same weeks, since if expedite were holding the line the expedited lanes should show a service gap over comparable non-expedited ones.
Concede what is true: without a holdout you cannot rule out a protective effect, and the pre-period is contaminated by the disruption, so the honest statement is an upper bound on the gain rather than a zero.
Hold the part that survives: the spend is real, it is concentrated in a small set of lanes, and nobody set a decision rule for when a leg gets expedited, which is a controllable problem independent of the counterfactual.
Name the next measurement: a lane-level staggered switch-off with a stated burn-in, and say what it would cost and how long it would take.

Follow-up

He offers to run the switch-off only on his two best lanes. Why is that a problem, and what do you counter with?
His director asks you for a yes or no on cutting the budget today. What do you say?