Interview guides · Quantium

Quantium Data Scientist Interview Questions & Guide 2026

Quantium data scientist prep: probability, sampling distributions, and stating the assumption behind every test you run.

The 60-second brief

As a Data Scientist at Quantium, you play a pivotal role in harnessing the power of data to drive strategic decisions and innovations that shape the future of the organization. Your work is vital in analyzing complex datasets, developing predictive models, and translating findings into actionable insights that not only enhance the company's product offerings but also significantly impact business outcomes. You will be part of a collaborative team dedicated to solving real-world problems using advanced analytics and machine learning techniques.

A large share of questions open as "how would you measure X", where the real work is choosing the metric, fixing its denominator, and defining the population it applies to. Any computation comes last and is frequently not required at all.

Focus areas

Size positions by risk contribution, not conviction
Attach uncertainty to every Sharpe claim
Separate forecast decay from execution cost

Overview

In this role, you will engage with various sectors and stakeholders, contributing to projects that span from operational improvements to strategic initiatives. Your analytical skills will help guide the development of data-driven solutions that align with Quantium's mission of delivering tangible business value. Expect to work on exciting challenges that involve large datasets, complex algorithms, and innovative methodologies, all while playing a crucial part in advancing the company's data-driven culture.

The Quantium interview process

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

Phone Screen

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

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

Team Interviews

An extra round usually exists because something is still open after the standard loop: a skill the earlier interviews did not sample, a level decision, or two interviewers who disagreed. It is rarely a rerun of what you already did well. Ask the recruiter who you are meeting, what function they sit in, and how long the session runs. That is an ordinary scheduling question, and the answer changes what you should prepare. What separates a strong candidate here is treating the round as a fresh evaluation with its own bar, rather than assuming earlier performance carries you through or sinks you.

What to demonstrate

Whether you can answer well on ground the earlier rounds did not cover, without leaning on what you already said to someone else
Consistency of the facts in your stories: the same sample size, timeframe, team size and scope of your own role as in earlier conversations
How you handle an unfamiliar format live, including whether you ask what kind of answer is wanted before producing one

How to prepare

Ask the recruiter for the interviewer's function, the length, and whether to expect a coding surface, a discussion, or a presentation. Preparing for a 30 minute conversation with a partner team is not the same work as preparing for a 60 minute technical block.
Write out what each earlier round actually covered, then list the two or three areas nobody probed. That gap is the most likely subject of the extra round.
Re-read the numbers in the project stories you have already told, so a second telling does not quietly contradict the first.

Leadership Interviews

Because the format is not fixed, prepare the reasoning rather than the ritual. Nearly every version of this round draws on the same underlying material: a design you can defend, a metric you can define exactly, an analysis whose assumptions you can state out loud. Only the wrapper changes, whether that is a take-home, a live case, a deep dive on past work, or a rough estimate on a whiteboard. Answers rehearsed to fit one shape stall the moment the shape differs. Practise naming the assumption behind a number, then saying how much the conclusion moves if that assumption is wrong.

What to demonstrate

Whether your justification for a method survives the question 'why not the simpler thing', including when the simpler thing would have worked
Precision under pressure: what exactly counts as an active user, a conversion or a success, over what window, with what exclusions
Whether you carry an argument through to a recommendation instead of stopping at a list of tradeoffs

How to prepare

For each project you plan to mention, write the metric definition in one sentence: numerator, denominator, time window, exclusions. Say it out loud once, because vagueness shows up in speech before it shows up on paper.
Rehearse the same project at three lengths: two minutes, ten minutes, and a deep dive on one technical decision. Cutting live is harder than it sounds.
For your headline result, write down what would have had to be true for it to be wrong, and how you ruled that out.

Where candidates lose points

Filtering on as_of_date rather than knowledge_ts, so restated fundamentals, revised index constituents and retroactively applied split and dividend adjustments enter the backtest before they were knowable.

