As a Data Scientist at the American Bureau Of Shipping (ABS), you are stepping into a pivotal role at the intersection of maritime safety, engineering, and advanced artificial intelligence. ABS is a leading global classification society, and its mission is to safeguard life, property, and the natural environment. In this role, particularly within the AI Practice Team, you will leverage vast amounts of vessel telemetry, historical safety records, and operational data to build predictive models that directly impact the future of the maritime industry.
Your work will have a tangible impact on global supply chains and environmental sustainability. By developing machine learning models for predictive maintenance, route optimization, and risk assessment, you help shipowners and operators make data-driven decisions that prevent catastrophic failures and reduce carbon footprints. The scale and complexity of the data you will handle are immense, requiring a blend of rigorous statistical thinking and practical engineering skills.
You can expect an environment that values deep technical expertise but also requires a high degree of adaptability. is actively modernizing its digital capabilities, meaning you will often act as a pioneer within the organization. You will be expected to translate complex AI concepts to stakeholders who may have traditional engineering backgrounds, making your ability to communicate just as critical as your ability to code.
Recruiter Screen
reportedA 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 Interview
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Team-Fit Interview
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
Behavioral Interview
reportedMost of the weight in this round sits on the disagreement questions. Data work routinely produces an answer someone senior did not want, and the interviewer is trying to learn what you do in that hour. Both failure modes are common: folding as soon as a director pushes back, and treating the pushback as ignorance to be corrected with a better chart. A strong answer usually contains a specific thing the other person knew that you did not, and describes how you found out whether it changed the conclusion.
What to demonstrate
- Whether you can state the other side's argument accurately before you explain why you disagreed
- What you treated as evidence during the disagreement, such as a rerun under their assumption or a holdout check, rather than persuasion technique
- Whether you distinguish being overruled from being wrong, and can give an example of each
How to prepare
- Write out one disagreement where you turned out to be wrong, and say what in the data misled you. Candidates prepare the story where they were right, and the follow-up asks for the other one.
- For your main disagreement story, be ready to say what result would have made you drop your position. If no such result exists, you were not arguing from the data.
- Practise stating the opposing position out loud in one sentence the stakeholder would accept, then continue the story.
PracHub editorial advice for the preparation topics above.
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 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.
Optimising accuracy on a heavily imbalanced target
State the base rate first, then choose the metric from the relative cost of a false positive against a false negative: precision and recall at the operating threshold, PR-AUC, or expected cost. At a 1 percent positive rate, predicting the majority class for everyone scores 99 percent accuracy and is worthless.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the concept of cross-validation and why it is important for ti…
Explain the concept of cross-validation and why it is important for time-series data.
Approach
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Say how the offline result would be validated online before it is trusted.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
What is the difference between a random forest and a gradient boosting…
What is the difference between a random forest and a gradient boosting machine, and when would you use each?
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.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
Weighted forecast error at the lag ordering actually consumes
You are given fct_inventory_daily as a DataFrame with inventory_date, sku_id, location_id, demand_qty and forecast_qty_lag7. Replenishment is decided weekly per SKU per node, so score the forecast at that grain over a trailing 8 weeks. WMAPE is the sum of absolute weekly errors over the sum of weekly demand; weighted mean percentage error is the same ratio with the error left signed. forecast_qty_lag7 is null before a series existed. Return one row per location_id carrying both statistics, the shared denominator, and the count of rows excluded. No forecasting library.
Approach
- Decide the null rule before writing any aggregation: a sku-location-week where any constituent day has a null forecast must be dropped whole. Signed error here is forecast minus demand, so summing 7 days of demand against the 5 days of forecast that survived leaves the numerator short by two days of forecast and drives the ratio negative, which reads as systematic under-forecasting the model never committed.
- Aggregate demand_qty and forecast_qty_lag7 to sku x location x week first, then difference. Differencing daily and summing the absolute values afterwards answers a different question, since intraday timing error cancels inside a week and the ordering decision never sees it.
- Build week buckets from inventory_date with a fixed anchor (a Monday-start ISO week or a rolling 7-day offset), and use the same buckets for both series so no partial week sits at either end of the 8-week window.
- Compute the two statistics by summing numerator and denominator to the location level and dividing once. Never average sku-level ratios: a C-class item with 3 units of weekly demand would otherwise carry the same weight as an A-class item with 3,000.
- Return the denominator and the excluded row count as columns, not as a printed aside, so a reader can tell a genuinely accurate node from one with almost no scored history.
Worked solution 20 min
- Filter to the trailing 8 complete weeks by inventory_date, then drop any sku-location-week containing a null forecast_qty_lag7 and record how many rows that removed.
- Group by sku_id, location_id, week and sum demand_qty and forecast_qty_lag7 into weekly totals.
- Add abs_err = (forecast - demand).abs() and signed_err = (forecast - demand) on the weekly frame.
- Group by location_id and sum abs_err, signed_err and demand_qty; divide the first two by the third to get wmape and wmpe.
- Attach the denominator and the excluded count, and sort by denominator descending so the nodes that matter read first.
Follow-up
- The same series is scored at lag 28 and WMAPE roughly doubles. Is that a model problem or an expected property of the horizon?
- A node shows WMAPE of 0.35 and bias of 0.01. What can you and can you not conclude about its inventory position?
- How would you report accuracy for a SKU whose weekly demand is zero in 40 of the 52 weeks?
Explain the difference between an inner join, a left join, and a full …
Explain the difference between an inner join, a left join, and a full outer join in SQL.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- State the window function and its partition and ordering out loud before writing it.
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 function to clean a dataset by removing outliers based …
Write a Python function to clean a dataset by removing outliers based on the interquartile range (IQR).
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.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
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?
How do you design a pipeline to ingest and process streaming IoT data?
How do you design a pipeline to ingest and process streaming IoT data?
Approach
- 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.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Perfect order rate against the original promise in local time
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.
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?
How do you optimize a Pandas script that is running out of memory on a…
How do you optimize a Pandas script that is running out of memory on a large dataset?
Approach
- 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.
- State what result would change your recommendation, so the answer is falsifiable.
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?
How do you prioritize your tasks when you are assigned multiple urgent…
How do you prioritize your tasks when you are assigned multiple urgent data requests at once?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- 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
- 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?
Cut variance on a safety-stock test with CUPED and strata
You are testing a new safety-stock formula on 300 SKU-location cells inside one region, randomised 150/150. The outcome is eight-week unit fill rate per cell from fct_order_line; you also have 26 weeks of pre-period fill rate per cell, and each cell carries abc_class and xyz_class in dim_sku. The cell-level correlation between pre-period and post-period fill rate is 0.7. Show the CUPED adjustment, state exactly what it does to the standard error, and say which cells it will fail on and why.
Approach
- Define the adjusted outcome: Y* = Y - theta * (X - Xbar), where X is the pre-period cell fill rate and theta = Cov(Y, X) / Var(X). Because randomisation makes X independent of assignment, the treatment effect estimate is unbiased for any theta; theta only controls how much variance is removed.
- Quantify the win rather than asserting it: Var(Y*) = Var(Y) * (1 - rho^2) = 0.51 * Var(Y), so the standard error falls by a factor of sqrt(0.51) = 0.71, the MDE falls 29%, and the same precision would otherwise have needed 51% of the cells.
- Estimate theta pooled across both arms on the observed data. Fitting it per arm re-introduces a treatment-dependent term into the adjustment; the O(1/n) bias from estimating theta at all is negligible at 300 cells but should be named rather than ignored.
- Stratify the randomisation itself on abc_class by xyz_class and fit with stratum fixed effects. Strata remove between-class variance that a single pre-period covariate does not, and XYZ class is precisely the axis along which demand variability, and therefore fill-rate variance, differs.
- Name where it fails. Fill rate is a ratio whose denominator is random and small for C and Z cells, so the pre-period value is a noisy estimate of the cell's true rate, rho collapses and the adjustment buys little; a cell with zero pre-period demand has no covariate at all. Handle the ratio by adjusting numerator and denominator and applying the delta method for the variance, never by averaging cell-level ratios.
Worked solution 30 min
- Build a cell-level table: 26-week pre-period fill rate X, 8-week post-period fill rate Y, arm, abc_class, xyz_class, and pre-period ordered_qty as a weight.
- Regress Y on X pooled across arms to obtain theta, then compute Y* = Y - theta * (X - Xbar).
- Estimate the effect by regressing Y* on treatment with abc by xyz stratum fixed effects and heteroskedasticity-robust standard errors.
- Compare the adjusted and unadjusted standard errors; the ratio should sit near sqrt(1 - 0.49) = 0.71.
- Split by xyz_class and report rho within each; expect a materially lower correlation and a much smaller reduction on Z cells.
Follow-up
- The policy change alters ordered_qty through substitution behaviour. What does a treatment-affected denominator do to a ratio metric, and does CUPED still help?
- Three cells carry 40% of regional volume. What does that do to your variance, and which estimand should you actually report?
A seven percent demand rise that is a calendar artefact
A planner reports regional demand up 7 percent for the most recent four weeks against the prior four and wants safety stock raised. fct_inventory_daily is cut at each node's local end of day using dim_location.timezone and working_calendar_id. The recent window contains one public holiday fewer and spans a daylight-saving transition. Using fct_inventory_daily (inventory_date, location_id, sku_id, demand_qty, stockout_flag), dim_location and dim_sku, test whether underlying demand moved at all. Deliverable: a calendar-adjusted growth figure and a statement of what you would raise, if anything.
Approach
- Count exposure before comparing totals, and be exact about what can differ. Any 28-day window contains exactly four of each weekday whatever date it is anchored to, so two consecutive four-week windows have identical weekday composition and a weekday-mix reweighting between them is identically zero. Assert it rather than assume it, then set it aside. The weekday term only becomes live when a window is not a whole multiple of seven days, which happens the moment someone compares calendar months or a truncated most-recent week, so the assertion is worth keeping in the query.
- What does differ is working days, and that is where the arithmetic lives. Derive each window's non-working dates per node from working_calendar_id: on a five-day calendar a 28-day window holds 20 weekdays, so one public holiday fewer takes a node from 18 working days to 19 (5.6 percent more selling exposure) or from 19 to 20 (5.3 percent), before any demand moves. Compare demand per working day, not demand per calendar day.
- Weight those days the way demand is actually distributed. Because order cut-offs are daily and local, days are not interchangeable: build a day-of-week index per node from 52 weeks of history with holiday dates excluded (mean demand_qty by weekday over the node's overall daily mean), and define exposure as the sum of that index across the window's working days. Demand per unit of index-weighted exposure is the adjusted figure; demand per plain working day is the cruder version and is wrong by the index spread whenever the holiday falls on an unusually heavy or light weekday.
- Measure the holiday's shoulder separately, because the exposure adjustment cannot see it. Orders that would have been placed on the closed day arrive on the working day before or after, so a window with one holiday fewer also loses the displaced spike its neighbours carried. Compare demand_qty on the two working days either side of each holiday against those weekdays' index values and report the displaced units as their own line.
- Bound the daylight-saving effect instead of arguing about it. The snapshot is cut at local end of day, so one inventory_date per timezone spans 23 or 25 hours: at most one extra or missing hour of order capture on one of 28 days, about 0.15 percent of the window even if that hour carried normal trading volume, which at an overnight transition it does not. Identify the transition date per timezone, compare its demand_qty against neighbouring same-weekday dates, and report growth with and without it so the term is shown to be small rather than presumed to be. Then test whatever residual survives against the same calendar weeks one year earlier under the identical exposure adjustment, and ask whether it is demand or the relaxation of censoring: an order never placed because the item displayed as unavailable leaves no row at all, so a window with fewer stockout days records higher demand_qty with underlying demand flat. Cut the residual by stockout_flag history per sku-location before calling it growth.
Follow-up
- After adjustment the growth is 0.4 percent with a wide interval. What do you tell the planner, and what would change your answer?
- Which of these adjustments would you bake into the standard report, and which stay manual because they need judgement?
- If the residual is recovered censored demand rather than growth, does that argue for more safety stock or less?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗02One 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.
Practice prompt ↗Practice prompt ↗03Only 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.
Practice prompt ↗Practice prompt ↗04One 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your 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.
Practice prompt ↗Practice prompt ↗06The 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.
Practice prompt ↗Practice prompt ↗07Taper
- 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
An answer without a quantity is hard to interrogate, so interviewers keep probing until they find one. Come with the baseline, the change, the window it was measured over, and how confident you were. If the effect never got measured, say so and say what you would have measured. Fabricated precision is worse than an honest gap.
Tell me about a time you had to work with messy, undocumented data. Ho…
Tell me about a time you had to work with messy, undocumented data. How did you proceed?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Name the disagreement or constraint, and how you resolved it with evidence.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- What would you do differently if you ran that project again?
- What did you decide not to do, and why?
Tell a sponsor the effect cannot be measured in six weeks
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?
Defend a finding that the expedite program bought nothing
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?
- 01
Tell me about a time you had to work with messy, undocumented data. How did you proceed?
- 02
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.
- 03
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.
Is this an official American Bureau Of Shipping interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at American Bureau Of Shipping. Rounds and questions reflect what candidates have reported, not a process American Bureau Of Shipping has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview process, and how long should I prepare?
The difficulty is generally considered average compared to big tech companies, but it requires a different kind of preparation. Focus less on LeetCode-style algorithms and more on end-to-end applied data science, model deployment, and clear communication. Plan for 2-3 weeks of focused preparation, heavily reviewing your past projects.
PracHub interview research ↗What differentiates a successful candidate for the AI Practice Team?
A successful candidate doesn't just know how to train a model; they know how to solve a business problem. American Bureau Of Shipping values candidates who can take a vague maritime challenge, identify the right data, build a robust model, and confidently explain the ROI to stakeholders.
PracHub interview research ↗What is the working style and culture like for Data Scientists at ABS?
The culture blends traditional engineering rigor with modern tech innovation. You will find a strong emphasis on safety, accuracy, and compliance. Because the AI Practice Team is driving digital transformation, you must be comfortable acting as an internal evangelist for data-driven decision-making.
PracHub interview research ↗How long does the interview process typically take?
The timeline from the initial recruiter screen to a final offer usually spans 3 to 5 weeks. Delays can occasionally happen due to scheduling conflicts with senior team members, so patience and proactive follow-ups are recommended.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Waymo Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Waymo, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
ZF Group Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for ZF Group data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
XPO Data Scientist Interview Questions & Guide 2026
Data-quality drills for XPO data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dropped; a genuine
Xometry Data Scientist Interview Questions & Guide 2026
A prep plan for Xometry data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three days later instead