Gusto Data Scientist Interview Questions & Guide 2026

Interviewing at Gusto

• Practice bank: 11+ questions
• Rounds: 2
• Typical prep: 1–2 weeks

Interview rounds

Round	Questions
Technical Screen	9
Onsite	2

How hard is the Gusto Data Scientist interview?

Difficulty	Share	Questions
Easy	9%	1
Medium	91%	10
Hard	0%	0

What Gusto actually tests for

Topic	Share	Questions
Analytics & Experimentation	55%	6
Machine Learning	18%	2
Behavioral & Leadership	9%	1
Data Manipulation (SQL/Python)	9%	1
Statistics & Math	9%	1

The 60-second brief

A Data Scientist at Gusto plays a pivotal role in shaping the financial security and operational success of hundreds of thousands of small businesses. Operating at the intersection of product, engineering, and business strategy, data scientists at Gusto do not simply build models in isolation; they design the analytical foundation that powers critical business decisions. Whether optimizing payroll routing, detecting transaction fraud, or building recommendation engines for employee benefits, your work directly impacts the livelihoods of millions of workers across the United States.

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

What a Data Scientist does at Gusto

The data ecosystem at Gusto is exceptionally rich but highly complex. Because the platform handles sensitive payroll, tax, benefits, and compliance data, the challenges you will solve require an uncompromising commitment to precision, security, and scalability. As a Data Scientist, you will work on core product features, risk mitigation in payments, and predictive modeling to help small business owners navigate complicated regulatory environments with ease.

To succeed in this role, you must possess a blend of rigorous technical capability and strong business intuition. The data science team is highly collaborative, meaning you will frequently partner with product managers, engineers, and risk operations teams. The ideal candidate is someone who thrives in ambiguity, translates complex business problems into structured technical frameworks, and communicates data insights as compelling, actionable narratives.

The Gusto interview process

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

Initial Screening

Most candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.

What it evaluates

• Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
• Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
• The substance of the questions you ask back, which an experienced screener reads as a level signal

How to prepare

• Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
• Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
• Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered

Technical Screening

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

What it evaluates

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

How to prepare

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

Virtual Onsite Loop

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

What it evaluates

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

How to prepare

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

Questions Gusto candidates report

Product sense and metrics

Decomposition questions are arithmetic before they are judgement. A top-line number is a product or a sum of smaller terms, and a tree is only useful if those terms recombine into the thing at the top and do not overlap: users times sessions per user times actions per session, or this month's actives as last month's carried forward, plus new, plus resurrected, minus churned. Build the identity first and attach levers to the leaves second. Trees come apart when a branch is a metric someone likes rather than a term in the arithmetic, because one underlying change then shows up in two branches and neither explains it.

• If we observe a sudden drop in the completion rate of our onboarding flow, how would you investigate the root cause?
• Share an experience where you had to manage competing priorities from different stakeholders. How did you decide what to prioritize?
• What metrics would you use to measure the health and engagement of our core payments product?
• What metrics would you track to determine if a recommendation engine for health insurance plans is performing successfully?

SQL and data manipulation

Funnels and retention read as counting problems and behave as time problems. Step two has to follow step one for the same user, inside a window someone has to define, and a cohort clock usually starts at each user's own first event rather than at a calendar boundary. Before writing, pin down which timestamp is event time rather than load time, whether your interval is half-open so a midnight row lands in exactly one bucket, and what time zone the reporting day belongs to. The usual failure is a query that looks right and whose day boundaries quietly belong to a different zone than the number it is compared against.

• Write a query to identify the top three highest-paying payroll runs for each business category in a given month.
• Explain the difference between a LEFT JOIN and an INNER JOIN in a scenario where some business profiles have missing tax identifiers.

A/B testing and experimentation

The standard analysis assumes one unit's treatment cannot affect another unit's outcome. Say that assumption out loud, then ask where it breaks in the setting you were handed: shared supply, a shared budget, a ranking that reorders when other people click, any two-sided market where the arms compete for the same inventory. Interference does not merely add noise, it biases the estimate, and where the arms compete for scarce supply it usually flatters the treatment because the control group absorbs the cost. The answer that lands names the channel the spillover travels through, then changes the design rather than the test.

• How would you design an A/B test to evaluate a new user interface for the payroll submission portal?
• How do you balance statistical significance with business urgency when running experiments on low-traffic features?

