As a Data Scientist at QuantumBlack, you are at the intersection of advanced analytics, engineering, and strategic consulting. You do not just build models; you solve complex, high-stakes business problems for some of the world’s most influential organizations. Your work directly informs the decision-making processes of executive leadership, transforming raw, often messy, real-world data into actionable insights that drive significant operational change.
The role requires a rare blend of technical rigor and business acumen. You will collaborate with cross-functional teams, including Data Engineers, Machine Learning Engineers, and Consultants, to design, build, and deploy custom analytical solutions. Whether you are optimizing supply chains, predicting consumer behavior, or developing bespoke algorithms for unique industry challenges, your contributions are expected to be both scientifically robust and commercially relevant.
You will operate in an environment that prizes intellectual curiosity and structured problem-solving. Success at QuantumBlack requires you to remain comfortable with ambiguity, as you will often be tasked with defining the scope of a problem before you even begin to model a solution. If you are driven by the desire to see your technical work manifest in tangible business outcomes, this role offers an unparalleled platform.
Preparation focus
editorialNo round sequence has been reported for this company, so work the categories below and confirm the format with your recruiter.
What to demonstrate
- Breadth across SQL, experimentation and product reasoning
- Ability to state assumptions before choosing a method
How to prepare
- Drill the practice exercises below and time yourself
- Prepare three quantified stories about decisions you drove
PracHub editorial advice for the preparation topics above.
Computing a t-statistic on daily observations of an h-day forward return as if the observations were independent.
Sampling an h-day forward return every day means consecutive observations share h-1 days of the same return, which induces strong positive autocorrelation. The naive standard error is too small by a factor on the order of sqrt(h), so a 5-day-horizon signal with a genuine t of 1.3 can present as 2.9. Either use non-overlapping samples, which costs power, or use a Newey-West or Hansen-Hodrick covariance with at least h-1 lags, and state which one was used.
Modelling transaction cost as a constant number of basis points, independent of order size and volatility.
Temporary market impact scales approximately with volatility times the square root of participation, that is, of order quantity divided by average daily volume, so cost per share rises as size rises rather than staying flat. A constant-bps assumption is roughly right for the small orders used to calibrate it and badly wrong for the size the strategy would actually run, which is how a book that backtests well at modest notional loses money at ten times the size. It also makes capacity unmeasurable, because capacity is exactly the notional at which marginal impact equals marginal alpha.
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.
Defining the cohort on a post-treatment condition
Ask how rows entered the table. Filtering on something that treatment itself influences, such as users who finished onboarding or accounts still active at ninety days, breaks comparability between arms; define the population at an entry point that precedes exposure and keep everyone in it.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you handle multicollinearity in a linear regression model?
How do you handle multicollinearity in a linear regression model?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
Can you explain the bias-variance tradeoff and how it impacts model se…
Can you explain the bias-variance tradeoff and how it impacts model selection?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
- 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?
Can you explain how a random forest handles overfitting compared to a …
Can you explain how a random forest handles overfitting compared to a single decision tree?
Approach
- Check what information would not exist at prediction time, and exclude it.
- 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.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
Permutation test for mean IC with overlapping forward returns
panel has as_of_date, instrument_id, zscore_xs and fwd_ret_5d_excess, the five-trading-day forward return in excess of the universe's cap-weighted mean, for 252 dates and roughly 1,500 instruments a date. Compute the daily Spearman rank IC and its mean. Then build a permutation null from scratch and report a two-sided p-value. Compare it with a naive t-test on the 252 daily ICs and with a Newey-West t using four lags. State which null hypothesis your permutation scheme actually tests.
Approach
- Compute the daily IC by ranking both columns within as_of_date with method='average' and taking the Pearson correlation of the rank vectors. Decide explicitly how to treat dates where the universe shrinks, because an unweighted mean gives a 40-name date the same weight as a 1,500-name date.
- The obvious permutation shuffles zscore_xs within each as_of_date. That is the right exchangeability for the null 'the signal carries no cross-sectional ordering on any given day', and it preserves the daily sample size and the cross-sectional return structure, factor effects included.
- But it makes the permuted daily ICs independent across dates, and the real ones are not. A five-day forward return sampled every day shares four days with its neighbour, and the signal itself is persistent, so the observed IC series is strongly autocorrelated. Under an i.i.d. daily return null the variance of the mean of overlapping h-period observations inflates by a factor of h, so the within-day null is too narrow by about sqrt(5) and its p-value is anti-conservative.
- Fix it by permuting at the date level: circularly shift the whole signal panel's as_of_date labels by a random offset, keeping each day's cross-section and the signal's serial persistence intact while breaking its alignment with the returns. The 252 distinct shifts give an exact randomization test with a p-value floor of 1/252.
- Report all three numbers. The naive t and the Newey-West t with 4 lags (h-1 for h = 5) should differ by a factor near sqrt(5), and the shift-permutation p should agree with the Newey-West figure rather than the naive one. If it does not, one of the two is implemented wrongly and you have a cheap way to find out which.
Worked solution 45 min
- ranks = panel.groupby('as_of_date')[['zscore_xs','fwd_ret_5d_excess']].rank(method='average'); daily IC is the per-date Pearson correlation of the two rank columns.
- Within-day scheme: one rng.permutation of the signal rank vector inside each date, 10,000 replications of the mean IC.
- Shift scheme: remap as_of_date through a circular offset over the sorted unique dates, re-join to the returns on (shifted_date, instrument_id), and record how much of the panel drops because an instrument is absent on the shifted date, since a large loss biases the null.
- naive_t = mean(IC)/(std(IC, ddof=1)/sqrt(252)); Newey-West t with a Bartlett kernel and 4 lags.
- Put the three p-values, the two t-statistics, the replication count and the p-value floor in one table.
Follow-up
- With 252 circular shifts and the observed statistic the largest among them, what is the smallest p-value you can report, and is it small enough for the decision being made?
- How would you redo this on non-overlapping five-day samples, and how much power do you surrender?
- The signal has a 12-day decay half-life. Does that change your shift block length or your Newey-West lag choice?
Sessionise child fills into execution bursts across venues
execution_fill holds fill_id, order_id, exec_ts TIMESTAMPTZ(6) in UTC, venue_mic, fill_qty, fill_px and liquidity_flag. Within each order_id, a burst is a maximal run of consecutive fills separated by under 90 seconds. Return one row per burst: order_id, burst sequence, first and last exec_ts, fill count, total quantity, quantity-weighted price, and the running share of parent_order.order_qty completed at the burst's end. Attach the exchange-local session date derived from instrument_master.primary_exchange_mic, not the UTC date.
Approach
- Order fills inside each parent and take
LAG(exec_ts) OVER (PARTITION BY order_id ORDER BY exec_ts, fill_id). Thefill_idtie-break is load-bearing: an algo slicing into a venue produces genuine microsecond ties, and without a deterministic second key the burst boundaries move between runs. - Flag a boundary where the lag is NULL or the gap exceeds 90 seconds, then convert flags to a dense burst id with
SUM(is_new_burst) OVER (PARTITION BY order_id ORDER BY exec_ts, fill_id ROWS UNBOUNDED PRECEDING). One pass, no self-join, and it degrades gracefully on a single-fill order. - Aggregate to burst grain with
SUM(fill_qty * fill_px) / SUM(fill_qty), notAVG(fill_px); averaging prices weights a 100-share child the same as a 50,000-share block and misstates the burst by the spread. - Add the completion curve as a second window over the aggregated bursts:
SUM(burst_qty) OVER (PARTITION BY order_id ORDER BY burst_seq ROWS UNBOUNDED PRECEDING) / order_qty. Doing it after aggregation keeps it at the grain you are reporting. - Resolve the session date through a MIC-to-IANA-zone lookup and
(exec_ts AT TIME ZONE zone)::date. The UTC date happens to coincide with the local session date for US cash equities and most Asian cash sessions, but an Australian morning sits on the previous UTC day, and a futures trade date that rolls at 17:00 US Central does not align with either.
Follow-up
- Two venues report the same execution microsecond with different
received_ts. Which timestamp do you sort by for sessionisation, and which for latency analysis? - Derive the 90-second threshold from the data instead of asserting it. What distribution would you look at, and what would tell you the threshold is wrong?
- How does the burst structure change under a POV algo versus a close-auction order, and what would you expect the completion curve to look like in each?
Order fill funnel by execution algorithm, in counts and notional
From parent_order (order_id, algo_name, order_qty, filled_qty, status, arrival_ts, arrival_mid_px), build a monthly funnel per algo_name over orders whose arrival_ts falls in the month: orders released, orders with any fill (filled_qty > 0), orders fully filled (status = 'filled'), and the two step conversion rates. Produce the same funnel in notional, using order_qty * arrival_mid_px. Orders with status = 'rejected' never reached the market — state how you treat them and implement that choice.
Approach
- Use conditional aggregation in a single pass —
COUNT(*) FILTER (WHERE filled_qty > 0)and friends — rather than three subqueries joined together, so every numerator and denominator provably comes from the same row set. - Make the denominator decision explicit: rejects are an order-management outcome, not an execution outcome, so exclude them from both numerator and denominator and report their count in a separate column. An exclusion you cannot see in the output is an exclusion nobody can audit.
- Cast before dividing. With integer counts,
filled / releasedfloors to 0 in Postgres;filled::numeric / NULLIF(released, 0)gives the rate and also handles an algo with zero orders in the month. - Compute the notional funnel with the same FILTER clauses over
SUM(order_qty * arrival_mid_px). Divergence between the count funnel and the notional funnel is the finding: 60 percent of orders completing but 20 percent of notional means the large orders are the ones stalling. - Group by
date_trunc('month', arrival_ts)andalgo_name, and left-join a distinct algo list if months with zero activity must still appear as rows.
Worked solution 20 min
- Write one aggregate query over the month with FILTER clauses for released, any-fill and fully-filled, plus a rejected count.
- Wrap it and compute the two conversion rates with explicit numeric casts and NULLIF guards.
- Duplicate the three FILTER clauses over
SUM(order_qty * arrival_mid_px)to get the notional funnel. - Reconcile: released + rejected must equal the raw count of orders with
arrival_tsin the month. - Scan for algos where the count rate and notional rate differ by more than 10 points and note them for follow-up.
Follow-up
filled_qtysits on the parent but the fills live inexecution_fill. How would you find parents whosefilled_qtydisagrees with the sum of their non-correction fills, and which side would you trust?- The fully-filled rate rises after
participation_rate_targetis lowered. Is that an improvement, and what second metric settles it?
We have a client with declining customer retention; how would you appr…
We have a client with declining customer retention; how would you approach this problem from a data perspective?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- 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.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
What is the difference between bagging and boosting, and when would yo…
What is the difference between bagging and boosting, and when would you prefer one over the other?
Approach
- Clarify what is being asked and what a complete answer would contain.
- State your assumptions explicitly before working the problem.
- 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?
Describe the mathematical intuition behind the kernel trick in SVMs.
Describe the mathematical intuition behind the kernel trick in SVMs.
Approach
- Work from the decision backwards to the evidence you would need.
- Say what you would check first and why it is the highest-information step.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Cut short-side financing cost without cutting the short alpha
Management wants short-side financing cost down. From position_daily you have financing_cost_base_day, borrow_rate_bps, borrow_status ('general_collateral', 'hard_to_borrow', 'unavailable', 'n_a'), quantity and market_value_base per instrument per business_date; from signal_score you have decile_rank per as_of_date. Design the metric set for this project: a primary, a guardrail, and the decision rule when they disagree. The complication is that the most negative decile is disproportionately hard to borrow, so the cheapest achievable borrow book is the one that has stopped taking the trade the strategy exists to take.
Approach
- Refuse total financing_cost_base_day as the primary: it is minimised perfectly by closing the short book. Denominate it instead as short-notional-weighted borrow_rate_bps, so the metric measures the price paid per unit of short exposure rather than the quantity of exposure taken.
- Benchmark that rate against a broad market borrow rate. A firm-wide easing of lending supply lowers the weighted rate without anyone doing anything, and a project that books that as a win will also book the reverse as a failure.
- Set the guardrail on the quantity the primary can be improved by destroying: the short book's notional-weighted mean decile_rank, joined on instrument_id and business_date equal to as_of_date. If the rate falls while that mean drifts up toward the universe midpoint, the saving came from abandoning the trade.
- Convert the conflict into one comparison rather than two metrics fighting. Hold a short only where expected annualized alpha exceeds borrow_rate_bps plus impact amortised over the expected holding period. That rule keeps expensive bottom-decile names whose alpha covers the borrow and drops mid-decile names whose alpha does not, which is the opposite of what a raw cost target produces.
- Separate in reporting the wins that do not touch the book: rate shopping across lenders for the same instrument on the same day, early warning from borrow_status transitions into hard_to_borrow, and term borrow for names held long enough to justify it. Without that split the project will claim credit for alpha it destroyed.
Worked solution 30 min
- From position_daily where quantity is negative, compute daily short-notional-weighted borrow_rate_bps, split by borrow_status, and aggregate monthly.
- Difference that series against a broad market borrow-rate proxy so supply-side moves are not scored as project outcomes.
- Join to signal_score on instrument_id and business_date equal to as_of_date, and compute the short book's notional-weighted mean decile_rank by month.
- Estimate expected alpha per decile from the trailing IC and the realized cross-sectional return spread, then compare decile 1 alpha net of its borrow cost against decile 3 alpha net of its borrow cost.
- Write the net-of-borrow inclusion rule and replay the last 12 months to list exactly which positions it would have removed.
Follow-up
- The weighted borrow rate falls 40 basis points and mean short-book decile_rank is unchanged. Name two explanations other than good work by this project.
- How do you price a name whose borrow_status is 'unavailable' rather than merely expensive, given it never appears in the cost series at all?
- A recall forces a buy-in on a bottom-decile short. Where does that cost land in your metric set, and should it?
Return dispersion widened inside one strategy composite
Trailing-12-month net returns for accounts running one strategy used to sit within about 40 bps of each other. This quarter the cross-sectional standard deviation is 210 bps and the AUM-weighted mandate success rate fell. The investment team insists the model is identical across accounts. You have position_daily (business_date, account_id, strategy_id, instrument_id, market_value_base, weight_pct_nav, is_restricted, fx_rate_to_base) and account_mandate (account_id, funded_date, inception_date, status, target_gross_exposure_pct, max_single_name_weight_pct, base_currency, mgmt_fee_bps, effective_from, effective_to). Explain the dispersion with an ordered checklist and say which part is a problem.
Approach
- Rank accounts by trailing-12-month net return and inspect the tail before averaging anything. A standard deviation is a distribution statistic and two accounts out of forty can produce it; the number alone does not say whether the cause is systemic or concentrated.
- Cut by months since funded_date and by status. An account in 'ramping' holds cash and sits below target_gross_exposure_pct, so it earns a diluted version of the strategy's return. In a rising market that reads as underperformance and in a falling one as outperformance, and both are mechanical rather than informative.
- Compute realized gross exposure per account-day from position_daily, as the sum of absolute market_value_base over NAV, and compare it with target_gross_exposure_pct from the account_mandate version valid on that business_date. Join on the effective_from and effective_to range, not on the current row, because mandate terms change mid-life and the current row would apply today's target to last year's book.
- Sort the remaining explanations into expected and not expected. Names excluded by is_restricted, base_currency differences moving through fx_rate_to_base, and mgmt_fee_bps differences on a net-of-fee metric are all expected. A weight breaching max_single_name_weight_pct, or an account holding instruments the others do not, is not.
- Report dispersion decomposed by cause with dollars attached. The client question is never why sigma is 210 bps; it is why this account returned less than the one on the last page.
Follow-up
- Two accounts funded the same day diverge by 90 bps and both reached target exposure inside 20 trading days. Where do you look next?
- The AUM-weighted success rate only counts accounts with 36 months of history. How does that interact with what you just found, and does it flatter the number or penalise it?
- How would you present cash drag to a client so it reads as a fact about funding rather than an excuse?
Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and set a baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
- Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
- Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.
Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Worked solution ↗02One query pattern, written three times
- Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
- On the third attempt, write the grain of every CTE as a comment before writing its body.
- Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.
Deliverable: Three independent versions of the same query plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗03Only the statistics you will be asked to defend
- Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
- Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
- Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.
Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.
Practice prompt ↗Practice prompt ↗04One case, and the assumptions holding it up
- Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
- Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
- Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.
Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
- Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in a longer weekend block
- Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗Practice prompt ↗07Taper
- Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
- Re-read only your own notes from this week, and open no new material.
- Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
A number you shipped turned out to be wrong, and someone had already acted on it. That is one of the most useful stories a data person can carry. What is being scored is how fast you noticed, who you told first, and what you changed in the process so the same class of error could not repeat quietly.
Writing an impact statement that survives a hostile reading
Write your own annual impact statement. Your work: a market-impact recalibration the desk adopted in March; a signal you researched that a portfolio manager sized and traded; and a rewrite of the nightly position reconciliation that reduced unreconciled rows in position_daily. Realized implementation shortfall fell from 21 bps to 14 bps after March. Market volatility also fell over the same period. State what you added, in basis points where the attribution supports it, and be explicit about where it does not.
Approach
- What is probed: whether you can separate correlation from contribution when the correlation favours you, which is the one place almost everyone's standards slip.
- Build a counterfactual for the shortfall claim instead of a before-and-after. Shortfall scales with volatility, so a pre and post comparison across a regime change partly measures the market. Use orders that kept the old routing or the old parameters as a control over the same window, matched on participation bucket (order_qty over adv_20d) and side, and report the difference-in-differences rather than the raw 7 bps.
- State the part you cannot claim before anyone asks. The signal was sized by the portfolio manager, so its P and L is a joint product. Claim the research decision itself: what you tested, what you rejected, the number of configurations tried, and the standard error you attached. Volunteering the boundary is what makes the claims inside it credible.
- Give the reconciliation work a number that is not basis points. Report unreconciled and break rows in position_daily before and after, plus the downstream consequence: marks that fell back to stale_prior_day, and client reports restated. Inventing a basis-point figure for operational work costs you the basis-point figures that are real.
- Write a falsifier next to each claim, naming the evidence that would show you added nothing. A reviewer who watches you name your own weakest claim stops auditing the strong ones.
Follow-up
- Your control group is 8 percent of order flow. Is the difference-in-differences credible at that size, and what would you need to make it so?
- The signal lost money this year. Does it appear in the statement, and in what form?
- What did you get wrong this year, and what did it cost?
Scoping is our execution any good into one answerable question
A chief operating officer stops you in the hallway and asks whether our execution is any good. You have parent_order and execution_fill for eighteen months, roughly 400,000 parent orders across four algos and six brokers. Nobody has defined good, no deadline is set, and two people have already produced conflicting answers. Before writing any SQL, produce a one-page scoping memo: the single question you will answer, the metric defined at field level, the slices, the exclusions, and what you are explicitly not answering.
Approach
- What is probed: whether you convert a request into a decision. The deliverable of scoping is not a work plan, it is the sentence describing what the requester will be able to decide once you are done.
- Choose the benchmark explicitly and state what each one charges. Arrival mid charges spread, impact and the price drift between the desk receiving the order and completing it, including the unfilled remainder. Interval VWAP charges almost none of that and is partly determined by the trader's own volume participation. Answer against arrival and report interval VWAP alongside so nobody believes you hid the flattering number.
- Write the metric to the field level so two analysts cannot compute it differently: side_sign times (avg_fill_px minus arrival_mid_px) times filled_qty, plus commission_amt plus exchange_fee_amt minus rebate_amt, plus opportunity cost on order_qty minus filled_qty at the terminal mid, divided by order_qty times arrival_mid_px, times 10000, aggregated by weighting each order by order_qty times arrival_mid_px.
- Fix the slices in advance, because choosing them after seeing results is how a scoping memo becomes a fishing expedition: algo_name, broker_code, side, and a participation bucket defined as order_qty divided by adv_20d. Set a minimum cell size so a 12 bps difference on 40 orders never reaches a slide.
- State the exclusions and the known data problems in the same memo: corrections net against corrects_fill_id rather than being counted twice, orders with a null arrival_mid_px are reported as a coverage percentage rather than dropped quietly, and clock skew between exec_ts and received_ts is a data-quality item and not an execution-quality finding.
- Close with the questions you are not answering, each with a rough cost: whether the strategy should trade less, whether broker relationships are priced correctly, and whether the algos' internal logic is sound.
Follow-up
- The COO says 12 bps sounds fine. What do you compare it against, and where does that comparison come from?
- The two existing answers disagree. How do you determine whether they used different benchmarks or different populations?
- What changes if this has to become a monthly production number rather than a one-off study?
Disagreeing with a product manager over an account leaderboard
A product manager wants to ship a client portal widget ranking every separately managed account against its peers in the same strategy composite, by trailing 12-month net return. You believe the ranking will mostly order accounts by mandate mechanics rather than by anything a client can act on. You have position_daily, account_mandate (SCD2) and benchmark returns for 140 accounts in the composite. Build the case and bring a counter-proposal you would ship. The product manager has a launch date and a client asking for exactly this.
Approach
- What is probed: whether you can lose the feature and keep the working relationship, meaning your disagreement arrives with a shippable alternative rather than as a veto.
- Measure the dispersion before arguing about it. Compute the cross-sectional standard deviation of trailing 12-month net return across the 140 accounts. If it is small, the product manager is right and you are not, and you want to know that before the meeting rather than during it.
- Decompose the dispersion into causes you can name from the tables: time spent ramping between funded_date and the date gross exposure reached 90 percent of target_gross_exposure_pct, average cash weight over the period, restricted names via position_daily.is_restricted, single-name cap differences across account_mandate SCD2 versions, and fee schedule including whether a performance fee crystallised above the high-water mark. Report the share each explains and the residual.
- Convert the finding into the client's decision, because that is what moves a product manager. If most dispersion is mandate mechanics, the leaderboard tells a client to change managers when the honest action is to relax a constraint or fund fully. A wrong action is an argument; a noisy statistic is a preference.
- Bring the alternative that keeps the launch date: the same widget, showing the account's return against its own benchmark and its own constraint set, with a named driver line such as your restricted list cost 34 bps, instead of a rank. It answers what the client actually asked and it survives a phone call.
- Pre-commit to being wrong. If the residual dominates the decomposition, the leaderboard is measuring something real, and saying so in the same memo is what makes the rest of it credible next time.
Follow-up
- Dispersion is 180 bps and mandate mechanics explain 40 percent of it. What do you ship?
- The client asked for a rank by name. Do they get one, and what do you put next to it?
- How do you keep this from becoming a standing veto on anything this product manager proposes?
- 01
Write your own annual impact statement. Your work: a market-impact recalibration the desk adopted in March; a signal you researched that a portfolio manager sized and traded; and a rewrite of the nightly position reconciliation that reduced unreconciled rows in position_daily. Realized implementation shortfall fell from 21 bps to 14 bps after March. Market volatility also fell over the same period. State what you added, in basis points where the attribution supports it, and be explicit about where it does not.
- 02
A chief operating officer stops you in the hallway and asks whether our execution is any good. You have parent_order and execution_fill for eighteen months, roughly 400,000 parent orders across four algos and six brokers. Nobody has defined good, no deadline is set, and two people have already produced conflicting answers. Before writing any SQL, produce a one-page scoping memo: the single question you will answer, the metric defined at field level, the slices, the exclusions, and what you are explicitly not answering.
- 03
A product manager wants to ship a client portal widget ranking every separately managed account against its peers in the same strategy composite, by trailing 12-month net return. You believe the ranking will mostly order accounts by mandate mechanics rather than by anything a client can act on. You have position_daily, account_mandate (SCD2) and benchmark returns for 140 accounts in the composite. Build the case and bring a counter-proposal you would ship. The product manager has a launch date and a client asking for exactly this.
Is this an official QuantumBlack interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at QuantumBlack. Rounds and questions reflect what candidates have reported, not a process QuantumBlack has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How much time should I spend preparing?
Given the rigor of the process, 4–8 weeks of structured preparation is recommended. Focus on bridging the gap between theoretical knowledge and your ability to explain it clearly in a high-pressure environment.
PracHub interview research ↗What is the biggest differentiator for successful candidates?
Successful candidates bridge the gap between "being a coder" and "being a problem solver." They don't just know how to run a model; they know how to choose the right model for the business problem at hand.
PracHub interview research ↗Does QuantumBlack focus on coding or theory?
It is a balanced blend. The initial stages are heavy on coding and technical theory, while the later stages shift almost entirely to case studies and your ability to apply that theory to real-world business scenarios.
PracHub interview research ↗What is the culture like?
It is intellectual, collaborative, and fast-paced. You are expected to be humble enough to learn from others and confident enough to defend your technical decisions.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Worldquant Data Scientist Interview Questions & Guide 2026
Product-sense practice for a Worldquant data scientist interview: define a quantitative trading metric, pick its guardrails, and argue why a tempting alternative would mislead you.
Wolverine Trading Data Scientist Interview Questions & Guide 2026
A prep plan for Wolverine Trading data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three days lat
The Carlyle Group Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at The Carlyle Group with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.
The Blackstone Group Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at The Blackstone Group candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.