Interview guides · SAIC

SAIC Data Scientist Interview Questions & Guide 2026

SAIC data scientist prep on data pitfalls: selection bias, target leakage, and checking an outlier's provenance before you drop it.

The 60-second brief

As a Data Scientist at SAIC (Science Applications International Corporation), you operate at the critical intersection of advanced analytics, systems engineering, and national security. SAIC is a premier technology integrator for the United States government, which means your work directly impacts defense, intelligence, space, and federal civilian missions. Whether you are optimizing logistics pipelines for the military, building predictive maintenance models for aerospace systems, or leveraging natural language processing to analyze intelligence feeds, your insights drive high-stakes decision-making.

SQL is seldom the hardest round and is often the one that eliminates people. The working bar is usually window functions, correct deduplication, and joins that do not silently fan out rows, rather than obscure syntax.

Focus areas

Estimate eligible populations outside administrative data
Separate obligations, outlays and ceilings correctly
Model censored case durations without survivorship bias

Overview

Unlike typical commercial data science roles where the primary goal is maximizing user clicks or ad revenue, a Data Scientist at SAIC tackles complex, unstructured data challenges where accuracy and reliability are paramount. You will work with diverse datasets—ranging from satellite imagery and sensor telemetry to unstructured military reports—requiring a robust understanding of both traditional statistical modeling and modern deep learning techniques.

To succeed in this role, you must be more than a skilled programmer; you must be a mission-focused problem solver. The systems you develop must be robust, explainable, and deployable within highly secure, regulated federal environments. This role offers the unique opportunity to apply cutting-edge machine learning and artificial intelligence to some of the nation's most complex and meaningful challenges.

The SAIC interview process

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

Recruiter Screen

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 Assessment

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

What to demonstrate

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

How to prepare

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

Final Panel Interview

Where a loop ends with a senior leader, that conversation is rarely another skills test. The technical signal already exists by then, so the questions tend to open up: what you would look at first, where a metric you have heard about could mislead, what you would push back on. The decision being made is scope, which in practice means level and how much you would be trusted to own unsupervised. Treating it as a formality is the usual mistake. An open question late in the day is still being scored, and a vague answer reads as someone who has not run anything themselves.

What to demonstrate

Whether your view of the business has anything specific behind it, given that you are working only from what is public and are expected to say so
Whether the scope of work you describe owning matches the scope of the role, instead of sitting a level below it
Whether you can disagree with something concrete and stay useful about it, rather than agreeing with everything said in the room
Whether your questions are ones only this person could answer, as opposed to ones the recruiter already covered

How to prepare

Build one view you could defend for two minutes using only public information: what the funnel probably looks like, which metric likely drives decisions, and where that metric could mislead. Being wrong for a stated reason survives this round; having no view does not
Write down the largest piece of work you have owned from question to decision, who else touched it, and what you decided alone, then check that it reads at the level you are interviewing for
Prepare one thing you would want changed if you joined and phrase it as a question rather than a verdict, so it opens a conversation instead of closing one

Where candidates lose points

Assuming record-linkage error is random noise that averages out

False non-matches concentrate among people with name changes, transliterated or hyphenated names, unstable addresses and no durable identifier, which are the same people a disparity analysis is usually about. The linked cohort is therefore systematically more stable than the population, and any disparity estimate computed on it is biased toward finding no disparity. Carry link_method and link_confidence into the analysis, test whether results hold as the confidence threshold moves, and report the match rate by subgroup as a diagnostic rather than a footnote.

Suppressing one small cell in a published table and leaving the row and column totals in place

A single suppressed cell is recoverable by subtracting the published cells from the published margin, so primary suppression without complementary suppression protects nothing. Two separately published tabulations of the same underlying data compose as well, meaning two individually safe releases can jointly identify a cell. Either apply complementary suppression across the whole table and check it against the margins, or use a formal mechanism with an accounted budget, remembering that Laplace noise for a count query is scaled to sensitivity over epsilon, that sequential releases add their epsilons, and that noisy counts are not automatically non-negative or additively consistent across aggregation levels until post-processed.

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.

Reporting a mean for a heavy-tailed metric without saying what it hides