Machine learning and modelling

A model that clearly improves offline can move nothing online, and the useful question is why. The candidate set feeding it may already exclude the cases it would have caught. The score may enter a surface where a cap, a fallback or a business rule blunts it. Training labels may describe a population the live traffic no longer matches, because they were collected under an earlier policy. Treat the offline number as a filter rather than as proof, plan the launch as a measured rollout with a guardrail and a rollback, and say which of those gaps you would check first.

• Explain how you would handle highly imbalanced datasets when training a model to predict employer churn.

Behavioural and stakeholder questions

Ownership questions usually arrive disguised as something else: a project that slipped, a pipeline that failed quietly, a number people had been reading wrong for months. What is being tested is what you did in the window before anyone told you it was yours. Be concrete about the first hour. Who you told, and what you checked before you knew how bad it was. The answer that falls short is the one that jumps from discovery straight to resolution and skips the part where you sized the damage, because sizing it is the decision everything else depended on.

• Tell me about a time you had to work with highly ambiguous requirements. How did you define the scope of the project and deliver results?

Practice exercises with worked solutions

The prompts above tell you what gets asked.

Count-weighted and dollar-weighted approval rates on one currency

Using fct_payment_authorization, report the trailing 7-day authorization approval rate two ways for transaction_currency = 'EUR': count-weighted, and dollar-weighted on amount_minor. Exclude is_reversal = true, exclude incremental authorizations (parent_auth_id not null), and exclude zero-amount account verifications. auth_result = 'approved' is the numerator; the four declined_* values make up the rest of the denominator. Return channel, attempts, approved_attempts, approval_rate_count and approval_rate_value. State every exclusion and its reason before you write the SELECT.

How a strong candidate works it

• Say the denominator out loud first: attempts on a single transaction currency, excluding reversals, incremental authorizations and zero-amount verifications, because none of those is a purchase attempt a merchant is trying to get approved.
• Filter requested_at against a half-open interval (>= start AND < end) so the boundary day is neither dropped nor double counted.
• Compute both rates in one pass with FILTER clauses: COUNT() FILTER (WHERE auth_result = 'approved') over COUNT(), and SUM(amount_minor) FILTER (WHERE auth_result = 'approved') over SUM(amount_minor).
• Cast one side of each ratio to numeric before dividing, since amount_minor and the counts are integers and integer division silently truncates to zero.
• Group by channel and sort by the value-weighted rate, then read the gap between the two rates as a statement about where the declines sit rather than as noise.

Expected result (20 min): One row per channel present in the window, with attempts and approved_attempts as integers and both rates as numerics strictly between 0 and 1. approval_rate_value is typically lower than approval_rate_count on ecommerce and moto, because declines concentrate in higher-value card-not-present traffic.

Check yourself

• SUM(attempts) across channels equals a separate COUNT(*) run with the same four filters and no GROUP BY.
• Dropping the amount_minor > 0 filter raises attempts and moves approval_rate_count while leaving approval_rate_value unchanged, which confirms the zero-amount rows were only ever affecting the count-weighted figure.
• Both rates are strictly less than 1 unless a channel had no declines at all in the window.

Follow-ups

• The two rates diverge by four points on the ecommerce channel but agree on card_present. What does that tell you, and what would you cut next?
• How would you extend this to all currencies without summing amount_minor across them?
• Which of the four decline reasons belong in the denominator of a rate you would put in front of a risk team, and which are really the network's problem?

Build a vintage delinquency table without pivot or unstack

fct_loan_performance_monthly gives loan_id, origination_month, months_on_book, days_past_due, charge_off_flag and restructured_flag. Produce a DataFrame with one row per origination_month and columns for months_on_book 0 through 12, each cell holding the share of that vintage's funded loans that had ever reached 90 or more days past due, or charge-off, by that age. You may not use pivot, pivot_table, crosstab or unstack. Cells for ages a cohort has not yet reached must be NaN rather than zero.

How a strong candidate works it

