cswork / libraryOpen practice workspace

Interview guides · Heal

Heal Data Scientist Interview Questions & Guide 2026

A two-week prep plan for Heal data scientist candidates: write your answer before reading the solution, revisit misses three days later.

The 60-second brief

The role of a Data Scientist at Heal is pivotal for leveraging data to drive insights that enhance healthcare solutions. By employing advanced analytical methodologies, a Data Scientist contributes to the development and optimization of Heal's services, which aim to provide accessible and effective healthcare. This position is not only about crunching numbers; it involves understanding complex datasets to inform decision-making processes that ultimately enhance patient care and operational efficiency.

Coding rounds for this role are usually data-manipulation shaped rather than data-structure shaped: group-bys, joins, time windows, ranking within a partition. Confirm the format before spending a week on graph traversal.

Focus areas

  • Reconstruct drug exposure intervals from dispensing records
  • Separate censoring from events in time-to-event models
  • Build member-month denominators from overlapping coverage spans

Overview

In this role, you will engage with diverse teams, including product development and engineering, to solve pressing challenges within the healthcare landscape. Your work will directly influence Heal’s ability to innovate and respond to user needs, making this position both impactful and rewarding. You can expect to work on projects that involve data cleaning, exploratory data analysis (EDA), and possibly predictive modeling, all aimed at improving Heal's offerings and user experience.

The Heal interview process

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

Phone Screening

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

This round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.

What to demonstrate

  • Whether your row counts survive each join, and whether you notice on your own when they do not
  • Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
  • Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
  • Reaching a defensible answer inside the window instead of a refined one after it

How to prepare

  • Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
  • Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
  • Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither

Behavioral Interview

Behavioural answers from data candidates get audited in a way that answers from other roles do not. When you say a model lifted retention, the next question is the denominator, the window, and how you knew the lift was not seasonal. So attach the measurement to each claim while you tell it: what the metric was before, over what period, and against what comparison. Numbers with no baseline read as rounded-up memory, and one unsupported figure tends to make the rest of the story sound rehearsed.

What to demonstrate

  • Whether each impact number arrives with a baseline, a window and a comparison, or as a bare percentage
  • Whether you can name the method that attributed the effect to your work (an experiment, a staged rollout, a seasonal control) or concede the link was correlational
  • Whether the magnitudes stay internally consistent when the interviewer multiplies them against the scale you described earlier

How to prepare

  • For each story, write the impact line as metric, value before, value after, window, and how attribution was established. Any line missing two of those five is a follow-up you will answer badly.
  • Re-derive one headline number from the source table rather than the deck that reported it. Resume numbers drift upward across retellings.
  • Decide in advance which figures you cannot share, and prepare the ratio or relative change you can give instead, so a confidentiality limit does not read as evasion.

Take-home Assignment

Before any modelling, the dataset is itself the first test. Take-home data usually carries something broken: rows duplicated at an unexpected grain, a join that silently drops part of the population, timestamps stored in more than one timezone, or missingness correlated with the outcome. An hour spent profiling row counts, key uniqueness and date ranges is not overhead, because it decides whether every number after it is real. What separates submissions is whether you report the defects you found and adapt the analysis to them, rather than modelling over them quietly and hoping the aggregate absorbs it.

What to demonstrate

  • Whether you established the grain of each table and checked row counts after every join, and said so in the writeup
  • Whether data defects you found are surfaced with their effect on the conclusion, instead of being dropped without comment
  • Whether filters and exclusions are reproducible from the submitted code, with the size of the excluded population quantified

How to prepare

  • Write a short profiling script you can point at any unfamiliar table: row count, distinct key count, null rate per column, and the min and max of every date field, then run it before anything else
  • Write the funnel or the join chain as one query and check the row count at each grain, so a silent fan-out shows up as a number rather than as a wrong answer later
  • On a past dataset, list every exclusion you applied and how many rows each one removed, then draft the single sentence about it you would put in a report

Where candidates lose points

Reading the most recent months of a claims-based series as real

