cswork / libraryOpen practice workspace

Interview guides · Cotiviti

Cotiviti Data Scientist Interview Questions & Guide 2026

Practice explaining analysis before a Cotiviti data scientist interview: the recommendation, the uncertainty, the follow-ups.

The 60-second brief

As a Data Scientist at Cotiviti, you will play a pivotal role in transforming healthcare data into actionable insights that drive decision-making and enhance patient care. This position is critical to the company’s mission of leveraging data to optimize healthcare outcomes and improve operational efficiencies. Your work will directly impact Cotiviti's products and services, helping to identify patterns, predict trends, and inform strategies that benefit both healthcare providers and patients.

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

Focus areas

  • Risk-adjust outcomes before comparing providers or panels
  • Reconstruct drug exposure intervals from dispensing records
  • Build member-month denominators from overlapping coverage spans

Overview

The complexity and scale of the data you will engage with at Cotiviti is substantial, encompassing a variety of datasets, including claims data, clinical data, and operational metrics. You will collaborate with cross-functional teams, including engineering, product management, and operations, to develop machine learning models and analytical solutions that address pressing healthcare challenges. This role not only offers the opportunity to apply advanced statistical and machine learning techniques but also to contribute to innovations that can significantly influence healthcare delivery and outcomes.

Candidates should be prepared for a dynamic environment where data-driven insights are at the forefront of decision-making processes. You will find that the impact of your contributions can lead to meaningful improvements in the healthcare landscape, making this an exciting and rewarding position.

The Cotiviti interview process

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

Initial Screening

Data Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.

What to demonstrate

  • Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
  • Whether you name what you have not done instead of stretching to cover every line of the posting
  • Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage

How to prepare

  • Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
  • Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
  • Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live

Interviews with Managers

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

Technical Discussions

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

What to demonstrate

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

How to prepare

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

Where candidates lose points

Immortal time in adherence, treatment, and enrolment definitions

Classifying members as adherent, treated, or programme-enrolled requires them to survive and stay covered long enough to accumulate the defining events. That guaranteed event-free interval is assigned to the exposed group, so the exposure looks protective for reasons that have nothing to do with the treatment. Adherence studies are the classic case: measuring 12-month proportion of days covered and then comparing mortality builds survival into the exposure definition. Use time-varying exposure or a landmark analysis with the classification window excluded from follow-up.

Treating clinical measurements as missing at random

A lab result, a vital sign, or a screening exists because someone ordered it, and ordering tracks suspicion of disease, visit frequency, and site workflow. Imputing the mean or dropping incomplete rows biases the population estimate and can flip the sign of an association, because the untested are systematically healthier or systematically disengaged. The presence indicator is often more predictive than the value, which is a warning sign rather than a feature win: a model that learns test ordering will not transfer to a site with different protocols.

Reporting a p-value with no effect size or interval

Give the estimated difference with a confidence interval in the units the business cares about, then say whether that whole interval is worth acting on. A p-value only addresses whether you can rule out exactly zero; it says nothing about magnitude.

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.

Questions & practice

Explain your experience with machine learning algorithms and when you would use each type.

Medium · machine learning and modelling

Approach

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

Follow-up

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

How would you optimize a machine learning model for performance?

Medium · machine learning and modelling

Approach

  1. Set a baseline first, so any model has something honest to beat.
  2. Say how the offline result would be validated online before it is trusted.
  3. Frame the prediction: the label, the moment of prediction, and the action it triggers.

Follow-up

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

Collapse claim versions before summing allowed amounts by member

Easy · claim versioning · groupby · deduplication

You are given medical_claim_line as a pandas DataFrame: claim_line_id, claim_id, claim_version, frequency_code (1 original, 7 replacement, 8 void), member_id, service_start_date, procedure_code, allowed_amount, claim_status. Return total allowed_amount per member for service dates in one stated calendar month, counting each claim once at its surviving version and excluding any claim whose surviving version is a void. Multi-line claims must keep every line of that surviving version. Output columns: member_id, allowed_amount, sorted descending. Do not deduplicate on claim_id alone.

Approach

  1. Separate the two grains out loud before writing code: versions live at the claim level, dollars live at the line level. Every bug in this exercise comes from mixing them.
  2. Compute the surviving version per claim with a groupby transform of max over claim_version, then keep the lines whose claim_version equals that value. A transform keeps the frame at line grain, which a sort plus head(1) does not.
  3. Drop whole claims whose surviving version carries frequency_code 8. A void is not a zero-dollar line, it retracts the claim, so filtering rows rather than claims leaves the prior version's lines behind.
  4. Filter to claim_status 'paid' and state the assumption: denied, pended and reversed lines carry an allowed_amount that never became a liability, so including them overstates cost.
  5. Restrict service_start_date to the month boundaries, then groupby member_id and sum. Sort descending and return.