Vendors overwrite history in place. A quarterly figure filed 45 days after period end is stored against period end, an index addition announced five business days before it takes effect is stored against the effective date, and a split applied tonight rewrites every prior close in the adjusted series. Each of those gives the strategy information it could not have had, and the resulting lift is concentrated in the highest-turnover, highest-apparent-alpha names. The signal_score table separates the two timestamps precisely so this filter can be written correctly.

Judging execution quality against interval VWAP and treating a favourable number as proof of good trading.

Interval VWAP is a benchmark the trader partly determines: trading in line with volume tracks VWAP almost by construction, and stretching an order over a longer interval makes the benchmark easier while exposing the position to price drift that the benchmark never charges. Arrival price is the benchmark aligned with the decision, because it charges both the spread and the drift between decision and completion, including the unfilled remainder. Reporting both, and reporting the opportunity cost of unfilled quantity, is what separates a real TCA from a flattering one.

Ending an analysis without a recommendation or next step

Close with what you would do and what would change your mind, stated as a condition you can check later. If the evidence is genuinely inconclusive, recommend the specific next measurement and say what it costs in time or exposure.

Crediting a treatment for regression to the mean

Selecting a group because it is extreme (lowest-engagement users, accounts having their worst month, the bottom decile of a score) moves that group's expected next-period value back toward the average even under no treatment, by exactly as much as the selecting measure is imperfectly correlated with its own later value. Compare against units that met the same selection rule and went untreated, or use two pre-periods so the bounce-back is visible before the intervention starts. A pre-post number on a group chosen for being extreme measures the selection rule, not the treatment.

Questions & practice

Write a function to implement a logistic regression model.

Medium · machine learning and modelling

Approach

Say how the offline result would be validated online before it is trusted.
Pick an evaluation metric that matches the cost of each error type, not a default.
Set a baseline first, so any model has something honest to beat.

Follow-up

What would you monitor after launch to know the model is still valid?
How would you choose the decision threshold, and who owns that choice?

How would you optimize the performance of a machine learning algorithm?

Medium · machine learning and modelling

Approach

Pick an evaluation metric that matches the cost of each error type, not a default.
Say how the offline result would be validated online before it is trusted.
Check what information would not exist at prediction time, and exclude it.

Follow-up

What would you monitor after launch to know the model is still valid?
How would you choose the decision threshold, and who owns that choice?

Annualized information ratio with an honest standard error

Easy · performance · inference · pandas

You are given active, one row per (account_id, business_date) with active_return: the daily arithmetic portfolio-minus-benchmark return, net of all costs, as a decimal. Three accounts, roughly 750 business days each. Rows are absent on exchange holidays and on days before an account's funded_date. Per account, compute the annualized information ratio (mean times 252, divided by standard deviation times sqrt(252)) and an approximate standard error for that ratio, then report a 95% interval. Do not reindex onto a calendar. State what T you used and why.

Approach

Drop null active_return per account rather than filling it. T must be the number of days the account actually traded: holidays and pre-funding days are not evidence, and treating them as such changes both the point estimate and the interval.
Compute the daily mean m and the daily standard deviation s with ddof=1. The annualized IR is (m/s)*sqrt(252), because the 252 in the numerator and the sqrt(252) in the denominator collapse to a single sqrt(252) factor. Say that out loud instead of writing two separate annualizations that can drift apart.
Take the standard error at the frequency the statistic is estimated at: SE(SR_daily) is approximately sqrt((1 + SR_daily^2/2)/T) for i.i.d. normal returns, then scale it by sqrt(252), the same factor as the point estimate. At daily frequency SR_daily^2/2 is of order 1e-3, so the SE is effectively sqrt(252/T) and depends only on elapsed years.
Report IR plus or minus 1.96*SE per account, and check the lag-1 autocorrelation of active_return. The i.i.d. assumption behind that SE is the same assumption that justifies the sqrt(252) scaling, so if the series is autocorrelated both numbers need widening and you should say by how much.

Worked solution (20 min)

groupby('account_id'), dropna on active_return, and record n per account before anything else.
Per account compute m = mean, s = std(ddof=1), ir = m/s*sqrt(252).
sr_d = m/s; se_ann = sqrt((1 + sr_d**2/2)/n)sqrt(252); interval = ir +/- 1.96se_ann.
Compute lag-1 autocorrelation of active_return per account and print it in the same table as the interval.

