At DRW, a Data Scientist operates at the intersection of quantitative finance, machine learning, and high-performance software engineering. As a technology-driven principal trading firm operating in global liquid markets—spanning equities, fixed income, commodities, foreign exchange, and digital assets—DRW relies on data scientists to extract predictive signals from massive, noisy datasets. Unlike traditional tech companies where data science primarily drives consumer user experience, a Data Scientist at DRW directly impacts proprietary trading strategies, risk management frameworks, execution efficiency, and market microstructure analysis.
The role demands both mathematical rigor and product-level domain context. You will work side-by-side with Quantitative Researchers, Portfolio Managers, and Trading Engineers to formulate hypotheses, design robust experiments, and convert vast raw telemetry into production-grade predictive models. Whether you are building mid-frequency signal pipelines, diagnosing abrupt performance drops in automated execution systems, or establishing rigorous metric tracking across complex trading desks, your work directly informs how capital is deployed in real time.
Succeeding in this role requires a deep understanding of statistical inference, time-series analysis, and signal extraction, combined with the business acumen to design meaningful metrics and experimentation frameworks. DRW cultivates an entrepreneurial, low-bureaucracy environment where decisions are backed by data rather than hierarchy. Candidates who combine strong statistical foundations with sharp product sense and clear communication thrive in this challenging, fast-paced environment.
Online Assessment
reportedA handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.
What to demonstrate
- Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
- Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
- Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.
How to prepare
- Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
- Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
- If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows
Technical Screen
reportedThis 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
Final Rounds
reportedA day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.
What to demonstrate
- Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
- Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
- Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method
How to prepare
- Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
- Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
- Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
- Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times
11 candidate reports. Individual accounts describe a particular role and hiring cycle.
DRW New Grad Quantitative Researcher Interview Experience — Auto-Rejected Before the OA Deadline Even Hit
I cold-applied online to DRW's US New Grad Quantitative Researcher role. Less than a week after applying, I got an online assessment invite. The email said the OA link would expire in seven days, and there was no other deadline notice anywhere. Then, five days later, I got an email saying I hadn't finished the OA in time, and I was flat-out rejected. But the OA link was still valid, so I went ahe…
Read full experienceDRW New Grad Software Engineer Interview Experience — A Greedy String-Parity Coding Problem
I ran into a greedy string problem. Given a string digits made up only of the characters '1' and '2', representing a positive integer, you can delete zero or more characters. After deleting, the requirements are: The remaining '1's must appear an even number of times. The remaining '2's must also appear an even number of times. Subject to those two conditions, the resulting integer should be as l…
Read full experienceDRW New Grad Software Engineer Interview Experience — A Greedy Deletion Problem on a String of 1s and 2s
I got a string greedy problem: Given a string digits made up only of '1' and '2', which represents a positive integer. You can delete 0 or more characters from it, and after the deletion: the number of remaining '1's must be even; the number of remaining '2's must also be even; and, while satisfying those first two conditions, the final integer should be as large as possible. Note that you can on…
Read full experienceDrw Customer Success Engineer interview: Three back-to-back interviews followed by a location rejection
I started with an internal recruiter reaching out about a very senior trade support type of role. My first call was with HR, and it felt like it went well. I then spoke with the hiring manager about my background, the team, and what the role involved. The conversation felt a little unfocused on their side, but it was still decent overall. The role I initially interviewed for didn't work out becau…
Read full experienceDrw Software Engineer interview with a one-hour coding assessment
The process began with an online coding assessment that took me about an hour, even though it was described as a roughly two-hour test. I felt confident after finishing it, but I didn’t hear anything afterward and received a rejection notification a couple of days later. I also interviewed with DRW for a technical role in Singapore, and that process took much longer than I expected. I completed e…
Read full experiencePracHub 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.
Comparing periods without accounting for seasonality or day-of-week
Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.
Dropping rows with missing values without naming the mechanism
Say whether the values are missing at random, missing by a known process, or missing in a way that depends on the outcome, and handle them accordingly. Deleting incomplete rows silently redefines the population whenever missingness correlates with what you are measuring.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Derive Bayes' Theorem from first principles and explain how Bayesian u…
Derive Bayes' Theorem from first principles and explain how Bayesian updates can be applied to sequentially update trading risk parameters.
Approach
- Translate the result into the decision it informs, in one plain sentence.
- Write down the assumption the method needs before you use the method.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
Follow-up
- How would you explain this result to someone who does not know statistics?
- What sample size would you need to detect an effect half this size?
Explain how you would determine the necessary sample size and exposure…
Explain how you would determine the necessary sample size and exposure duration required to achieve adequate statistical power when testing subtle algorithmic modifications.
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?
- Where could label leakage enter this setup?
How large a Sharpe does pure noise produce over many trials
A research team tested 250 strategy variants on the same three years of daily returns (756 observations). The best variant has an annualized Sharpe of 1.4. Under the null that every variant has zero expected return, estimate by simulation the probability that the maximum of 250 Sharpe estimates is at least 1.4. Then repeat with the variants' daily returns equicorrelated at rho = 0.7, which is closer to the truth when variants share a universe. Report both probabilities with Monte Carlo error and say which one belongs in the memo.
Approach
- Simulate at the frequency the statistic is estimated at: 756 daily draws per variant, not three annual ones. The Sharpe is scale-free, so standard normal draws suffice and the choice of sigma cannot change the answer.
- Build the correlated case as X = sqrt(rho)*Z0 + sqrt(1-rho)*E, with Z0 one common daily draw shared by all variants and E independent per variant. That is exact equicorrelation for one extra column, rather than a 250x250 Cholesky per replication.
- Per replication compute all 250 annualized Sharpes as mean/std(ddof=1)*sqrt(252) along the time axis, take the maximum, and count how often it clears 1.4. Use at least 20,000 replications so the Monte Carlo standard error on a probability near 0.85 is about 0.0025.
- Check the independent case analytically before trusting the simulation: 1 - Phi(z)^250 with z = 1.4/SE and SE = sqrt(252/756) = 0.577 gives z = 2.43 and p close to 0.85. The simulation should land inside two Monte Carlo standard errors of that.
- Get the direction of the correlation effect right. Correlated variants behave like fewer independent trials, so the null maximum is smaller and an observed 1.4 becomes less likely under the null, not more. Present the correlated p-value as the smaller, more favourable number and state plainly that it depends on an assumed rho you did not measure.
Worked solution 25 min
- rng = np.random.default_rng(0); per replication draw X with shape (756, 250).
- sr = X.mean(axis=0)/X.std(axis=0, ddof=1)*np.sqrt(252); store sr.max().
- Repeat with X = sqrt(0.7)*Z0[:, None] + sqrt(0.3)*E where Z0 has shape (756,).
- p = (max_sr >= 1.4).mean(); mc_se = sqrt(p*(1-p)/n_sims).
- Plot both null distributions of the maximum with 1.4 marked on each.
Follow-up
- The team says it only ran six configurations because it discarded the rest early. How do you count trials that were abandoned after somebody looked at the result?
- What Sharpe would the best of 250 have to reach for you to call it significant at 5%, and is that number attainable at this strategy's turnover?
- How would you carve out a holdout the search has genuinely not touched, given the team has already seen the full sample?
Write a function to identify and extract all increasing sub-array leng…
Write a function to identify and extract all increasing sub-array lengths from a given time-series array using optimal time complexity.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- State the window function and its partition and ordering out loud before writing it.
- 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?
How do you find the second highest execution price per asset class usi…
How do you find the second highest execution price per asset class using SQL window functions (DENSE_RANK or ROW_NUMBER), and how do these functions differ when handling price ties?
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from it.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Ramp completion cohort by funding month under amended mandates
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 acrossstrategy_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 onaccount_idalone 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 afterfunded_date, then takeMIN(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 sessionsexceeds the latest business_date in the panel as provisional.
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 would you design a product metric framework to measure the health …
How would you design a product metric framework to measure the health and efficiency of an internal data ingestion platform used by quantitative traders?
Approach
- Fix the population and the time window before naming any metric.
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
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?
Suppose you observe a sudden 15% drop in execution fill rates across a…
Suppose you observe a sudden 15% drop in execution fill rates across an automated trading strategy overnight. How would you systematically diagnose the root cause of this metric drop?
Approach
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
How do you prioritize competing requests from multiple trading desks w…
How do you prioritize competing requests from multiple trading desks when resources and time are strictly limited?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Fix the population and the time window before naming any metric.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you evaluate the product metric design for a trade analytics…
How would you evaluate the product metric design for a trade analytics dashboard used by execution desks to monitor slippage?
Approach
- Fix the population and the time window before naming any metric.
- Restate the decision this analysis has to support, and who acts on the answer.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
What are the primary experimentation pitfalls—such as sample ratio mis…
What are the primary experimentation pitfalls—such as sample ratio mismatch, cluster correlation, and novelty effects—and how do you mitigate them when testing signal updates?
Approach
- Decide the analysis before seeing data, including how long it runs and when you look.
- 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.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
How would you design an A/B testing framework to evaluate a new execut…
How would you design an A/B testing framework to evaluate a new execution routing strategy in live markets where traditional split-testing is hindered by market impact?
Approach
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Name the guardrails that would stop a launch even on a positive primary result.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
Build an execution scorecard that a desk cannot game
A desk reports that its new algo beat interval VWAP by 4 basis points last month. From parent_order (order_qty, filled_qty, arrival_ts, arrival_mid_px, interval_vwap_px, avg_fill_px, adv_20d, status, terminal_ts, algo_name, broker_code) and execution_fill (fill_qty, fill_px, commission_amt, exchange_fee_amt, rebate_amt, liquidity_flag, is_correction), define the primary metric for the monthly algo scorecard, two guardrails and the slicing. Name three ways the VWAP number can be arithmetically true while the desk destroyed value, and state what your primary charges that interval VWAP does not.
Approach
- Make the primary notional-weighted implementation shortfall in basis points against arrival_mid_px, with the denominator order_qty times arrival_mid_px and not filled_qty, and with the unfilled remainder charged at the terminal mid. The denominator is the entire metric: a filled-only denominator lets every cancelled order leave the sample.
- Enumerate the three gaming paths concretely. Stretching the horizon works because interval VWAP is partly set by the desk's own volume and a longer interval both eases the benchmark and exposes the position to drift the benchmark never charges. Cancelling adverse orders works because status = 'canceled' rows vanish from a filled-only sample, leaving the easy fills behind. Routing for rebate works because maximising rebate_amt with liquidity_flag = 'added' earns a fraction of a cent while the missed fill costs multiples of it in drift.
- Set the guardrails against exactly those paths: notional-weighted fill rate (filled_qty over order_qty), and the residual of realized shortfall against the calibrated impact curve at matched participation, so the scorecard cannot be improved by trading only the easy names.
- Slice by participation bucket (filled_qty over adv_20d), by side, and by instrument volatility, using fixed bucket edges. An unsliced monthly average moves with order mix, so a desk can post an improvement by changing what it trades rather than how.
- Keep interval VWAP as a reported diagnostic rather than a scorecard line. The gap between arrival shortfall and VWAP shortfall isolates drift over the trading interval, which is worth reading; it is only dangerous when it is the thing being scored.
Worked solution 35 min
- Join parent_order to execution_fill on order_id, aggregate to notional-weighted avg_fill_px and summed commission_amt, exchange_fee_amt and rebate_amt, netting any row where is_correction = TRUE against the fill it corrects.
- Compute per-order shortfall in basis points with the side sign applied, adding the opportunity-cost term on order_qty minus filled_qty marked at the terminal mid.
- Aggregate with weights order_qty times arrival_mid_px, grouped by algo_name and by participation bucket with edges at 1, 5 and 20 percent of adv_20d.
- Recompute the same aggregate twice more, once over filled orders only and once against interval_vwap_px, and put the three side by side.
- Decompose the arrival-minus-VWAP gap to show how much of the reported 4 basis points came from drift over a lengthened interval rather than from better trading.
Follow-up
- The algo is best in the 0 to 1 percent ADV bucket and worst above 5 percent. What decision does that support, and what does it not support?
- Corrections arrive as new execution_fill rows with is_correction = TRUE. How do they enter avg_fill_px, and what happens to a published monthly number when one lands on the 5th of the next month?
- An order is cancelled because the compliance restricted list turned on mid-day. How should its opportunity cost be marked, and should it score against the algo at all?
TCA traded notional fell while book turnover held
The daily TCA report's traded notional dropped about 12 percent starting on a Tuesday, while turnover computed from position_daily is unchanged. No orders were rejected and parent_order.status shows the usual filled share. You have parent_order (order_id, decision_ts, arrival_ts, terminal_ts, order_qty, filled_qty, broker_code, algo_name) and execution_fill (fill_id, order_id, exec_ts TIMESTAMPTZ(6), received_ts, venue_mic, fill_qty, fill_px, is_correction). Find the missing notional and name the mechanism. Give the ordered checklist, including the cut you would make first and the cut you would deliberately not make first.
Approach
- Reconcile at the order level first. parent_order.filled_qty is maintained by the order management system independently of the fill table, so orders where filled_qty exceeds SUM(fill_qty) over their non-correction fills enumerate exactly which fills the report lost. That turns a 12 percent aggregate into a concrete row set you can cut.
- Cut those rows by exec_ts hour in UTC and by venue_mic before cutting by broker_code. The hour cut tests a time-boundary mechanism. The broker cut will also light up, because whichever broker routes the affected region's flow looks responsible, and that correlation is what sends people down the wrong path.
- Read the report's date predicate. exec_ts is TIMESTAMPTZ(6) in UTC; if the job buckets fills by a local calendar date while bounding parent orders by a different zone's date, every fill that crosses midnight in the mismatched zone falls outside the join window and vanishes without raising an error.
- Establish whether rows were dropped or misfiled. Sum the report over two days instead of one. If the two-day total reconciles, the rows landed in the adjacent bucket; if it does not, they are gone. These look identical in a daily total and demand different fixes.
- Date the change against deploys and configuration rather than against market events, and re-run the prior week's data through the current job to confirm the code moved and the data did not.
Follow-up
- The rows turn out to be misfiled rather than dropped. Does that change your severity assessment, and what does it do to the month-to-date figure?
- Write the predicate you would use so the same report is correct for venues in every timezone, including one whose session spans the UTC date boundary.
- received_ts and exec_ts differ by up to several seconds. Which belongs in the bucketing predicate and which belongs in latency monitoring?
Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Breadth pass: query fluency
- Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
- For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
- Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.
Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Breadth pass: statistics and inference
- Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
- Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
- Rewrite the two weakest answers the following morning from memory in full sentences.
Deliverable: Ten graded answers with an honest count of exact hits.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Breadth pass: modelling
- Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
- Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
- Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.
Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Breadth pass: product judgement
- Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
- For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
- Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.
Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Depth, first area
- Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
- Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
- Re-solve the two you failed the same evening with notes closed.
Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.
Practice prompt ↗Practice prompt ↗06Depth, second area, and the seam between them
- Repeat the depth protocol on the second-ranked area with the same six-problem structure.
- Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
- Solve your own combined problem end to end and note where the handoff between the two areas cost you time.
Deliverable: One combined problem, solved end to end, with the handoff failure written down.
Practice prompt ↗Practice prompt ↗07Integration and re-measurement
- Re-run the six prompts from day one under the same clock and compare both correctness and time.
- Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
- Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.
Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Data people depend on systems owned by other teams, and much of the job is negotiating for instrumentation, access, or a fix to a broken pipeline. Prepare an example of getting something changed upstream that you did not control. Describe what you asked for, what you traded, and how you worked while you waited.
Tell me about a time when a complex data pipeline or predictive model …
Tell me about a time when a complex data pipeline or predictive model failed in production or yielded unexpected results. How did you communicate the failure to stakeholders and remediate the problem?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Quantify the outcome, including what you would not claim credit for.
- 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?
Ranking three quarters of requests into one quarter of capacity
You are the only data scientist supporting three groups for one quarter. The execution desk wants the market-impact curve recalibrated; the last fit is fourteen months old and predates a volatility regime change. A portfolio manager wants a new signal researched. The client team wants a Brinson attribution that reconciles to reported active return, because it currently leaves an unexplained residual of roughly 40 bps a year. Each group believes theirs is first. Produce a ranked plan, the decision rule you used, and what you tell the two groups who do not go first.
Approach
- What is probed: whether you can price work in the firm's units rather than in the requester's urgency, and whether the rule you used survives being stated out loud to the people it ranks last.
- Convert each request into expected basis points of net active return per year with an explicit range, then divide by weeks of your time. The impact recalibration applies to every order: at 150 percent annualized one-way turnover the book trades roughly three times average gross per year counting both sides, so a 2 bps shortfall improvement is about 6 bps of gross annually. Small, high confidence, and applies whether or not any research succeeds.
- Price the signal as an expected value rather than a hoped-for one. Most researched signals do not survive deflation for the number of configurations tried, since the maximum of many noisy Sharpe estimates grows roughly like the standard error times the square root of twice the natural log of the number of trials even with no true edge. A plausible 0.2 information-ratio contribution at a one-in-five survival rate is a large number heavily discounted, with a long right tail that is the reason to do it at all.
- Price the attribution request by what it protects rather than by what it earns. A 40 bps unexplained residual is a number clients see, and attribution that does not reconcile is a credibility cost that surfaces later in the dollar redemption rate. Defensive work can rank first without generating a single basis point of alpha.
- Rank, then sequence for parallelism. Put the short, high-confidence item first if it unblocks somebody else's work, and schedule the long-tailed research where a failure is cheap and discoverable early. State the rule before the numbers, so the groups who lose can argue with the inputs rather than with your loyalties.
- Give each deferred group something real: a date, the specific input that would change the ranking, and the smallest useful piece you will do now, such as a one-day bisection of the 40 bps residual that tells the client team whether it is pricing, cash or trade timing.
Follow-up
- The portfolio manager escalates to your manager's manager. What do you say, and what do you not say?
- The quarter shortens by four weeks. Which item do you drop entirely rather than shrink?
- How do you avoid becoming the person who always picks the execution desk's work because it is the easiest to quantify?
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?
- 01
Tell me about a time when a complex data pipeline or predictive model failed in production or yielded unexpected results. How did you communicate the failure to stakeholders and remediate the problem?
- 02
You are the only data scientist supporting three groups for one quarter. The execution desk wants the market-impact curve recalibrated; the last fit is fourteen months old and predates a volatility regime change. A portfolio manager wants a new signal researched. The client team wants a Brinson attribution that reconciles to reported active return, because it currently leaves an unexplained residual of roughly 40 bps a year. Each group believes theirs is first. Produce a ranked plan, the decision rule you used, and what you tell the two groups who do not go first.
- 03
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.
Is this an official DRW interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at DRW. Rounds and questions reflect what candidates have reported, not a process DRW has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the DRW technical evaluation process?
The evaluation is widely regarded as challenging, particularly in fast-paced mathematical problem-solving during the Online Assessment and phone technical screens. Candidates are advised to dedicate significant preparation time to mental probability calculations, linear algebra concepts, and linear regression failure modes.
PracHub interview research ↗How much time should I expect to spend on the Online Assessment?
The Online Assessment typically ranges from 30 to 90 minutes depending on the specific desk loop. It requires rapid execution, as candidates are asked to solve between 4 and 8 dense math, statistics, and programming problems under tight time constraints.
PracHub interview research ↗What differentiates successful candidates in DRW interview loops?
Successful candidates combine deep mathematical precision with practical engineering execution. Rather than treating models as black boxes, successful applicants can explain the exact underlying statistical mechanics, articulate potential failure modes, and structure clean SQL window functions or Python scripts on demand.
PracHub interview research ↗Does DRW favor candidates with prior financial trading experience?
While prior experience in quantitative finance or market microstructure is helpful, DRW strongly considers candidates from tech, academia, or scientific research backgrounds who demonstrate elite mathematical aptitude, strong coding ability, and a genuine interest in quantitative markets.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
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
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.
Trexquant Investment Data Scientist Interview Questions & Guide 2026
Timed practice for Trexquant Investment data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Tower Research Capital Data Scientist Interview Questions & Guide 2026
Modeling drills for Tower Research Capital data scientist prep: choosing a baseline, reading regression coefficients honestly, handling class imbalance, and defending a model you would actually ship.