Worked solution (20 min)

  1. Build a max-version lookup per claim_id with groupby('claim_id')['claim_version'].transform('max') and keep rows where claim_version equals it.
  2. From the surviving rows, collect the claim_ids whose frequency_code is 8 and drop those claim_ids entirely.
  3. Filter claim_status to 'paid' and service_start_date into the month window.
  4. Group by member_id, sum allowed_amount, sort descending, reset the index.

Expected result: A two-column frame member_id, allowed_amount. On a claim with versions 1, 7, 7 only the third version's lines contribute; a claim whose latest version is frequency_code 8 appears nowhere. Total allowed is strictly below a naive sum over all rows whenever any claim in the sample was adjusted, and equal to it when none was.

Verify it yourself

  • The distinct claim_id count in your filtered frame equals the count of distinct claim_ids whose surviving version is not a void.
  • The line count you kept for each surviving claim equals that claim's line count at its max version, not 1.
  • A naive sum over every row is greater than or equal to your total, with equality only when no claim has claim_version above 1.

Follow-up

  • A claim has versions 1, 7, 7 where the second replacement has fewer lines than the first. What does your code return and is that correct?
  • How would you handle a claim whose lines span two calendar months at the boundary of the reporting window?
  • The same logic has to run over 400 million lines in a warehouse. What changes, and what stays the same?

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

Medium · sql and data manipulation

Approach

  1. Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
  2. State the window function and its partition and ordering out loud before writing it.
  3. Compute rates by summing numerator and denominator separately, never by averaging rates.

Follow-up

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

Reconstruct drug coverage intervals and compute proportion of days covered

Hard · gaps and islands · window functions · adherence

pharmacy_claim holds fill_id, member_id, ndc_code, therapeutic_class_code, fill_date, days_supply, reversal_flag and reversed_fill_id. Early refills overlap, so days_supply must be laid end to end: each fill's coverage starts at the later of its fill_date and the previous interval's end. Both rows of a reversed pair are excluded. For one therapeutic_class_code over 2025-01-01 to 2025-06-30, return per member the proportion of days covered, defined as covered days divided by days from first fill_date to window end, plus the share of members at or above 0.80. Require at least two fills and 91 days of follow-up.

Approach

  1. Clean the fills first. Drop rows with reversal_flag TRUE and also the fills they point at through reversed_fill_id. Dropping only the reversal row leaves an original fill counted as exposure that never reached the member. Use NOT EXISTS for that second step, since reversed_fill_id is nullable and NOT IN would return nothing.
  2. Shift, never stack. The shifted end is covered_end_i = GREATEST(fill_date_i, covered_end_{i-1}) + days_supply_i, which looks recursive but has a closed form: with cum_i the running sum of days_supply through fill i, covered_end_i = cum_i + MAX over j <= i of (fill_date_j - cum_{j-1}). That is SUM(days_supply) OVER (ORDER BY fill_date ROWS UNBOUNDED PRECEDING) plus a running MAX of an anchor column, so it is two window functions and no recursive CTE.
  3. Derive covered_start_i as GREATEST(fill_date_i, LAG(covered_end)). The intervals are disjoint by construction, so covered days is a plain sum of lengths and never needs a distinct day grid.
  4. Clip intervals to the window end before summing, and decide explicitly whether to clip at disenrollment as well. Supply that runs past the window must not inflate the numerator.
  5. Use the denominator the spec names, first fill_date to window end, and hold it constant across classes. A fixed-window denominator yields a different and usually lower number, and mixing the two across classes makes the comparison meaningless.
  6. Apply the inclusion rules at member level after the intervals are built, then compute the share at or above 0.80 with the qualifying member count beside it.

Worked solution (40 min)

  1. Filter to the therapeutic_class_code and window, then remove reversal rows and their originals with NOT EXISTS.
  2. Per member ordered by fill_date, compute cum_supply and anchor = fill_date - (cum_supply - days_supply), then covered_end = cum_supply + MAX(anchor) OVER (ORDER BY fill_date ROWS UNBOUNDED PRECEDING).
  3. Compute covered_start = GREATEST(fill_date, LAG(covered_end) OVER (ORDER BY fill_date)), clip both ends to the window, and drop intervals that collapse.
  4. Sum interval lengths as covered_days, compute follow_up_days from first fill_date to window end, and divide.
  5. Apply the two-fill and 91-day rules, then aggregate the share at or above 0.80.