Expected result: For an account with an annualized IR of 1.0 over 756 trading days the standard error is about 0.58 (sqrt(252/756) = 0.577; the SR^2/2 term moves it by under 0.1%), so the 95% interval runs roughly from -0.13 to 2.13 and the IR is not distinguishable from zero. Three years of daily data cannot establish an IR of 1.

Verify it yourself

sqrt(252/T) must reproduce your standard error to three decimals at daily frequency; a materially different number means you annualized the SE by 252 rather than sqrt(252).
Computing IR as (m252)/(ssqrt(252)) must equal (m/s)*sqrt(252) exactly.
Doubling the sample length should shrink the interval by sqrt(2), not by 2.

Follow-up

The shortest account has 14 months of history. How much of the spread between the best and worst account IR is explainable by sampling noise alone?
One account carries mark_source = 'vendor_eval' on 30% of days. What does that do to the denominator, and to the independence assumption behind the standard error?
How many years of daily data would you need to distinguish an IR of 0.8 from an IR of 1.1 at 95% confidence?

How do you approach debugging your code?

Medium · sql and data manipulation

Approach

Compute rates by summing numerator and denominator separately, never by averaging rates.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Check whether any join is one-to-many before aggregating, or the sums inflate.

Follow-up

What breaks if events arrive late or out of order?
How would you verify this result without re-running the same query?

Provide a code snippet for data manipulation using Python's Pandas library.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Check whether any join is one-to-many before aggregating, or the sums inflate.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

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

Ramp completion cohort by funding month under amended mandates

Hard · cohort-analysis · scd2 · window-functions · retention

From account_mandate (account_id, funded_date, target_gross_exposure_pct, status, effective_from, effective_to) and position_daily (business_date, account_id, strategy_id, weight_pct_nav, market_value_base), compute ramp completion per funding month: the share of accounts funded in month M whose daily gross exposure first reached 90 percent of target_gross_exposure_pct on or before the 20th trading day after funded_date, plus the median trading day to completion. target_gross_exposure_pct can be amended mid-ramp, so use the value in force on each business_date.

Approach

Compute daily gross as SUM(ABS(weight_pct_nav)) grouped by (account_id, business_date), summing across strategy_id. Absolute values are the point: a market-neutral book nets to roughly zero and would otherwise read as an account that never deployed.
Cross-check that gross against SUM(ABS(market_value_base)) divided by the account's NAV. If the two disagree by more than rounding, the weights are stale or the NAV source is wrong, and every downstream rate inherits that error.
Range-join the mandate on business_date >= effective_from AND business_date < COALESCE(effective_to, DATE '9999-12-31'). Joining on account_id alone fans out one position-day per mandate version, which inflates gross and corrupts the session index at the same time.
Index sessions per account with DENSE_RANK() OVER (PARTITION BY account_id ORDER BY business_date) over dates strictly after funded_date, then take MIN(day_idx) FILTER (WHERE gross_pct >= 0.9 * target_gross_exposure_pct). The first crossing is the definition; an account that touched target once and fell back has not completed, and MAX or ANY would score it as if it had.
Aggregate to the funding month: completion rate is completers within 20 sessions over all accounts funded that month, and the median is PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY day_idx) among completers only. Flag months whose 20-session window has not closed as provisional rather than dropping the incomplete accounts, which would bias the rate upward.

Worked solution (45 min)

Aggregate position_daily to (account_id, business_date) gross and record the pre-join row count.
Range-join the SCD2 mandate and assert the post-join row count is unchanged.
Add the session index restricted to dates after funded_date, and compute the first-crossing day per account.
Bucket accounts by date_trunc('month', funded_date) and compute rate plus PERCENTILE_CONT median among completers.
Mark months where funded_date + 20 sessions exceeds the latest business_date in the panel as provisional.

Expected result: One row per funding month with account count, completion rate in [0, 1], median trading day to completion among completers, and a provisional flag on months whose window has not closed.