• Define the per-row indicator as days_past_due >= 90 or charge_off_flag, then take a cumulative maximum of it per loan ordered by months_on_book, because the metric is reached-by-age-m, not in-that-state-at-age-m.
• Deal with restructuring before the cumulative max. Restructuring resets days_past_due, so a restructured loan re-enters at current and, without the cumulative maximum carrying its pre-restructure worst state, reads as a cure.
• Fix the denominator once as the count of distinct loan_id per origination_month across the whole cohort. Prepaid and charged-off loans stop producing rows, so a denominator recomputed at each age silently shrinks exactly where losses land.
• Aggregate with groupby(['origination_month','months_on_book'])['ever_90'].sum(), then pre-build the output frame indexed by sorted origination months with integer columns 0 to 12 and assign from the grouped Series by .loc on its index.
• Mask cells beyond each cohort's maximum observed months_on_book so an immature cell reads NaN instead of an artificially low rate.

Follow-ups

• Two adjacent vintages diverge at months_on_book 6. How would you separate seasoning, mix shift and a genuine credit-quality change?
• The three most recent vintages look best on this table. What do you check before saying so?
• How does the table change if charge-off policy moved from 180 to 120 days past due partway through the series?

Measure calibration of a twelve-month default probability from scratch

fct_loan_application gives application_id, model_pd_12m, model_version, decision, funded_at and loan_id. fct_loan_performance_monthly gives loan_id, months_on_book, days_past_due and charge_off_flag. Define the outcome as ever 90 or more days past due, or charged off, by months_on_book = 12. Without sklearn or scipy, build an equal-count binned reliability table, the expected calibration error, the Brier score and its reliability, resolution and uncertainty components, and report the residual the binned identity leaves behind. Restrict to cohorts that have actually reached 12 months on book.

How a strong candidate works it

• Build the label first and name the population it covers out loud: only funded loans have outcomes, so this measures calibration on the approved population. The declined region is unmeasured, and no binning scheme repairs that.
• Restrict to applications whose loans have reached months_on_book = 12. A cohort observed at 8 months has a mechanically lower default rate and will read as systematic over-prediction that is really just immaturity.
• Bin by equal count, deciles of model_pd_12m through a rank-based cut, not equal width. The PD distribution is heavily right-skewed, so equal-width bins put most of the mass in the first bin and leave the risky bins with single-digit counts whose observed rates mean nothing.
• Per bin compute n, mean predicted, observed rate, and the binomial standard error sqrt(o(1-o)/n) so a gap can be read against noise. ECE is the count-weighted mean absolute gap between mean predicted and observed.
• Compute Brier directly as the mean squared error, then reliability = sum of n_k (pbar_k - obar_k)^2 over N, resolution = sum of n_k (obar_k - obar)^2 over N, uncertainty = obar(1 - obar). Report residual = Brier - (reliability - resolution + uncertainty). That identity is exact only for discrete forecasts, so with binned continuous scores the residual is the within-bin spread of the score; a large one means the bins are too wide to support the decomposition.
• Split by model_version. A mixed-version population can look well calibrated in aggregate while each version is biased in opposite directions.

Expected result (45 min): A ten-row reliability table with n, mean predicted, observed and standard error; an ECE of a few tenths of a percentage point to a couple of points; a Brier score close to the uncertainty term, because a rare-event model has little resolution to subtract; and a residual small relative to the reliability term.

Check yourself

• Bin counts sum to the filtered row count, and the count-weighted mean of bin observed rates equals the overall observed rate.
• Uncertainty equals obar(1 - obar) computed directly, and reliability is zero on a synthetic input where observed is set equal to predicted in every bin.
• The residual shrinks as the bin count rises from 5 to 20; if it does not, the label or the binning is wrong.
• Multiplying every PD by 1.5 must raise reliability and ECE while leaving resolution, uncertainty and AUC unchanged, since equal-count bins are invariant to a monotone transform.

Follow-ups

• AUC is unchanged after a population shift but the reliability curve has moved. What happened, and what do you do about it?
• How would you recalibrate without retraining, and what would you check afterwards?
• The top decile shows observed default well above predicted. Is that a calibration problem or a policy problem?

Define an active customer for a card portfolio

Leadership wants one weekly number for how many customers are active. You have fct_payment_authorization (auth_id, customer_id, auth_result, captured_at, amount_minor, is_reversal, channel) and dim_customer (customer_id, is_current, kyc_status, onboarded_at, closed_at). Write the metric definition you would publish: numerator, denominator, window, and every exclusion with its reason. Then name two ways the definition gives a wrong read, one that inflates it and one that deflates it, and say what you would report alongside it.

How a strong candidate works it