Claims incur before they are reported and paid, so recent incurred months are systematically undercounted until runout completes. The lag is not uniform: pharmacy adjudicates in days, professional claims in weeks, inpatient facility claims in months. That means recent data is both too low and mix-shifted toward cheap services, which reads as a cost improvement and a utilisation drop at once. The fix is to hold the last three incurred months back or apply completion factors, and to state the paid-through date on every chart.

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.

Reading an observational correlation as a causal effect

Name the confounder you are most worried about and the design that would remove it: an experiment, a difference-in-differences with a checked pre-period trend, an instrument, or a regression discontinuity. When none is available, state which direction the bias likely runs and bound the claim accordingly.

Explaining an aggregate move without decomposing the mix shift

Split the change in the aggregate into within-segment movement and movement in segment weights before you explain it. Every segment's rate can fall while the overall rate rises, purely because volume shifted toward segments that already had higher rates.

Questions & practice

Write a function to calculate the correlation between two datasets.

Medium · statistics and probability

Approach

  1. Say what the estimate is of, and over what population it generalises.
  2. Write down the assumption the method needs before you use the method.
  3. Quantify uncertainty explicitly rather than reporting a point estimate alone.

Follow-up

  • What sample size would you need to detect an effect half this size?
  • How would you explain this result to someone who does not know statistics?

Explain a time you used a machine learning model to solve a real-world problem.

Medium · machine learning and modelling

Approach

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

Follow-up

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

Expand overlapping coverage spans into fractional member-months

Medium · interval expansion · denominators · vectorisation

member_enrollment has span_id, member_id, plan_id, product_type, effective_date, termination_date (NULL while active). Both dates are inclusive. Write a function returning one row per calendar month of a stated year with total member-months, where a member contributes covered days in the month divided by days in that month, capped at one month per member even when two spans overlap after a plan change or a retroactive span. Do not expand to one row per member-day: the sample has 400,000 members. Output: month, member_months.

Approach

  1. Resolve NULL termination_date to the reporting end date and say so in a comment. An open span is not an infinite span, and clipping it at the year end is what keeps the denominator finite and auditable.
  2. Merge overlapping and adjacent spans per member before touching months. Sort by member_id and effective_date, carry a running maximum of the end date, and open a new merged group when effective_date exceeds that running max plus one day. Adjacent means a gap of zero days, which a plan change produces constantly.
  3. Cross join the merged spans to the 12 month boundaries rather than to days. Overlap days = (min(span_end, month_end) - max(span_start, month_start)).days + 1, clipped below at 0. That is at most 12 rows per span instead of 365.
  4. Divide overlap days by the number of days in that month, so February and July are weighted correctly, then sum by month.
  5. Validate on a constructed member before trusting the aggregate: a single span covering the whole year must sum to exactly 12.0.

Worked solution (30 min)

  1. Fill termination_date nulls with the reporting end date and clip all spans to the reporting year.
  2. Sort by member_id, effective_date, then compute a running max end per member with cummax shifted by one, flag a new group where effective_date > prior_max_end + 1 day, and cumsum the flag to get merged group ids.
  3. Aggregate each group to min start and max end, producing disjoint spans per member.
  4. Cross join merged spans to a 12-row month frame, compute clipped overlap days, divide by days in month.
  5. Group by month and sum.

Expected result: Twelve rows. For a member with spans 2026-01-01 to 2026-03-15 and 2026-03-01 to 2026-06-30, March contributes exactly 1.0, not 15/31 plus 31/31. For a member with spans covering January and March only, January is 1.0, February is 0.0, March is 1.0, and the member totals 2.0.

Verify it yourself

  • A member with one span covering the full year sums to exactly 12.0 across the twelve rows.
  • Total member-months is less than or equal to (distinct members) x 12, and equality holds only if every member is covered all year.
  • Re-running the span merge on its own output changes nothing, which proves the merged spans are disjoint.
  • Recompute one member by brute-force day expansion and confirm the two agree to floating point tolerance.