Verify it yourself

The count of (account_id, business_date) pairs is identical before and after the mandate join.
Every counted completion day index lies between 1 and 20.
The denominator equals a direct COUNT of accounts with funded_date in that month.
An account whose target was amended mid-ramp appears exactly once per business_date in the joined set.

Follow-up

An account funded on the 28th has two sessions of history when this runs. What do you publish for that month, and how does the number change when it is restated?
Completion rate falls while every account still reaches target eventually. Which constraint would you test first — borrow availability, the restricted list, or a participation cap — and what query settles it?
Two accounts funded the same day, same strategy, diverge by 8 sessions. Name three legitimate causes and the column that would evidence each.

How do you prioritize tasks when managing multiple projects?

Medium · product sense and metrics

Approach

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

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?

Provide an example of how you translated complex data findings into actionable business strategies.

Medium · product sense and metrics

Approach

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

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?

Walk us through your process for conducting exploratory data analysis.

Medium · product sense and metrics

Approach

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

Follow-up

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

How would you design an experiment to test the effectiveness of a new product feature?

Medium · a/b testing and experimentation

Approach

Say whether units interfere with each other, and switch design if they do.
Name the randomisation unit first; it decides the variance and what the test can detect.
Decide the analysis before seeing data, including how long it runs and when you look.

Follow-up

What would you conclude if the result is positive but the test is underpowered?
How would you handle interference between treated and control units?

Explain the difference between supervised and unsupervised learning.

Medium

Approach

State your assumptions explicitly before working the problem.
Say what you would check first and why it is the highest-information step.
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?

Ramp new accounts fast or cheap, and defend the exchange rate

Medium · ramp · tradeoffs · impact · guardrails

Newly funded accounts must reach 90 percent of target_gross_exposure_pct within 20 trading days of funded_date; that is today's primary metric. Raising it means ramping faster, which raises implementation shortfall because temporary impact scales roughly with volatility times the square root of participation. You have account_mandate (funded_date, target_gross_exposure_pct, benchmark_id, effective_from, effective_to), position_daily (market_value_base, weight_pct_nav) and parent_order. Pick the primary, pick the guardrail, and state the exchange rate at which you would trade one against the other, in basis points rather than in words.

Approach

Name the objective both metrics are proxying: an unramped day costs expected active return plus unwanted benchmark-relative risk, and a faster ramp costs one-off impact. Both convert to basis points of account NAV, so the conflict is resolvable by arithmetic rather than by argument.
Price the slow side. Daily expected active return is annualized expected alpha over 252, multiplied by the exposure shortfall as a fraction of target. A linear ramp averages a 50 percent shortfall over its window, so at 300 basis points of expected annual alpha a 20-day ramp forgoes roughly 12 basis points. Flag the precondition: this is an expectation with a wide error bar, which makes it the uncertain side of the trade.
Price the fast side correctly, because this is where most answers break. Total ramp notional is fixed, so halving the ramp window doubles participation, raises per-unit impact by about the square root of two, and raises total ramp cost by about 41 percent rather than 100 percent. The window scaling is proportional to one over the square root of the number of days.
Choose the primary as ramp completion and the guardrail as ramp shortfall in basis points of ramped notional with a hard cap, on the stated reasoning that the impact cost is realized and permanent while the forgone alpha is an estimate. Set the cap where marginal impact per day saved exceeds daily expected active return.
Do not paper over the conflict with a blended score. Report both, and if a single number is demanded, define total ramp cost as impact paid plus expected alpha forgone, and attach the alpha assumption to the same line so the reader can see whose estimate is carrying it.

Worked solution (30 min)

From position_daily compute each account's daily gross exposure as the sum of absolute market_value_base over NAV, and find the first business_date reaching 0.9 times target_gross_exposure_pct, joining account_mandate on business_date between effective_from and effective_to.
From parent_order and execution_fill compute arrival shortfall in basis points restricted to orders with decision_ts inside each account's ramp window.
Fit the impact coefficient by regressing shortfall basis points on the square root of filled_qty over adv_20d interacted with trailing realized volatility, and keep the slope.
Project total ramp impact for windows of 10, 15, 20 and 30 trading days from that curve, and project alpha forgone as 0.5 times the daily expected active return times the window length.
Add the two columns and pick the minimum, then state the alpha level at which the ranking flips.