• Fix the grain before writing anything. The number counts distinct customers, so the authorization table has to be reduced to one row per customer_id first; a customer with forty approvals counts once.
• Build the numerator from money that actually moved: auth_result = 'approved' AND captured_at IS NOT NULL, excluding is_reversal = true and zero-amount verification authorizations. An approval that is never captured, or is reversed, has no economic content behind it.
• Build the denominator from the population that could have transacted: dim_customer with is_current = true, kyc_status = 'verified', onboarded_at on or before the window start, and closed_at null or after the window start. Joining without is_current fans the type 2 history out and multiplies the denominator by the number of attribute versions.
• State the window and its recompute cadence, trailing 30 days recomputed daily, and say plainly that this series is not comparable to a calendar-month version of the same definition.
• Name the inflation path (recurring and subscription-only customers, and wallet top-ups, count as active with no user intent behind them) and the deflation path (a customer onboarded inside the window had less than 30 days of opportunity, and activity on products outside this table is invisible).
• Pair it with a depth metric such as settled volume per active customer, so breadth cannot be reported on its own and an acquisition push cannot pass as engagement.

Expected result (20 min): An eight-line definition: distinct customer_id with an approved, captured, non-reversed, non-zero-amount authorization in the trailing 30 days, over is_current, KYC-verified, open customers onboarded on or before the window start; accompanied by an exclusion log giving the customer count removed by each exclusion.

Check yourself

• The numerator count never exceeds the denominator count. If it does, the numerator contains customers who are absent from dim_customer or whose only row is not the current version.
• Total dim_customer rows divided by distinct customer_id is greater than one, which is the fan-out the is_current filter prevents.
• Dropping the captured_at filter raises the numerator, and the increase concentrates in specific channels such as holds and verifications rather than spreading evenly. An even spread means the filter is removing the wrong rows.

Follow-ups

• A product team proposes counting any successful login as activity. What breaks?
• The number jumps four percent overnight with no product change. What do you check first?
• How would you report customers onboarded inside the window, given they had a shorter opportunity to transact?

Fraud losses appear to halve in recent transaction months

A weekly chart attributes fct_card_dispute cases to the requested_at month of the linked fct_payment_authorization row. The two most recent months show the first-chargeback rate falling by half, and a risk rule shipped six weeks ago. Columns: dispute_id, auth_id, dispute_category, dispute_stage, opened_at, disputed_amount_minor, liability_shift_flag, outcome, net_loss_minor, resolved_at. Decide whether the rule worked, and produce the version of the chart you would sign your name to.

How a strong candidate works it

• Separate the two dates explicitly. opened_at is when a case was filed, requested_at is when the transaction happened. Attributing by transaction month is the right causal choice and is exactly what makes the newest months structurally incomplete.
• Measure the filing lag rather than assuming it: the distribution of opened_at minus requested_at over fully developed months, split by dispute_category, and the age at which around 95 percent of cases have arrived.
• Build a development triangle of transaction month by months of development on cumulative case counts, and estimate age-to-age factors from the columns that are complete.
• Develop the immature months with those factors and plot the result as an estimate with a visible band, kept visually distinct from the matured series rather than blended into it.
• State the assumption the method needs: a stable development pattern across cohorts. A change in filing behaviour, merchant mix or the dispute team's own backlog breaks it, so inspect factor stability down each column before relying on the estimate.
• Only then evaluate the rule, comparing pre-change and post-change cohorts at equal development age.

Follow-ups

• What leading indicator would you accept while the cohort matures, and what is its known bias?
• How does liability_shift_flag change which disputes you should expect to see in the first place?
• If the rule also blocked good transactions, where does that cost appear, and is any of it in this chart?

Defend a vintage finding that contradicts the portfolio dashboard

The lending dashboard shows blended 90-plus days-past-due falling for four consecutive quarters while originations grew 60 percent. Using fct_loan_performance_monthly, you build a vintage view keyed on origination_month by months_on_book and find the three most recent vintages are worse than their predecessors at the same age. The business lead presents that dashboard weekly and pushes back hard, suggesting you picked favourable cohorts. You get one meeting and the vintage table. Present the finding so it survives the cherry-picking objection and ends in a decision.

How a strong candidate works it