Follow-up

  • Product type changes mid-year. The metric must be reported by product_type. Where does the cap now apply and what breaks?
  • An eligibility file arrives with a retroactive termination that shortens a span you already reported on. How do you restate?
  • Why member-months rather than distinct members, in one sentence, for a director who wants the simpler number?

How would you optimize a slow-running SQL query?

Medium · sql and data manipulation

Approach

  1. State the window function and its partition and ordering out loud before writing it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. 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?

Describe the differences between supervised and unsupervised learning.

Medium · sql and data manipulation

Approach

  1. Check whether any join is one-to-many before aggregating, or the sums inflate.
  2. Say which table is the grain you start from, and join outward from it.
  3. State the window function and its partition and ordering out loud before writing it.

Follow-up

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

Find inpatient encounters with no resulted lab during the stay

Medium · anti-join · null semantics · event matching

encounter holds encounter_id, patient_id, encounter_type, admit_ts, discharge_ts and facility_id. lab_result holds result_id, order_id, patient_id, encounter_id (NULL for outpatient standing orders), loinc_code, specimen_collected_ts, resulted_ts and result_status. Return every inpatient encounter discharged in 2025 with no final or corrected lab_result linked to it. A colleague wrote WHERE encounter_id NOT IN (SELECT encounter_id FROM lab_result) and got zero rows back. Say why, write the correct query, then say what changes when labs must instead be matched on patient_id with the specimen collected between admit_ts and discharge_ts.

Approach

  1. Name the mechanism rather than the symptom. x NOT IN (subquery) expands to x <> y1 AND x <> y2 AND ..., and a single NULL y makes that chain UNKNOWN, never TRUE. Since lab_result.encounter_id is nullable by design for standing orders, this query can only ever return zero rows.
  2. Rewrite as NOT EXISTS, or LEFT JOIN with an IS NULL filter. Both treat a NULL key as no match rather than as unknown. Adding IS NOT NULL inside the NOT IN subquery also works, but NOT EXISTS is the habit that survives someone making another column nullable later.
  3. Put the result_status predicate inside the correlated subquery or the ON clause, not in an outer WHERE. Outside, it turns the anti-join back into an inner join and an encounter whose only labs were cancelled disappears instead of qualifying.
  4. For the timestamp variant, match on patient_id with specimen_collected_ts inside the stay rather than resulted_ts. A specimen drawn an hour before discharge can result the next day, and anchoring on resulted_ts would wrongly call that stay lab-free.
  5. Restrict to encounter_type 'inpatient' and discharge_ts in 2025, and report open encounters with a NULL discharge_ts as a separate count instead of letting the filter swallow them.

Worked solution (20 min)

  1. Demonstrate the cause: SELECT COUNT(*) FROM lab_result WHERE encounter_id IS NULL returns a non-zero number.
  2. Write the NOT EXISTS version with result_status IN ('final','corrected') inside the correlated subquery.
  3. Write the LEFT JOIN version with the same predicate in the ON clause and WHERE l.result_id IS NULL, then compare counts.
  4. Build the timestamp variant joining on patient_id with specimen_collected_ts >= admit_ts AND < discharge_ts.
  5. Report both counts side by side and explain which encounters differ between the two definitions.

Expected result: One row per qualifying inpatient encounter with encounter_id, patient_id, facility_id, admit_ts and discharge_ts. The count is strictly below total 2025 inpatient discharges and strictly above zero, while the NOT IN version returns exactly zero rows.

Verify it yourself

  • NOT EXISTS and LEFT JOIN with IS NULL return identical row counts.
  • Adding AND encounter_id IS NOT NULL inside the NOT IN subquery reproduces the NOT EXISTS count exactly.
  • No returned encounter_id appears anywhere in lab_result with result_status in ('final','corrected').
  • The patient-and-timestamp variant returns fewer encounters than the encounter_id variant, since it also catches labs whose encounter link is missing.

Follow-up

  • Write the LEFT JOIN form and say exactly where the result_status predicate must sit for the two forms to agree.
  • How would you separate encounters whose only labs were cancelled from encounters with no lab rows at all?
  • Some encounters carry member_id NULL because the person index did not match. What does that do to a payer-side version of this measure?