Expected result: One recommended ramp window with both costs shown. Worked at 300 basis points of expected annual alpha and an 8 basis point impact cost at the current 20-day schedule: 20 days costs about 8 plus 11.9, near 19.9 basis points; 15 days about 9.2 plus 8.9, near 18.1; 10 days about 11.3 plus 6.0, near 17.3, so recommend 10 trading days. State that the ranking flips back toward 20 days once expected alpha falls below roughly 120 basis points a year.

Verify it yourself

Projected impact must scale as one over the square root of the window: halving the window should raise it by about 41 percent, not double it.
Alpha forgone must use average exposure shortfall over the window, about 50 percent for a linear ramp, not the day-one shortfall.
The fitted impact curve must reproduce a held-out ramp order's realized shortfall within its residual spread. A curve fitted only on small orders will under-predict the ramp, which is the largest order the account ever sends.

Follow-up

Two accounts funded the same week ramp at different speeds because one carries a restricted list. Should the metric penalise the desk, and how would you separate that in the data?
How does the exchange rate move for a strategy whose expected alpha is 80 basis points a year rather than 300?
The impact curve was fitted on the desk's ordinary daily orders. What is wrong with using it for a ramp, and which direction does the error run?

Turnover doubled in a week with unchanged positions

Medium · definition drift · turnover · data semantics · reconciliation

Annualized one-way turnover for a strategy reads 368 percent this month against 180 percent last month. Position_daily shows end-of-day quantities and market_value_base following their usual pattern, and neither the signal nor portfolio construction was touched. Tables: execution_fill (fill_id, order_id, side, fill_qty, fill_px, is_correction, corrects_fill_id, exec_ts, currency) and position_daily (business_date, account_id, instrument_id, quantity, market_value_base). The catalogue definition is: monthly sum of min(total buy notional, total sell notional), over average end-of-day gross market value, times 12. Find the cause and prove it.

Approach

Split the ratio and chart the numerator and the denominator as separate monthly series before interpreting either. A ratio that moved tells you nothing about which side moved, and the two sides have unrelated failure modes.
Read the magnitude as evidence. A jump close to a factor of two, in a book whose buy and sell notional are nearly balanced, is the signature of min(buy, sell) having become buy plus sell. No strategy change produces a suspiciously round multiple in a week.
Reconstruct the numerator yourself from the catalogue definition and compare it with the reported figure for both months. If your recomputation matches last month and not this month, the expression changed, and the scheduled job's query or its version history says when.
Rule out the competing mechanism before closing. Correction rows arrive as new rows referencing corrects_fill_id, so a naive SUM(fill_qty) counts the correction and never removes the original. Size the corrected notional separately instead of assuming it is small.
Reconcile to the book of record. Day-over-day change in position_daily.quantity per instrument must equal that day's net signed fills, which bounds true traded quantity independently of whichever expression the report used.

Follow-up

Correction rows turn out to be 0.8 percent of notional. Write the numerator expression that handles them correctly in one pass.
Your reconciliation against position_daily leaves a residual on two instruments. Which legitimate causes would you rule out before calling it a data bug?
What would you add to the pipeline so a metric definition cannot change without the change being visible in the report itself?

Suggested practice checklist

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.

Bring numbers, including the ones you are unsure of

An answer without a quantity is hard to interrogate, so interviewers keep probing until they find one. Come with the baseline, the change, the window it was measured over, and how confident you were. If the effect never got measured, say so and say what you would have measured. Fabricated precision is worse than an honest gap.

Can you give an example of a time when you led a project or initiative?

Medium · behavioural and stakeholder questions

Approach

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

Follow-up

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

Defending a backtest correction that removes an allocated strategy

Medium · stakeholder pushback · backtest integrity · lookahead bias