For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.

Questions & practice

How do you handle missing or corrupted data in a large dataset before feeding it into a machine learning model?

Medium · machine learning and modelling

Approach

Frame the prediction: the label, the moment of prediction, and the action it triggers.
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?

Walk me through a machine learning project you led from conception to deployment. What challenges did you face, and how did you overcome them?

Medium · machine learning and modelling

Approach

Frame the prediction: the label, the moment of prediction, and the action it triggers.
Check what information would not exist at prediction time, and exclude it.
Pick an evaluation metric that matches the cost of each error type, not a default.

Follow-up

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

Kaplan-Meier days to decision with Greenwood standard errors

Medium · survival analysis · right censoring · greenwood

apps has application_id, submitted_at, decision_at (NaT while open) and status, and you have a scalar extract_date. Estimate time from submission to decision in days using a Kaplan-Meier survivor function written from scratch. Rows still in status 'submitted' or 'pending_evidence' are right-censored at extract_date minus submitted_at. Return S(t) with Greenwood standard errors, the median, and S at 30, 60 and 90 days. Report the mean over decided rows alongside it. No lifelines and no statsmodels.

Approach

Build duration and an event indicator in one pass: decided rows get event = 1 with duration = (decision_at - submitted_at).days, open rows get event = 0 with duration = (extract_date - submitted_at).days. Count negative durations from backdated decisions and report them rather than clipping to zero, which would invent same-day decisions.
Assemble the risk table: distinct durations ascending, d_i events at each, c_i censored at each, and n_i at risk. Use the standard tie convention that observations censored at time t are still at risk at t, so events are credited before censoring at the same duration.
S(t) is the cumulative product of (1 - d_i / n_i) over event times up to t. Greenwood gives Var(S(t)) = S(t)^2 * sum(d_i / (n_i * (n_i - d_i))) over the same times. Each term of that sum grows as n_i thins, but the sum is multiplied by a falling S(t)^2, so the standard error is not monotone in t: it climbs early, peaks in the interior of the curve, and falls again once S(t) is small. Guard the term where n_i == d_i, which divides by zero at a last event that empties the risk set.
Median is the smallest t with S(t) <= 0.5. If the curve never crosses 0.5 inside observed follow-up, return 'not reached'. Substituting the largest duration there is the same mistake as dropping censored rows, in a different costume.
Put the decided-only mean next to it and state the mechanism, not just the gap: open cases are disproportionately the slow ones, so restricting to decided rows is length biased and the bias grows as the backlog grows.

Worked solution (35 min)

Compute duration_days and event for every row, and separately count and report rows with negative durations.
Aggregate to a risk table with columns t, d, c, then derive n as total minus the cumulative sum of (d + c) shifted by one.
Cumulative-product the survival factors for S(t), and cumulative-sum the Greenwood terms before multiplying by S(t)^2 and taking the square root, with an explicit branch for n_i == d_i where the term is undefined and S(t) is already 0.
Read off the median by scanning for the first t with S(t) <= 0.5, and interpolate S at 30, 60 and 90 by taking the last event time at or below each.
Compute the decided-only mean and median and return everything in one summary dict.

Expected result: S(t) starting at 1 and non-increasing, a Kaplan-Meier median at or above the decided-only median, S(30), S(60) and S(90) each with a Greenwood standard error, and the string 'not reached' rather than a number when the curve stays above 0.5 through the longest observed follow-up.

Verify it yourself

With censoring removed, 1 - S(t) equals the empirical CDF of the durations at every t.
At each event time the number at risk falls by exactly d_i + c_i going into the next time, and n_i is never negative.
The standard error is 0 for every t below the first event time, where S = 1 and the Greenwood sum is empty. Do not assert that it rises from there: SE(t) = S(t) * sqrt(sum(d_i / (n_i * (n_i - d_i)))) is a falling factor times a rising one, so it can decrease in the thin tail, and it returns to 0 at a final event that empties the risk set, where S(t) = 0. Assert finite and non-negative at every t instead, and assert that the empty-risk-set branch is exercised by a sample whose longest duration is an event.
Recomputing with every open case forced to event = 1 at its censoring time gives a curve lying everywhere at or below the Kaplan-Meier curve, and that gap is the size of the shortcut's bias.
With no censoring the Greenwood standard error equals the binomial sqrt(S(t) * (1 - S(t)) / n) at every t, because the sum telescopes to 1 / n_i - 1 / n. Assert that to floating point on a censoring-free sample; it catches an off-by-one in the risk set that the shape of the curve hides.