How do you prioritize tasks when dealing with multiple projects?

Medium · product sense and metrics

Approach

  1. Name one primary metric, then the guardrail that stops it being gamed.
  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?
  • How would you detect that the metric is being gamed rather than genuinely improving?

If you were tasked with predicting patient outcomes, what steps would you take?

Medium · product sense and metrics

Approach

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

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?

How would you approach a situation where the data is inconclusive?

Medium · product sense and metrics

Approach

  1. Restate the decision this analysis has to support, and who acts on the answer.
  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?
  • How would you detect that the metric is being gamed rather than genuinely improving?

Describe your process for identifying key metrics for a new healthcare initiative.

Medium · product sense and metrics

Approach

  1. Fix the population and the time window before naming any metric.
  2. Name one primary metric, then the guardrail that stops it being gamed.
  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?

Can you discuss a project where you had to clean and prepare a dataset?

Medium

Approach

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

Follow-up

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

Set the decision rule when cost and denial guardrails conflict

Medium · guardrail conflict · denials · non-inferiority bound · audit sampling

Utilization management is asked to cut risk-adjusted allowed PMPM, and its lever is prior authorization and first-pass denial on advanced imaging and specialty drugs. The scorecard guardrail is first-pass denial rate from medical_claim_line (claim_status, denial_reason_code, claim_version, received_date) paired with the overturn rate on appealed denials. The two move in opposite directions by construction. Write the decision rule: which metric binds, at what pre-declared threshold, who adjudicates a breach, and what happens on breach. Do not resolve the conflict by weighting both into one score.

Approach

  1. Say why a composite is the wrong instrument: the weights get chosen after someone has seen which way the quarter went, and any weighted sum lets a large enough cost win purchase an unbounded increase in wrong denials. A guardrail is a constraint, not a term in an objective.
  2. Sharpen what the guardrail is actually protecting. A higher denial rate is not by itself a harm, since some denied claims should be denied. The harm is denials that should not have been made, so split first-pass denials by denial_reason_code into administratively correctable ones (eligibility, coding, missing documentation) and clinical-necessity ones, and put the bound only on the clinical group.
  3. Fix the measurement of the guardrail before setting its threshold: count the denominator at claim_version 1 so replacements (frequency_code 7) and voids (8) are not double counted, hold the month back for 60 days of adjudication runout, and report by received_date.
  4. Get the direction of the appeal-selection bias right. Appeals are filed on the denials the appellant already believes are wrong, by the members and providers with the staffing, literacy and dollar threshold to file at all, and an appeal usually arrives carrying documentation the first adjudication never had. The overturn rate on appealed denials therefore runs well above the wrong-denial rate across all denials, often by a multiple, and it moves with filing behaviour as much as with adjudication quality. The unbiased population estimate is a blind re-review of a random sample of all denied clinical-necessity lines each quarter, judged on the record as it stood at first adjudication; the appeal series is a fast indicator read against its own history between audits, not a second estimate of the same quantity.
  5. Write the rule as a bound with a consequence: risk-adjusted allowed PMPM is the primary and binds only while the audited wrong-denial rate stays within a pre-declared absolute margin of its trailing four-quarter mean. Breach stops the program's expansion rather than discounting its score, and the margin is set before the quarter opens.
  6. Name the adjudicator and the cadence: a clinical owner outside the utilization function, reviewing at the stated paid-through date, with the breach consequence written down before any result is known.

Worked solution (25 min)

  1. Restate the guardrail metric properly: numerator is claim lines denied at first adjudication, denominator is lines received in the month counted at claim_version 1, held 60 days, broken out by denial_reason_code group.
  2. Split denial_reason_code into administratively correctable and clinical-necessity groups and say which function owns each, since the two have different fixes and different harms.
  3. Write the appeal-selection argument in two sentences, including which way it runs, and specify the random blind re-review: the frame it is drawn from, namely all denied clinical-necessity lines rather than appealed ones, plus sample size, who reviews, what record they are shown, blinding, and quarterly cadence.
  4. State the bound as an absolute margin on the audited wrong-denial rate against its trailing four-quarter mean, with the margin fixed before the period.
  5. Write the breach consequence and the named adjudicator, and note that both are recorded before results exist.