• Reconcile before you contradict: show that aggregating your vintage table along the calendar diagonal reproduces the published blended series, so the disagreement is about age mix rather than about data quality.
• Make the mechanism arithmetic rather than rhetorical: a loan cannot reach 90 days past due before it is 90 days old, so rapid origination growth shifts weight onto young months-on-book where the rate is structurally near zero.
• Show every vintage rather than a selected pair, all indexed at months_on_book equal to 12, with cohort sizes printed beside each curve so nobody can claim the divergence rests on a thin cohort.
• Handle restructuring explicitly, because restructured_flag resets days_past_due: count each loan on its worst pre-restructure state, or recent vintages will look better than they are.
• Close on the decision rather than the chart: state what the divergence implies for the cutoff or the channel mix, and state in advance what evidence would make you withdraw the claim.

Follow-ups

• Two cohorts differ at month 12. How do you separate a seasoning effect from a genuine credit-quality effect?
• Someone argues the recent vintages are simply a broker-channel mix shift. How do you test that, and what would confirm it?

Retract a published number after finding a currency bug

Two weeks ago you published an interchange and fraud analysis that summed amount_minor across fct_payment_authorization without converting currencies. Minor units are not two decimals everywhere: some currencies carry none and some carry three, so the sum has no interpretation. A pricing decision is already in flight on the back of it. You now have corrected figures. Produce the retraction: what you send, to whom, in what order, and what you change in the process so this class of error is caught next time rather than trusted next time.

How a strong candidate works it

• Size the error before announcing it, because saying the number is wrong without a magnitude and a direction forces every reader to assume the worst case.
• Check whether the conclusion actually flips: if the ranking that drove the pricing decision is unchanged, that belongs in the first sentence beside the correction rather than buried at the end.
• Tell the person acting on it first and directly, then the wider distribution, using the same text, so nobody learns about it secondhand.
• Write the correction as four parts: the old number, the cause in one clause, the effect on the pending decision, and the new number. Leave out self-flagellation, which makes the reader do emotional work instead of acting.
• Fix the class rather than the instance: a rule that a sum over amount_minor either groups by transaction_currency or passes through both conversion steps, exponent scaling and then a dated rate into one named reporting currency, plus a standing reconciliation of the settled subset to the settlement ledger inside each settlement_currency.

Follow-ups

• The corrected figures do not change the decision. Do you still send the correction, and what does that choice signal?
• What automated check would have caught this, where would it live, and what would it cost in false alarms?

Where candidates lose points

Recalibrating an underwriting cutoff on approved and funded applicants only

Rejected applicants have no repayment outcome, and they were rejected because the incumbent model scored them badly, so the missingness depends directly on the outcome being modelled. Reject inference by augmentation or parcelling fills the gap using the incumbent model's own assumptions, which means it can confirm those assumptions but cannot test them. The only genuinely new information about the reject region comes from bureau performance on rejects who borrowed elsewhere, or from a deliberately randomised approval band around the cutoff.

Assuming a model is fair because protected attributes are not among its inputs

Postcode, device, tenure, income proxies and even transaction patterns correlate with protected characteristics, so a model can produce a disparate outcome without ever reading the attribute. Credit decisions additionally carry an explainability obligation in many jurisdictions, since a denial has to be accompanied by its principal reasons, which constrains model form and feature engineering rather than being a reporting afterthought. Treating fairness testing and reason-code generation as design constraints from the first model version is far cheaper than retrofitting them to a deployed one.

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.

Analysing at a different unit than the one randomised

Say out loud what was randomised (user, device, account, cluster) and make the analysis unit match, or account for the clustering with cluster-robust standard errors, the delta method, or aggregation up to the randomised unit. Randomising users and then running a test over sessions understates variance and inflates the false-positive rate.

Product sense first, for an engineer moving into data science

For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.

Day 1 — Metric anatomy

• For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
• For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
• Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.

Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.

Day 2 — Diagnosing a drop without guessing

• Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
• List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
• Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.

Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.

Day 3 — Should we build it

• Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
• Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
• Write the counter-metric that would make you kill the feature even if it wins on the primary metric.

Deliverable: A one-page product memo ending in a decision rather than a list of considerations.

Day 4 — The places aggregate numbers lie

• Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
• Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
• Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.

Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.

Day 5 — Technical maintenance, aimed at metrics

• Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
• Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
• Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.

Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.

Day 6 — Turning engineering work into data science stories

• Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
• For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
• Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.

Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.

Day 7 — Mock case and gap list

• Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
• Listen back and mark every moment you proposed a solution before the success metric existed.
• Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.

Deliverable: A recorded case plus a rewritten opening 90 seconds.