Follow-up

Two programs report the same Kaplan-Meier median but S(30) differs by 15 points. Which do you escalate, and what do you ask for first?
A case can also exit by withdrawal or administrative closure. What does a single curve on 'any exit' get wrong, and what estimator replaces it?
Decision events are sometimes backdated by up to three weeks. Which direction does that move the curve, and how would you bound the effect?

What is your approach to optimizing SQL queries when working with massive database tables?

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.
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 would you verify this result without re-running the same query?

Point-in-time join across slowly changing dimension and boundary vintage

Hard · scd type 2 · point-in-time join · fan-out

fact_application has application_id, constituent_id and submitted_at. dim_constituent is type 2 with constituent_id, residence_geo_id, effective_from and effective_to (NULL marks the current row). dim_geography has geo_id as the primary key, unique to one geography and one boundary vintage, plus geo_code, vintage_year, effective_from, effective_to and deprivation_quartile; the same geo_code refers to different physical areas in different vintages. Count applications submitted between 2021 and 2025 by submission year and by the deprivation quartile of the residence as it stood on submitted_at. Exactly one output row per application must feed the count.

Approach

Join dim_constituent with a range predicate, submitted_at >= effective_from AND (effective_to IS NULL OR submitted_at < effective_to), using a half-open interval so an application submitted exactly at a version boundary matches one version and not two.
Join dim_geography on residence_geo_id, not on geo_code: geo_id is already unique to the geography-and-vintage pair, so it carries the vintage for free, while geo_code multiplies each application by the number of vintages that code has existed in and reassigns records across a redraw.
Assert the grain rather than assuming it, by counting rows before and after each join; a type 2 dimension joined on the natural key alone produces one row per version of the person and the inflation is largest for constituents who moved, which is exactly the population a quartile breakdown is about.
If the dimension has overlapping ranges from a bad load, deduplicate with ROW_NUMBER() OVER (PARTITION BY application_id ORDER BY effective_from DESC) and keep rn = 1, but record how many applications needed it instead of hiding the repair.
Report the count of applications that failed to match any version as its own line, because a point-in-time join that silently drops pre-history applications understates the earliest years and produces a fake upward trend.

Worked solution (40 min)

Record COUNT(*) of fact_application in the date range as the target grain before writing any join.
Join to dim_constituent with the half-open range predicate and re-count; investigate any increase before proceeding.
Join to dim_geography on residence_geo_id and re-count again, confirming the number is unchanged.
LEFT JOIN rather than INNER JOIN at both steps first, so unmatched applications are visible and countable instead of silently gone.
Group by EXTRACT(YEAR FROM submitted_at) and deprivation_quartile, with a separate bucket for unmatched rows.
Re-run the whole thing with a naive current-row join and compare the quartile distribution to size the error.

Expected result: A tidy grid of five years by four quartiles plus an unmatched bucket, where the row counts sum exactly to the count of applications submitted in the range. The naive current-row variant returns a larger total than the application count, and the excess concentrates in constituents with multiple address versions.

Verify it yourself

SUM of all output counts, including the unmatched bucket, equals COUNT(*) of fact_application for the date range.
COUNT() after the constituent join equals COUNT() before it.
No application_id appears more than once in the intermediate joined set, verified with a HAVING COUNT(*) > 1 probe.
Each matched application's geo row has effective_from <= submitted_at, checked as an assertion rather than eyeballed.

Follow-up

A boundary redraw happened in 2023. What exactly goes wrong in a year-over-year quartile comparison if you attach current-vintage geography to every year, and which direction does it bias?
How would you present a 2021-to-2025 trend when the quartile definitions themselves were re-derived within each vintage?
Some applications match no constituent version because the identity was resolved after submission. Include them, exclude them, or report separately?