Expected result: One row per qualifying member with covered_days, follow_up_days and pdc in [0, 1], plus a summary row with qualifying members and the share at or above 0.80. A member with 30-day fills on 2025-01-01, 2025-01-20 and 2025-04-01 is covered 2025-01-01 to 2025-03-01 and 2025-04-01 to 2025-04-30, giving 60 + 30 = 90 covered days over 181 follow-up days and a PDC of 0.497.

Verify it yourself

  • No pdc exceeds 1.0 before any clipping. A value above 1 proves supplies were stacked instead of shifted.
  • On a twenty-member sample, the summed interval lengths equal the distinct covered day count from a slow day-grid version.
  • A member with one fill is excluded by the two-fill rule rather than appearing with a PDC of 1.0.
  • Re-running with reversals left in raises covered days for exactly the members who have a reversed_fill_id, and for no one else.

Follow-up

  • A member is hospitalised for twelve days mid-window, when the facility supplies medication. Should those days count as covered, and what do published adherence measures do about them?
  • Someone wants to classify adherence over twelve months and then compare mortality from month zero. What is wrong with that design and what fixes it?
  • Two different ndc_codes in the same therapeutic class overlap. Is that stacking or switching, and how does your interval logic treat each case?

How do you prioritize tasks when working on multiple projects?

Medium · product sense and metrics

Approach

  1. State what result would change your recommendation, so the answer is falsifiable.
  2. Decompose the metric into the rates that drive it, and say which one you would check first.
  3. Restate the decision this analysis has to support, and who acts on the answer.

Follow-up

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

Present a case study where you had to pivot your approach based on new findings.

Medium · product sense and metrics

Approach

  1. Fix the population and the time window before naming any metric.
  2. Restate the decision this analysis has to support, and who acts on the answer.
  3. State what result would change your recommendation, so the answer is falsifiable.

Follow-up

  • How would you detect that the metric is being gamed rather than genuinely improving?
  • What would you do if the primary metric and the guardrail moved in opposite directions?

Walk me through your approach to tackling a new data science project.

Medium · product sense and metrics

Approach

  1. Decompose the metric into the rates that drive it, and say which one you would check first.
  2. Name one primary metric, then the guardrail that stops it being gamed.
  3. State what result would change your recommendation, so the answer is falsifiable.

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?

If you were given a dataset with unusual patterns, how would you investigate the anomalies?

Medium · product sense and metrics

Approach

  1. State what result would change your recommendation, so the answer is falsifiable.
  2. Fix the population and the time window before naming any metric.
  3. Decompose the metric into the rates that drive it, and say which one you would check first.

Follow-up

  • Which segment would you cut first, and what would that rule out?
  • What would you do if the primary metric and the guardrail moved in opposite directions?

Describe a project where you used data analysis to solve a business problem.

Medium

Approach

  1. State your assumptions explicitly before working the problem.
  2. Clarify what is being asked and what a complete answer would contain.
  3. Work from the decision backwards to the evidence you would need.

Follow-up

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

Score trial sites without rewarding enrollment that does not stick

Medium · site scorecards · shrinkage · guardrails · gaming

A clinical operations group ranks sites on subjects randomized per activated site-month, using study_subject_visit (study_id, site_id, subject_id, arm_code, randomization_ts, site_activation_date, visit_name, visit_number, visit_status, primary_endpoint_value, protocol_deviation_flag, deviation_severity). Bottom-ranked sites lose allocation on the next study. Define the primary metric, two guardrails, the handling of sites activated too recently to rank, and the estimator you rank on. Then state what a site under allocation pressure does to the number, and which guardrail sees it.

Approach

  1. Move the numerator from randomized to randomized and retained through the protocol-defined primary endpoint visit. A subject who randomizes and withdraws consumes screening, drug supply and monitoring while contributing nothing to the analysis population, so counting them rewards the wrong behaviour precisely when a site is under pressure.
  2. Build the denominator as exposure, not sites: site-months from site_activation_date to the earlier of period end and database lock, per study. Ranking on a raw count instead of a rate confuses a large site with a fast one.
  3. Handle young sites by reporting rather than dropping. Sites with fewer than a stated minimum exposure are shown in an insufficient-exposure band, because excluding them is how a non-enrolling tail disappears from a scorecard, and the non-enrolling tail is usually the larger operational problem.
  4. Rank on a shrunken estimate, not the raw ratio. With a few site-months of exposure the ratio has enormous variance, and a site with two site-months and one randomization will top an unshrunken table. Partial pooling toward the study mean, or a simple empirical-Bayes posterior mean, prevents rank being an artefact of small exposure.
  5. Pick guardrails that read the two pressure responses. A site that loosens eligibility judgement shows an implausibly low screen-failure rate, computed as subjects with randomization_ts NULL and visit_status screen_failed over subjects screened. A site that pushes visits to hit counts shows up in major protocol deviations per 100 completed visits, reported separately from minor ones because a single major deviation can remove a subject from the per-protocol set.
  6. Report the companion the median hides: the share of activated sites with no randomization by day 90. A median computed only over sites that eventually randomized is silent about the sites that never did.