A colleague's cross-sectional equity signal received capital last month on a backtest showing annualized Sharpe 1.6 over three years. Reproducing it, you find the panel filters signal_score on as_of_date rather than knowledge_ts. Rerunning with the knowledge_ts predicate, holding universe_id, date range, cost model and rebalance schedule fixed, gives Sharpe 0.5 and moves mean daily IC from 0.041 to 0.012. The colleague is senior and presented the original result. You have one meeting with the research lead and the portfolio manager. Deliver a recommendation on whether the allocation stands, and the evidence behind it.

Approach

What is probed: whether a quantitative objection survives social cost. Lead with the defect and the single-variable reproduction, never with a judgement about the colleague. The claim under test is one predicate, not a person's competence.
Rerun both versions from one code path with one line changed, and say so explicitly. Holding universe_id, date range, cost model and rebalance schedule fixed leaves the 1.1 Sharpe gap exactly one candidate cause, which is what makes the result arguable on its merits instead of on whose code is trusted.
Pair the comparison before quoting any error bar. For modest Sharpe ratios the annualized standard error of a Sharpe estimate is approximately 1 over the square root of the number of years, so three years of daily data gives roughly 0.58 and two marginal estimates 1.1 apart are only about two standard errors apart. But the two runs are the same returns except where the leak bites, so test the daily difference series directly: its standard error is far smaller, and the pairing is what turns a marginal result into a decisive one.
Exhibit the mechanism, not just the size. Rank instrument-days by their contribution to the return difference between the two runs and show that the top contributors carry is_backfilled TRUE or coverage_flag 'stale', with knowledge_ts postdating as_of_date by the vendor's restatement lag. A named mechanism is falsifiable; a Sharpe delta alone becomes an argument about your code.
Bring a decision rather than only a finding: the position size the corrected Sharpe supports, and an untouched out-of-sample window that would settle it either way. Being right with no path forward is how a correct objection gets overruled.

Follow-up

Your colleague reruns it and gets 0.9 rather than 0.5. What do you do with the discrepancy before the meeting?
The strategy is up since funding. Does live P and L change your recommendation, and how much of it would?
What would have caught this before the allocation, and why did the existing review not catch it?

Explaining why two accounts in one strategy diverged 210 bps

Easy · client communication · attribution · reconciliation

Two separately managed accounts run the identical strategy. Over the trailing twelve months one returned 8.4 percent net and the other 6.3 percent, a gap of 210 bps. The client who owns the lower one has asked in writing why. You have position_daily, account_mandate (SCD2) and the fill history for both accounts. Produce two things: a reconciliation that accounts for the gap down to a residual you state, and a reply of at most 200 words that a non-specialist can act on, without jargon and without blaming the client.

Approach

What is probed: whether you reconcile to the total before you explain anything. An explanation that does not sum to the observed gap is a guess with numbers attached, and the client's next analyst will find the difference.
Reconcile mechanically and in this order, because each step has a clean source: fee difference from mgmt_fee_bps plus any performance fee crystallised above the high-water mark; average cash weight, as one minus the summed weight_pct_nav; restricted names, as is_restricted days multiplied by what those names returned; single-name cap differences across account_mandate SCD2 versions; and the ramp between funded_date and the date gross exposure first reached 90 percent of target.
Carry a residual and state it plainly. If five components explain 170 of 210 bps, the reply says 40 bps unexplained rather than largely explained by. The residual is usually trade timing across the two accounts, and naming it is cheaper than having it discovered.
Order the reply by what the client can do rather than by size of component: what is structural and will persist, such as the fee schedule and their own restricted list; what was one-off and will not repeat, such as the ramp; and what they can change if they choose to.
Remove every term that would need looking up. Your restricted list kept the account out of three names that contributed 62 bps is actionable. Negative selection effect from compliance constraints is not, and the decision to relax a restriction belongs to the client rather than in a recommendation you push.

Follow-up

The residual is 120 bps rather than 40. What goes in the letter, and what do you do before sending it?
The client asks whether their account was deliberately disadvantaged. How do you answer that specific question?
Does the other client need to be told anything, and who decides?