How do you prioritize your tasks when managing multiple competing deadlines across different projects?

Medium · product sense and metrics

Approach

State what result would change your recommendation, so the answer is falsifiable.
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.

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?

Explain the difference between supervised and unsupervised learning, and provide an example of how you have applied both.

Medium

Approach

Clarify what is being asked and what a complete answer would contain.
Work from the decision backwards to the evidence you would need.
Say what you would check first and why it is the highest-information step.

Follow-up

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

How do your specific technical skills and academic background translate to the defense and federal contracting space?

Medium

Approach

Clarify what is being asked and what a complete answer would contain.
State your assumptions explicitly before working the problem.
Say what you would check first and why it is the highest-information step.

Follow-up

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

Design an intake completion metric that survives a channel mix shift

Easy · funnel metrics · mix shift · standardisation

Intake runs through six channels in fact_application.channel: online, phone, mail, in_person, kiosk and partner_org. Only online and kiosk write a row at created_at before submitted_at is populated. The rest appear only once submitted, so submitted_at is never NULL for them. Leadership wants one application completion rate on the weekly dashboard. Define the metric, state which channels it is valid for, propose what you report for the others, and show how you stop a shift in channel mix from moving the pooled number on its own.

Approach

Define completion on the cohort that can express the event: applications with created_at in the week and submitted_at NOT NULL within 30 days of created_at, over all applications with created_at in that week including those still in status 'draft' or 'abandoned'. Evaluate the cohort 30 days after it closes so every row has had the full window.
Rule the metric out for mail, phone, in_person and partner_org. Those channels have no observable draft state, so the numerator equals the denominator and they report a structural 100 percent that will drag the pooled figure toward a constant.
Give the offline channels a different metric that their data can support, such as the share of submitted applications that reach a decision without an evidence request, or the share returned as incomplete at intake. Say clearly that it is a different quantity and cannot be added to the online number.
Show that a pooled rate over mixed channels moves with mix alone. Publish per-channel rates as the primary display and, if a single headline is required, a fixed-weight standardised total using a frozen base-period channel mix so that the headline moves only when a channel's own rate moves.
Name the base period and the rule for refreshing the weights, because a standardised series with silently updated weights is the same problem wearing a different label.

Worked solution (20 min)

Write the cohort definition with the exact 30-day evaluation lag and the inclusion of draft and abandoned rows in the denominator.
List the six channels and mark each valid or invalid for this metric, with the reason stated as a data fact rather than a preference.
Construct a two-channel numerical example where each channel's rate falls but the pooled rate rises, to demonstrate the mix effect rather than assert it.
Recompute that example with fixed base-period weights and confirm the standardised figure falls.
Write the dashboard specification: per-channel rates as the primary panel, standardised total as a single secondary line, with the base period printed next to it.

Expected result: Worked example: base period online completion 62 percent at 50 percent share, kiosk 55 percent at 50 percent share, pooled 58.5 percent. Current period online 61 percent at 80 percent share, kiosk 54 percent at 20 percent share, pooled 0.8 * 61 + 0.2 * 54 = 59.6 percent, which is up even though both channels fell. Standardised at base weights: 0.5 * 61 + 0.5 * 54 = 57.5 percent, correctly down from 58.5. The deliverable is per-channel rates plus a standardised headline labelled with its base period.

Verify it yourself

Every channel-level rate in the example moved down while the pooled figure moved up, which is the property being demonstrated.
The standardised total equals the pooled total in the base period by construction.
Mail, phone, in_person and partner_org do not appear in the online completion metric at all.

Follow-up

A new kiosk deployment doubles kiosk volume in one district. What does the standardised headline do, and what should the district-level report show instead?
How would you detect that partner_org submissions are being drafted offline and keyed in as complete, which would hide abandonment entirely?

Quarterly obligations double in an as-of snapshot table

Medium · snapshot double counting · signed deltas · fiscal seasonality

Obligated dollars for one program appear to double in a fiscal quarter. fact_obligation holds one row per funding action per snapshot: obligation_action_id, award_id, action_type, obligated_delta_cents, ceiling_amount_cents, outlay_to_date_cents, fiscal_year, fiscal_quarter, snapshot_date, is_current_snapshot. Establish whether obligations actually rose, produce the corrected quarterly series, and name the comparison period you would publish it against.