Worked solution (30 min)

  1. Define the numerator as subjects with non-null randomization_ts whose primary endpoint visit reaches visit_status completed with a non-null primary_endpoint_value, per study and site.
  2. Compute site-months of exposure from site_activation_date to period end or database lock, and set the minimum exposure below which a site is banded rather than ranked.
  3. Compute the raw rate, then the shrunken estimate by partial pooling toward the study mean, and print both columns side by side so the shrinkage is visible rather than hidden.
  4. Specify the two guardrails with numerator, denominator and window, keeping major and minor deviations as separate series.
  5. Add the no-randomization-by-day-90 share across all activated sites, so the non-enrolling tail appears on the same page as the ranking.

Expected result: A scorecard whose primary metric is randomized-and-retained subjects per activated site-month per study, ranked on a shrunken estimate with the raw rate shown beside it; sites below a stated minimum exposure reported in an insufficient-exposure band rather than excluded; guardrails of screen-failure rate and major protocol deviations per 100 completed visits reported separately from minor ones; and a companion share of activated sites with no randomization by day 90.

Verify it yourself

  • Compare raw and shrunken rankings. The largest rank movements should be concentrated among the lowest-exposure sites; if a high-exposure site moves far, the pooling is misconfigured.
  • Confirm the denominator's site-months sum matches an independent count of months between activation and period end across all sites.
  • Check that screen failures are being counted at all: a site reporting a zero screen-failure rate across dozens of screened subjects is a data-capture problem or an eligibility-judgement problem, and both need an answer.
  • Verify that excluding the insufficient-exposure band does not change the study-level mean materially; if it does, those sites carry more of the study than the banding implies.

Follow-up

  • A site has the best randomized-and-retained rate and the worst major deviation rate. What do you recommend, and what would change your answer?
  • Your shrunken ranking moves a site from 3rd to 14th. How do you explain shrinkage to the site's operations lead in two sentences?
  • Primary endpoint retention takes 18 months to observe. What do you rank on in the meantime, and what bias does that interim choice introduce?

Allowed PMPM fell fourteen percent in three months

Easy · claims runout · completion factors · incurred vs paid

Allowed PMPM in the monthly series fell from $412 to $354 over the three most recent incurred months, and leadership wants to announce the saving. You have medical_claim_line (allowed_amount, service_start_date, received_date, paid_date, claim_id, claim_version, frequency_code, place_of_service_code), pharmacy_claim (allowed_amount, fill_date, reversal_flag) and member_enrollment coverage spans. The chart carries no paid-through date. Work out how much of the fall survives completion, and hand back a restated series with an explicit paid-through date and the completion factors you applied.

Approach

  1. Get the paid-through date first and put it on the chart. Without it the series is uninterpretable, because every incurred month is a different age.
  2. Build a lag triangle: for each incurred month, cumulative allowed_amount by the number of months between service_start_date and paid_date, on surviving claim versions only (drop frequency_code 8 voids and keep the highest claim_version per claim_id).
  3. Estimate development factors separately for pharmacy fills, professional lines and inpatient facility lines. Pharmacy adjudicates within days, professional within weeks, inpatient facility over months, so one blended factor understates the correction on the newest month and overstates it on the oldest.
  4. Gross each of the last three incurred months up by the reciprocal of its cumulative development factor, using factors fitted on months that have already fully run out.
  5. Rebuild the denominator independently as member-months from coverage spans. Member-months are complete on day one, so if the denominator also shows a lag pattern the enrollment file is late, which is a different bug with a different fix.
  6. Restate the series, mark the last three months as estimated, and report the residual movement after completion as the only part worth investigating.

Follow-up

  • The completed series still shows a three percent fall. What do you look at next, and in what order?
  • How would you detect that the fall is a mix shift toward cheaper services rather than lower volume?
  • A contract settles on this number at a fixed paid-through date. What do you owe the other party about the estimate you just made?