Expected result: A written rule in which risk-adjusted allowed PMPM is primary; the binding guardrail is the audited wrong-denial rate on clinical-necessity denials, estimated from a blind random re-review of all denied clinical-necessity lines, with the appeal overturn rate kept as a between-audit indicator that runs above the audited rate and never sets the bound; the bound is a pre-declared absolute margin against a trailing four-quarter mean; a clinical owner outside utilization management adjudicates; and a breach halts expansion rather than adjusting a score.

Verify it yourself

  • Recount the denominator with and without version dedup. If the two differ by more than a percent or two, the incumbent number has been counting resubmissions.
  • Re-run a closed month at two extract dates 60 days apart. A moving denial rate means the runout hold is too short.
  • Compare the audited wrong-denial rate to the appeal overturn rate for the same quarter. The overturn rate should be the higher of the two, usually by a multiple, because appeals are filed on the denials most likely to be wrong and often add documentation the first adjudication never saw. An audit rate at or above the overturn rate is the anomaly: check that the sample was drawn from all denied clinical-necessity lines rather than only appealed ones, and that the reviewers were blinded and shown the record as it stood at first adjudication.
  • Confirm the margin, the adjudicator and the consequence are all recorded with a timestamp before the period's data was available.

Follow-up

  • Denials rose and the overturn rate fell. Give the benign reading and the bad reading, and the one number that separates them.
  • What happens to your bound if the appeal filing rate per denial drops 30 percent in the same quarter?
  • How large a random audit sample do you need to detect a 2 percentage point rise in wrong denials off a 6 percent base, and what does that cost in clinician review hours?

Readmission rate rose while every facility improved

Medium · simpsons paradox · mix shift · risk adjustment

Quarter over quarter the 30-day unplanned readmission rate for an attributed population rose from 14.2 to 15.1 percent, yet all eleven facilities in encounter show a flat or falling rate over the same period. You have encounter (facility_id, admit_ts, discharge_ts, encounter_type, admission_type, discharge_disposition, drg_code, is_planned_admission, index_encounter_id) and twelve months of prior medical_claim_line for comorbidities. Explain the direction reversal numerically, and state what the population-level number should be reported as instead.

Approach

  1. Confirm the reversal is arithmetic, not a definition difference, by recomputing both the facility rates and the pooled rate from the same query with the same index-stay exclusions.
  2. Decompose the pooled change exactly with a Kitagawa split. With facility weights w and within-facility rates r, the change equals the sum over facilities of (w_1 - w_0) times (r_0 + r_1)/2, the mix term, plus the sum of (w_0 + w_1)/2 times (r_1 - r_0), the within term. If the mix term exceeds the total change and the within term is negative, the reversal is volume shifting toward facilities with higher baseline rates.
  3. Ask why the weights moved. Check index-stay volume by facility, and check whether an exclusion changed behaviour: acute-to-acute transfers (discharge_disposition 'transfer_acute') must not open an index stay, and if one facility began transferring more, its denominator shrinks toward its sickest retained patients.
  4. Check case mix inside the facilities too, using drg_code and comorbidities drawn from the 12 months of claims before admit_ts, excluding complications of the index stay itself. A facility rate can be flat while its case mix worsens.
  5. Replace the raw pooled rate with an observed over expected ratio, where expected is the sum of predicted probabilities from a model fitted on age, sex and prior comorbidities. Raw rates are not comparable across a population whose facility and case mix is moving.

Follow-up

  • Your O/E ratio is 1.04 with a 95 percent interval of 0.96 to 1.13. What does that let you say to a facility, and what does it not?
  • If one facility contributes 40 percent of index stays, how does that change how you present the decomposition?
  • How would you handle a member with two index stays in the quarter, where the second is also a readmission from the first?