Approach

Check snapshot hygiene before any aggregation. Count distinct snapshot_date per obligation_action_id: if actions repeat across snapshots, an unfiltered SUM counts the same action once per snapshot. Restrict to is_current_snapshot = TRUE, or to a single chosen snapshot_date, and re-run.
Sum the signed obligated_delta_cents across all action types rather than filtering to action_type = 'new_award'. Deobligations and terminations are negative rows, so dropping them inflates every period; award value is only correct when summed across all actions grouped by award_id.
Confirm no one has substituted a different money column. ceiling_amount_cents is a maximum the award may reach and is not money committed; outlay_to_date_cents is cumulative cash as of the snapshot and lags obligation by months to years, so differencing it across snapshots gives a flow while summing it gives nonsense.
Choose the comparison period on the basis of how the appropriation behaves. Where funds lapse at fiscal year end, obligations concentrate in the closing weeks, so quarter over quarter compares a peak against a trough; compare the same fiscal quarter across years instead, and say so in the note.
If the rise survives all of that, decompose by award_id, action_type and competition_type. A single option exercise or one multi-year award booked in full is a different finding from broad growth, and the two should never be reported with the same sentence.

Follow-up

Obligations rose and outlays did not. What are the benign explanations, and which one would you test first?
How would you publish a series that is stable when a prior quarter is restated in a later snapshot?

Suggested practice checklist

Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.

Day 1 — Breadth pass: query fluency

Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.

Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.

Day 2 — Breadth pass: statistics and inference

Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
Rewrite the two weakest answers the following morning from memory in full sentences.

Deliverable: Ten graded answers with an honest count of exact hits.

Day 3 — Breadth pass: modelling

Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.

Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.

Day 4 — Breadth pass: product judgement

Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.

Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.

Day 5 — Depth, first area

Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
Re-solve the two you failed the same evening with notes closed.

Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.

Day 6 — Depth, second area, and the seam between them

Repeat the depth protocol on the second-ranked area with the same six-problem structure.
Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
Solve your own combined problem end to end and note where the handoff between the two areas cost you time.

Deliverable: One combined problem, solved end to end, with the handoff failure written down.

Day 7 — Integration and re-measurement

Re-run the six prompts from day one under the same clock and compare both correctness and time.
Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.

Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.

Explaining a method to someone who will not follow the maths

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

Describe a time you had to collaborate with a multidisciplinary team of systems engineers, software developers, and business analysts.

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

Describe a time when you had to work with a highly unstructured or messy dataset. What steps did you take to clean and structure it?

Medium · behavioural and stakeholder questions

Approach

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

Follow-up

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

Correct a published duration figure you got wrong

Medium · censoring · error disclosure · survivorship

Six weeks ago you published median days to decision as the median over applications that had a decision_at. A colleague points out that applications still in status 'submitted' or 'pending_evidence' were dropped rather than censored; the Kaplan-Meier median on the same cohort is 41 days against the 22 you published. The figure sits on a public page and was quoted in a briefing. Set out what you do in the first twenty-four hours, and draft the correction note in under 150 words.

Approach

Quantify before you talk. Recompute with still-open applications entered as right-censored at extract_date minus submitted_at, confirm the direction and size, and check whether any decision that cited the figure would have gone differently at 41 days.
Establish who acted on it. Tell the owner of the affected decision and the owner of the publication first, in that order, rather than broadcasting to the widest audience or waiting until you have a full remediation plan.
Write the correction so the corrected number is the first thing a reader finds: the corrected figure with its method named, the mechanism in one clause (decided-only samples exclude the slow cases that are still open, so they are length-biased), and the exact period affected.
Fix the pipeline rather than the cell. Put the censoring rule into the metric definition, and add a test that fails if the published duration is computed on a decided-only subset.
Say what the incident teaches about the review step that missed it, and be specific: a reviewer checking the numerator and denominator counts would have seen the cohort shrink.

Follow-up

If the corrected figure is worse for the agency, does any part of your process change?
What single automated check goes into the recurring job, and what does it compare?