Suggested practice checklist

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

Day 1 — Diagnostic, scored before you study anything

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

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

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

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

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

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

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

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

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

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

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

Day 5 — The gap that is not a skill

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

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

Day 6 — Retest under day-one conditions

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

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

Day 7 — Full loop under interview conditions

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

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

Ownership when the result is inconvenient

Sometimes the honest read is that the initiative did not work, and the person who commissioned the analysis was hoping otherwise. Interviewers want to know whether you softened it. Prepare the case where you delivered an unwelcome result, how you presented the uncertainty without hiding behind it, and what the team did next.

Describe a time when you had to work with a difficult team member. How did you handle the situation?

Medium · behavioural and stakeholder questions

Approach

  1. Name the disagreement or constraint, and how you resolved it with evidence.
  2. State the situation in two sentences and spend the rest on your reasoning.
  3. Pick a story where you drove the decision, not one where you observed it.

Follow-up

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

Scope a one-line request for a readmission rate

Easy · scoping · measure specification · stakeholder communication

A clinical operations lead messages you: 'What is our readmission rate? The committee meets Friday.' You have encounter (encounter_id, admit_ts, discharge_ts, encounter_type, admission_type, discharge_disposition, drg_code, index_encounter_id) and member_enrollment coverage spans. Do not open a query editor yet. Deliverable: the three to five questions you send back, ranked by how much the answer moves the number; the default specification you will build if nobody replies by Wednesday; and the one line you will place under the figure so the committee does not read it against a published benchmark.

Approach

  1. Read the probe: this tests whether you convert ambiguity into a specification without either stalling or guessing silently. Both failure modes are common, and the silent guess is worse because nobody can see it.
  2. Rank your questions by leverage on the number rather than by curiosity. Whether the numerator is all-cause or unplanned, and whether the clock starts at discharge_ts, move the result far more than a tie-break rule on same-day returns.
  3. Ask about the comparison first. A number going to a committee will be compared to something, and whether that something is last quarter, another panel, or a national figure decides whether you owe them a raw rate, a risk-adjusted rate, or an observed-over-expected ratio.
  4. Commit to a default in writing so silence does not block you: unplanned acute inpatient readmission within 30 days of discharge_ts, index stays excluding planned admissions, acute-to-acute transfers, discharges against medical advice, and dispositions of expired or hospice, denominator of eligible index discharges, paid-through date stated.
  5. Write the caveat as a restriction on use rather than a hedge: name the one comparison the figure supports and the one it does not.

Follow-up

  • They reply that they want it 'the way the benchmark does it'. What do you ask next?
  • The committee wants it split by attending provider. What changes in the specification, and what do you refuse to show?
  • How does your answer change if the meeting is tomorrow rather than Friday?

Make an honest case for your own analytical impact

Hard · impact attribution · counterfactual · self-assessment

You are asked to account for a year of your work. Constraint: you may only use measures that existed before you knew the outcome, and you must include one project that moved nothing. The portfolio contains a measure specification that changed how a contract settles, a predictive model that shipped, a self-serve dashboard, and an evaluation that killed a proposed programme. Deliverable: how you attribute value to each, which of them you claim credit for and which you do not, and the one number you would accept being judged on next year.

Approach

  1. The probe is whether you can reason counterfactually about your own work, which is the same discipline this domain demands of you for programmes, applied where it is uncomfortable.
  2. State the counterfactual for each item: what would have happened without you. A measure specification that changed how a contract settles has a dollar counterfactual you can compute. A dashboard's counterfactual is analyst hours, which is real and small, and attaching a revenue number to it is where these accounts usually turn into fiction.
  3. Treat the killed programme as your strongest item and say why. Avoided spend is real value, it is attributable because the decision turned on your evaluation, and it is the one item nobody else will count on your behalf.
  4. Report the shipped model the way you would report anyone's model: calibration in the subgroups that matter, adoption by the people it was built for, and whether any decision changed. A model that is live but ignored has zero impact, and saying so is the credibility test in this answer.
  5. Name the failed project with its mechanism and its cost, then say what earlier signal you would watch to kill it sooner. Time to kill is a legitimate impact measure.
  6. Choose next year's number so that it can go down. A metric that only ratchets upward is not a commitment.

Follow-up

  • Two other people also claim the contract measure. How do you split it?
  • Your model is live and used, but the decisions it informs would have been the same without it. Is that impact?
  • What is the strongest argument that your year had less impact than you just described?