The Data Scientist role at MBC is a pivotal position focused on delivering high-impact analytical support for critical government programs, specifically within the U.S. Navy’s SEA 21 / PAE Maritime office. You will act as the bridge between complex, large-scale datasets and actionable strategic decisions. Your work directly influences the modernization and sustainment of surface ships, requiring you to translate raw technical data into clear, persuasive briefings for government leadership.
This role is uniquely challenging because it blends advanced technical execution with significant stakeholder management and operational coordination. Beyond building machine learning models or data pipelines, you are expected to handle data calls, facilitate project meetings, and refine operational processes. Success at MBC requires a blend of rigorous analytical capability and the interpersonal finesse necessary to navigate a high-stakes, mission-driven environment.
Initial Screen
reportedWhoever runs this call is usually not a practitioner. They take notes, and a hiring manager skims those notes later, so the real question is whether your work survives being written down by someone outside the field. Test every project sentence against that: could a non-specialist repeat it correctly without knowing what a propensity score is? Carry a plain-language version of each project and one reason you want this particular role that you could not copy onto another application. Vagueness at this stage reads as inexperience, even when the underlying work was genuinely deep.
What to demonstrate
- Whether a non-specialist can restate your projects accurately, since their paraphrase is what reaches the hiring manager
- Whether your reason for wanting the role points at the work itself rather than the company's reputation
- Whether your language signals the level being screened for: what you decided yourself versus what you were handed
How to prepare
- Write a two-sentence, jargon-free version of each major project: the question nobody could answer, and the decision your work changed. Read it to someone outside data and have them repeat it back
- Point your 'why this role' answer at something concrete in the job description or the product surface you would be working on, and keep it to two sentences
- Have two questions ready about measurement: which metric the team is held to, and who acts on an analysis once it lands
Technical Deep-Dives
reportedA 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
Behavioral Interviews
reportedRounds of this kind usually include one question about work that did not go well, and it is the part that carries the most information. Anyone can narrate a shipped win. What the interviewer learns from a project that stalled is how you behave without a result to hide behind: whether you noticed the problem yourself, how long it took, and who you told. Answers that route the failure onto a data pipeline or a reorganisation close the topic without answering it, and the follow-up comes back to your own part.
What to demonstrate
- Whether you found the error yourself or someone else found it, and how long it sat before anyone knew
- What you changed afterwards, stated as a check you now run rather than a lesson you now believe
- Whether the mistake you choose has real cost attached, such as a quarter of misdirected roadmap or a metric that was reported upward, instead of one that flatters you
How to prepare
- Choose a failure you caught yourself and be ready to say what tipped you off. A story where someone else caught it is still usable, but you will be asked why you missed it.
- Write down the check you added afterwards and where it lives now, so the correction is a concrete artefact rather than a resolution.
- Rehearse saying the cost out loud. Candidates shrink the number by instinct once the interviewer is in the room.
PracHub editorial advice for the preparation topics above.
Treating event_at in the case event log as when the event actually happened
Staff backdate to the true date of an action and enter it later, and batch loads write many rows at once, so event_at and recorded_at diverge systematically and the divergence is largest at fiscal-period and reporting-deadline boundaries. An interrupted time series keyed on event_at will read a queue flush before a deadline as a level shift caused by the policy change, and a dashboard keyed on recorded_at will show activity on days when nothing happened. Reconcile both columns, model the entry lag distribution, and state which clock each metric uses.
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.
Never asking what decision the analysis will inform
Open with who makes the decision, what the options are, and by when. The answer determines the precision you need, the segments worth cutting, and whether an observational read suffices or an experiment is required.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Which key performance indicators (KPIs) would you choose to measure th…
Which key performance indicators (KPIs) would you choose to measure the success of a new maintenance scheduling algorithm?
Approach
- Set a baseline first, so any model has something honest to beat.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Laplace release of nested counts with consistent post-processing
counts holds exact denial counts by (district_geo_id, tract_geo_id, denial_reason_code), where tracts nest inside districts and each constituent contributes to exactly one cell. Release the tract by reason cells and the district totals under a total privacy budget epsilon, using a Laplace mechanism you write yourself. Then post-process each district so its tract cells are non-negative and sum exactly to the released district total. Finally show empirically how per-query error moves when one epsilon is split across k sequential queries.
Approach
- Fix the adjacency and the sensitivity before touching data. The full tract by reason histogram has L1 sensitivity 1 under add-or-remove adjacency and 2 under replace-one, because a replaced record leaves one cell and enters another. Say which you are using; it doubles the noise scale b = sensitivity / epsilon_cells.
- Split the budget honestly. District totals are a coarsening of the same records rather than a disjoint query, so releasing them alongside the cells composes sequentially and epsilon_cells + epsilon_totals = epsilon. Disjointness buys you something only across records, for example separate districts released by separate mechanisms.
- Add noise with a seeded generator: rng.laplace(0, b, size). Laplace(b) has variance 2b squared, so per-cell standard deviation is sqrt(2) * b. Compare that number against the typical cell count before deciding the release is publishable at all.
- Post-process per district: clip the noisy district total at 0, then project the noisy tract vector onto {x >= 0, sum x = T} by minimising squared distance. The solution is x_i = max(y_i - tau, 0) with tau found by sorting y descending and scanning for the value that makes the sum hit T. If integers are required, round with largest remainders so the total survives the rounding.
- Run the sweep: for k in 1 to 8, split one epsilon into k sequential queries each with b = k * sensitivity / epsilon, and plot RMSE against k. Per-query standard deviation grows linearly in k, which is the whole argument for releasing fewer and coarser queries.
- State why the reconciliation is free: any function of a differentially private output is differentially private with the same parameters, provided it touches no raw data again.
Follow-up
- You could skip epsilon_totals and derive district totals by summing the noisy tract cells. Compare the variance of that against a directly measured total and say when each wins.
- A reason code appears in only two tracts, with a true count of 3 in each. What do you publish, and does the noise alone make it safe?
- The same table is released monthly for a year. What is the honest statement about cumulative budget, and what would you change in the design?
Reconcile obligations, ceilings and outlays across snapshot dates
obligations holds one row per funding action: obligation_action_id, award_id, action_type, action_at, fiscal_year, obligated_delta_cents (signed), ceiling_amount_cents, outlay_to_date_cents, program_code, snapshot_date and is_current_snapshot. The table is a stack of as-of snapshots, and outlay_to_date_cents is an award-level cumulative figure repeated on every action row inside a snapshot. Produce a per-award frame with net obligated value, ceiling in force and outlay; a program by fiscal-year obligation total; and an exception report for awards where net obligated exceeds the ceiling or outlay exceeds net obligated.
Approach
- Filter to is_current_snapshot and assert that exactly one snapshot_date survives. If several do, the flag is maintained per award rather than per snapshot and every total below counts some awards twice.
- Net obligated per award is the sum of signed obligated_delta_cents. Deobligations and terminations are negative and must be summed in; filtering to action_type = 'new_award' reports gross intent, not money committed.
- Ceiling is the value carried on the latest action by action_at, because a modification can raise it. Summing ceiling_amount_cents across actions is a category error: it is a maximum the award may reach, not cash.
- Outlay is award-level and repeated, so reduce it with first after asserting nunique() == 1 per award. Summing it multiplies the figure by the action count, and the result still looks plausible, which is what makes it dangerous.
- Build fiscal totals by grouping deltas on the action's fiscal year, and cross-check the stored fiscal_year against the value derived from action_at. Disagreements are an assignment bug worth listing, not rounding.
- Exception frame: net > ceiling, outlay > net, earliest action not of type new_award, and net < 0. Report counts and cents rather than percentages of a denominator you have not defended.
Worked solution 25 min
- Filter on is_current_snapshot, then assert obligations['snapshot_date'].nunique() == 1 and stop if it fails.
- Group by award_id with a different reducer per column: sum for obligated_delta_cents, the value at max action_at for ceiling_amount_cents, and first for outlay_to_date_cents guarded by an nunique check.
- Group by program_code and fiscal_year over the signed deltas for the fiscal totals, and recompute fiscal_year from action_at to list mismatched rows.
- Build the exception frame by stacking the four rule violations with a rule column, so one award can appear more than once.
- Return the three frames with cents intact; convert to dollars only at presentation.
Follow-up
- Outlay sits at 40 percent of obligations for a program this fiscal year. Name three innocent explanations before you write the word underspending.
- Leadership asks how much money was committed this year for an award that spans three years with option exercises. What number do you give and what do you refuse to give?
- The snapshot flag turns out to be per award. What breaks in your aggregation and how do you rebuild it from snapshot_date alone?
Write a query to identify the top three most frequent failure modes ac…
Write a query to identify the top three most frequent failure modes across different ship classes.
Approach
- 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.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
How would you use SQL window functions to calculate rolling averages o…
How would you use SQL window functions to calculate rolling averages of ship maintenance costs over time?
Approach
- Say which table is the grain you start from, and join outward from it.
- State the window function and its partition and ordering out loud before writing it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Total time each case spent awaiting evidence
fact_case_event is append-only with case_event_id, application_id, event_type, event_at, prior_status and new_status. A case enters the pending_evidence state on an event where new_status = 'pending_evidence' and leaves it at that application's next event in event_at order; it may enter more than once, and it may still be sitting there at the extract timestamp. Return per application_id the number of pending_evidence stints and the total hours spent in that status, counting any open stint up to the extract timestamp. Order events within an application by event_at with case_event_id as the tiebreaker.
Approach
- Compute LEAD(event_at) OVER (PARTITION BY application_id ORDER BY event_at, case_event_id) over the full event stream in a CTE, before filtering to pending_evidence rows: if you filter first, LEAD returns the next entry into pending_evidence rather than the exit from it, and every stint is measured from one entry to the following entry.
- Include case_event_id in the ORDER BY because staff backdating puts several events on the same event_at, and a window with a non-deterministic order silently reorders a transition pair.
- In the outer query, keep only rows where new_status = 'pending_evidence' and set the stint end to COALESCE(next_event_at, extract_ts), which is what makes open stints count instead of vanishing.
- Aggregate with COUNT(*) for stints and SUM(EXTRACT(EPOCH FROM (stint_end - event_at)) / 3600.0) for hours, grouping by application_id.
- Flag applications whose final stint is open separately, because those durations are right-censored lower bounds and must not be pooled into a mean as if they were complete.
Worked solution 30 min
- Build a CTE selecting all fact_case_event columns plus LEAD(event_at) OVER (PARTITION BY application_id ORDER BY event_at, case_event_id) AS next_event_at.
- Verify on one multi-stint application by listing its events with next_event_at alongside, and confirm each pending_evidence row's next_event_at is an evidence_received or decision event.
- Filter the CTE to new_status = 'pending_evidence' and compute stint_end = COALESCE(next_event_at, extract_ts).
- Aggregate stints and hours per application_id, and carry a BOOL_OR(next_event_at IS NULL) flag for open stints.
- Compare the total hours on the same application computed with and without the COALESCE to size how much the open stints contribute.
Follow-up
- The average of this total is used to claim evidence handling improved. Why is that average biased downward while the backlog is growing, and what would you report instead?
- Two events on one application share an event_at and describe opposite transitions. How do you decide which came first?
- How would you extend this to give the time in every status rather than just pending_evidence, in one pass?
If we notice a sudden drop in the availability of a specific ship syst…
If we notice a sudden drop in the availability of a specific ship system, how would you diagnose the root cause?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- State what result would change your recommendation, so the answer is falsifiable.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you balance competing priorities when designing metrics for a m…
How do you balance competing priorities when designing metrics for a multi-stakeholder project?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you design a dashboard to track the readiness of surface shi…
How would you design a dashboard to track the readiness of surface ship components?
Approach
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
How do you determine the required sample size to ensure statistical si…
How do you determine the required sample size to ensure statistical significance in a pilot program?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
What are the most common experimentation pitfalls you have encountered…
What are the most common experimentation pitfalls you have encountered, and how do you avoid them?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- How would you handle interference between treated and control units?
Switchback design for a shared-capacity dispatch rule
A new rule routes service requests to crews by predicted travel time rather than by district. Crew hours are fixed, so treating some requests and not others moves capacity between arms and a request-level split violates the no-interference assumption. Using fact_service_request with assigned_unit_id, reported_at and first_response_at, design a switchback across 12 districts over 28 days. State the switching unit, the burn-in handling, the estimand and the variance treatment. The outcome is the 90th percentile hours to first response.
Approach
- Name the interference channel explicitly: crews are a shared and exhaustible resource, so under a request-level split the control arm's waiting time depends on how many treated requests are absorbing crew hours, and the difference in means describes neither the fully treated nor the fully untreated world.
- Switch the whole district on the clock: randomise the rule at the district by time-block level so that at any instant every request in a district faces one regime, which makes the estimand the global treatment effect rather than a contaminated local one.
- Set the block length against carryover, not convenience: blocks must be long relative to how long a job stays in progress, so with a multi-hour service standard a 6-hour block with the first 60 minutes discarded as burn-in is defensible and a 30-minute block is not.
- Analyse at the level you randomised: compute the p90 per district-block, regress it on the assignment indicator with district and block-of-day fixed effects, and cluster by district-day so serial correlation inside a day is not counted as independent information.
- Test the carryover assumption rather than asserting it: add the previous block's assignment as a regressor and confirm its coefficient is near zero, then re-estimate with a longer burn-in and report whether the point estimate moved.
Worked solution 35 min
- Count the design units: 12 districts * 4 blocks a day * 28 days = 1,344 district-blocks, about 672 per arm, which is the real sample size.
- Define the block outcome as the p90 of (first_response_at - reported_at) in hours over requests reported after the burn-in window, and drop any block where more than 10 percent of requests are still open at extract, because its p90 is not identified from observed data.
- Fit p90 ~ treat + district + block_of_day + day, with standard errors clustered by district-day.
- Re-fit with lagged assignment included and with the burn-in extended to 120 minutes, and report that pair as the stated robustness check.
Follow-up
- Demand is not stationary and storms produce correlated bursts across districts. Which part of the design breaks first, and how do you repair it?
- A stakeholder proposes randomising at the request level to get forty times more rows. What exactly does that estimate, and when would it be acceptable?
Online completion collapses the week autosave ships
Submission completion rate for the online channel fell from 61 to 38 percent the week a redesigned form shipped with autosaved drafts; mail and in-person are flat. You have fact_application (application_id, channel, created_at, submitted_at, status) and fact_case_event (application_id, event_type, event_at). The product lead wants to roll the release back tomorrow. Decide whether the metric moved because behaviour changed or because the denominator did, and state the evidence that separates the two.
Approach
- Look at the numerator in levels before touching the ratio. Count submitted applications per day for the online channel across the release. If the absolute count of submissions is unchanged while the rate fell, no constituent behaviour has changed and the denominator grew.
- Establish what a row in the denominator now means. Autosave writes a draft row on first interaction, so applications that previously left no trace now appear with created_at set and never advance. Count created_at rows per day before and after: a step change with no matching change in downstream events is the signature.
- Rebuild the metric on a denominator that is stable across the release. Restrict to drafts that reached a fixed progress marker, for instance those with at least one fact_case_event beyond 'created', and recompute both periods on that definition.
- Keep channels separate. Mail, in_person and kiosk have no draft state, so their completion rate is structurally near 100 percent and pooling them hides the online move or dilutes it depending on mix.
- Respect cohort maturity. The metric allows 30 days from created_at to submitted_at, so the release week is a partial cohort whose rate is mechanically low. Compare only cohorts that have fully matured, or report the day-7 completion share for both periods instead.
Follow-up
- On the stable denominator the rate still fell 4 points. How do you decide whether that is the release or the week, and what would you instrument next?
- What reporting change would you make so that a future instrumentation change cannot move this metric without being visible?
For a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
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 explain a complex technical finding to…
Tell me about a time you had to explain a complex technical finding to a non-technical stakeholder.
Approach
- Quantify the outcome, including what you would not claim credit for.
- Close with what you would do differently, concretely.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that project again?
- What did you decide not to do, and why?
Explain why a ranked district table should not be published
You have twelve small areas ranked by service requests per 1,000 residents, computed from fact_service_request counts over dim_geography.population_estimate. The estimates carry population_estimate_moe published at 90 percent confidence, and for the smallest areas the margin is close to a quarter of the estimate. An executive wants the ranked list on a slide tomorrow as "the twelve worst districts". You have five minutes with her and cannot put an equation on the slide. Say what you show instead, and what you tell her.
Approach
- Convert each published margin to a standard error first: at 90 percent confidence the standard error is moe divided by 1.645. Compute the relative standard error of the denominator for every area in the table.
- Show where the uncertainty lives. Treating the administrative count as fixed and independent of the survey estimate, the rate's relative standard error equals the denominator's, so an area with a 24 percent relative standard error on population has a 24 percent relative standard error on its rate no matter how clean fact_service_request is.
- Demonstrate the instability rather than asserting it: resample each denominator from its published standard error, recompute the ranking a few thousand times, and report how often each area actually lands in the worst twelve. Areas that appear in only a third of draws are not findings.
- Replace the rank with something that survives the uncertainty: aggregate to a geo_level where the relative standard error clears a threshold you state out loud, or group areas into tiers whose intervals do not overlap, and name the threshold as a choice you made rather than a standard.
- Give the executive one sentence she can repeat without you in the room, for example that the data supports naming a group of high-demand areas but not ordering them.
Follow-up
- Which relative standard error threshold do you use, and why is it a judgement rather than a rule?
- Two of the areas you aggregated sit across a boundary redraw. What breaks in the join, and how would you notice?
Allocate one analyst-week across three competing requests
Three requests land on Monday and you have one analyst-week. A statutory report of decision counts by program_code is due in nine days. An operations team wants a backlog projection to size next quarter's staffing. An equity lead wants the first-response equity ratio by deprivation quartile for a briefing in six weeks. Produce the allocation, the message you send to whichever teams you defer, and name the one deliverable you will refuse to produce in the time available.
Approach
- Sort by who owns the date. The statutory deadline is external and non-negotiable; the other two have owners who can trade scope or timing, which makes them negotiable even though both feel urgent.
- Cost each request in hours including the slow parts rather than the query: the statutory extract needs a validation pass and review time, the backlog projection needs arrival rates and a real capacity ceiling from dim_unit, and the equity ratio needs request-type stratification and a boundary-vintage-correct join to dim_geography.
- Allocate with review time inside the estimate, not after it. Finish the statutory report early enough that a second person can check it, because a late correction on a statutory return costs more than every other item on the list combined.
- Scope the backlog projection down to something honest: a capacity-bounded projection that states the stability condition, since a queue only clears when the arrival rate is below the throughput ceiling, and Little's Law relates work in progress to arrival rate times time in system only in steady state, which a seasonal arrival pattern violates.
- Turn the deferral into a commitment: a date, a named smaller interim artefact, and the specific input you need from them in the meantime, so "deferred" is falsifiable rather than a soft no.
- Refuse the one thing that cannot be done well: a single-date backlog clearance forecast with no capacity assumption, and say why in one sentence rather than negotiating it down.
Follow-up
- The operations director escalates to your manager. What do you send, and what do you not say?
- On day six the statutory extract fails a validation check. What drops, and who finds out first?
- 01
Tell me about a time you had to explain a complex technical finding to a non-technical stakeholder.
- 02
You have twelve small areas ranked by service requests per 1,000 residents, computed from fact_service_request counts over dim_geography.population_estimate. The estimates carry population_estimate_moe published at 90 percent confidence, and for the smallest areas the margin is close to a quarter of the estimate. An executive wants the ranked list on a slide tomorrow as "the twelve worst districts". You have five minutes with her and cannot put an equation on the slide. Say what you show instead, and what you tell her.
- 03
Three requests land on Monday and you have one analyst-week. A statutory report of decision counts by program_code is due in nine days. An operations team wants a backlog projection to size next quarter's staffing. An equity lead wants the first-response equity ratio by deprivation quartile for a briefing in six weeks. Produce the allocation, the message you send to whichever teams you defer, and name the one deliverable you will refuse to produce in the time available.
Is this an official MBC interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at MBC. Rounds and questions reflect what candidates have reported, not a process MBC has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How much preparation time is typical for this role?
Most successful candidates spend 2–4 weeks reviewing technical fundamentals and practicing behavioral stories. Given the specific domain expertise required, ensure you are comfortable explaining your past projects in the context of government or large-scale operational environments.
PracHub interview research ↗What differentiates successful candidates?
The strongest candidates balance technical depth with "client-readiness": they can explain complex statistical concepts to non-technical partners clearly and professionally.
PracHub interview research ↗What is the culture like at MBC?
MBC describes its culture as mission-driven and valuing hard work, while also emphasizing laughter and a positive environment. The company looks for people who are proactive, willing to challenge themselves, and interested in helping its clients succeed.
PracHub interview research ↗Are there travel requirements?
Yes, this role requires the ability and willingness to travel domestically and internationally to provide in-person support at MBC and client sites.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
SAIC Data Scientist Interview Questions & Guide 2026
Data-quality drills for SAIC 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 genuin
Nokia Federal Solutions Data Scientist Interview Questions & Guide 2026
Data-quality drills for Nokia Federal Solutions 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 o
Institute for Defense Analyses Data Scientist Interview Questions & Guide 2026
Communication practice for Institute for Defense Analyses data scientist candidates: turn an analysis into a recommendation, name the uncertainty honestly, and answer the follow-up a skeptical stakeholder will raise.
Govini Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Govini candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.