Suggested practice checklist

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

Day 1 — Diagnostic, scored before you study anything

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

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

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

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

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

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

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

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

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

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

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

Day 5 — The gap that is not a skill

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

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

Day 6 — Retest under day-one conditions

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

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

Day 7 — Full loop under interview conditions

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

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

The project you argued against

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

Describe your experience with data visualization tools.

Medium · behavioural and stakeholder questions

Approach

  1. Close with what you would do differently, concretely.
  2. Name the disagreement or constraint, and how you resolved it with evidence.
  3. Pick a story where you drove the decision, not one where you observed it.

Follow-up

  • What did you decide not to do, and why?
  • What would you do differently if you ran that project again?

Own an analysis that shipped wrong and was acted on

Easy · retrospective · ownership · data quality

Describe an analysis you delivered that was wrong, where someone acted on it before the error surfaced. Pick something with a mechanism you can name, not a typo. Cover what the number claimed, what was actually true, how much time passed before it was caught, who caught it, and what you told the people who had already acted. Deliverable: a five-minute account that ends with the specific control you added afterwards, plus one occasion since when that control has fired.

Approach

  1. Read the probe: the interviewer is testing whether you detect your own errors and whether the correction was structural. Pick an error with a nameable mechanism (a denominator built from distinct members instead of member-months, a series read before claims runout completed, a cohort selected on the outcome) so the story has a diagnosis rather than a mood.
  2. Open with the decision that was made on your number, not with the bug. The severity of an analytic error is measured in the action it caused: a rate filing, a staffing plan, a programme expansion.
  3. State the counterfactual number. 'The true figure was 14.1 admissions per 1,000 member-years, not 9.8' is a fact; 'it was off by a lot' is not.
  4. Describe the detection path honestly, including whether you found it or somebody else did. Say how long it took, because time to detection is the part you actually control next time.
  5. Close on the control, and make it something that protects a reader who has never met you: a unit test on the denominator, a paid-through date stamped on every chart, a required exclusions block in the spec template. Name one later date it caught something.

Follow-up

  • What would have had to be true for you to catch this before delivery rather than after?
  • Did the stakeholder change how much they trust your work, and did you want them to?
  • Give an example of a control you added that turned out to be the wrong control.

Disagree with a product manager about an adherence nudge

Medium · immortal time · confounding · disagreement

A product manager proposes shipping a refill-reminder feature to the whole member base, citing an internal analysis: members with 12-month proportion of days covered at or above 0.80 had 31 percent fewer admissions than members below it. The roadmap date is three weeks out and engineering is scoped. You believe the comparison builds survival and continuous coverage into the exposure definition, and is separately confounded by the kind of member who refills on time. Deliverable: what you say in the room, what you send afterwards, and the smallest study you would accept as sufficient to ship.

Approach

  1. The probe is whether you can be specific and non-territorial at once. A disagreement that arrives as 'the analysis is flawed' costs you the room; one that names a mechanism and offers a cheaper path keeps it.
  2. Name the two defects separately, because they have different fixes. Classifying a member as adherent over 12 months requires them to stay alive and stay covered for those 12 months, and that guaranteed event-free interval is assigned to the adherent group. Separately, members who refill on schedule differ from those who do not in ways claims never record.
  3. Show rather than assert. Rerun the same comparison as a landmark analysis: classify adherence over days 1 to 90, start follow-up at day 91 for everyone still enrolled and event-free, and report how much of the 31 percent survives.
  4. Separate the association claim from the intervention claim out loud. Nothing in the analysis speaks to whether a reminder changes refill behaviour, which is the actual product question and is separately testable.
  5. Offer the shippable path: a randomised holdout on a subset with proportion of days covered as the primary endpoint, powered on the plausible effect of a reminder rather than on the 31 percent, with a stated read date.

Follow-up

  • The landmark rerun still shows a 20 percent difference. Do you ship?
  • The product manager says a holdout delays launch. How do you cost that argument?
  • What primary endpoint do you choose, and why not admissions?