As a Data Scientist at Quantexa, you play a crucial role in harnessing data to drive innovative solutions in complex domains like financial fraud detection and risk management. This role is pivotal in shaping the algorithms and models that form the backbone of Quantexa’s products, contributing directly to their mission of enabling organizations to make better decisions through enhanced data analytics.
In your position, you will engage with large datasets, employing statistical techniques and machine learning algorithms to extract insights that influence product development and customer engagement strategies. The complexity and scale of the data you will work with present unique challenges, making this role not only vital to Quantexa's success but also intellectually stimulating and rewarding. You will collaborate with cross-functional teams, contributing to projects that have a significant impact on users and the broader business landscape.
Initial Screening Call
reportedWhoever runs this call is usually not a practitioner. They take notes, and a hiring manager skims those notes later, so the real question is whether your work survives being written down by someone outside the field. Test every project sentence against that: could a non-specialist repeat it correctly without knowing what a propensity score is? Carry a plain-language version of each project and one reason you want this particular role that you could not copy onto another application. Vagueness at this stage reads as inexperience, even when the underlying work was genuinely deep.
What to demonstrate
- Whether a non-specialist can restate your projects accurately, since their paraphrase is what reaches the hiring manager
- Whether your reason for wanting the role points at the work itself rather than the company's reputation
- Whether your language signals the level being screened for: what you decided yourself versus what you were handed
How to prepare
- Write a two-sentence, jargon-free version of each major project: the question nobody could answer, and the decision your work changed. Read it to someone outside data and have them repeat it back
- Point your 'why this role' answer at something concrete in the job description or the product surface you would be working on, and keep it to two sentences
- Have two questions ready about measurement: which metric the team is held to, and who acts on an analysis once it lands
Technical Interviews
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
Coding Assessments
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
Presentations of Prior Work
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
PracHub editorial advice for the preparation topics above.
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.
Reporting the best backtest out of many trials as if it were a single pre-registered test.
The maximum of N noisy Sharpe estimates grows roughly like the standard error times sqrt(2 ln N) even when every underlying strategy has zero edge, so with a few hundred variants an in-sample Sharpe near 1 is the expected result of pure noise. Worse, the search is rarely counted honestly: parameter sweeps, universe changes, date-range choices and feature variants all count as trials. Quote the number of configurations tried, deflate the Sharpe for it, and keep a genuinely untouched holdout period. Note also that the asymptotic standard error of a Sharpe estimate is approximately sqrt((1 + SR^2/2)/T) for i.i.d. normal returns, which for three years of daily data is roughly 0.33, so two strategies differing by 0.3 in Sharpe are not distinguishable.
Reading a dozen metrics with no multiplicity control
Nominate one primary metric before launch and treat the rest as guardrails or exploratory, with Bonferroni or Benjamini-Hochberg applied when you intend to make claims from them. Twenty independent tests at 0.05 under the null produce at least one false positive about 64 percent of the time.
Averaging per-user rates to produce a population rate
Decide which quantity you want: the mean of per-user ratios and the ratio of summed numerator to summed denominator are different estimands, and heavy users dominate one but not the other. For a ratio metric, aggregate numerator and denominator separately and use the delta method for its variance.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Describe how you would structure a data pipeline for a machine learnin…
Describe how you would structure a data pipeline for a machine learning project.
Approach
- Check what information would not exist at prediction time, and exclude it.
- 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.
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?
Implement a basic decision tree algorithm in pseudo-code.
Implement a basic decision tree algorithm in pseudo-code.
Approach
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Check what information would not exist at prediction time, and exclude it.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Validate a point-in-time signal panel before it is traded
signal_score arrives as a DataFrame with signal_id, model_version, instrument_id, as_of_date, knowledge_ts (UTC), raw_value, zscore_xs, decile_rank, universe_id, coverage_flag, is_backfilled and computed_at: one signal, six years, about 2.4M rows. Write a checker returning a tidy frame of (check_name, as_of_date, n_violations, example_instrument_id) covering grain duplication, knowledge_ts ordering, the cross-sectional moments of zscore_xs, effective coverage, and day-over-day universe churn. Choose your own thresholds and state each one in the output.
Approach
- Start with the grain. The declared key is (signal_id, model_version, instrument_id, as_of_date). Count rows per key rather than calling duplicated(), which with keep='first' reports k-1 for k copies and tells you nothing about whether the copies disagree. Compare raw_value across the duplicates to separate a harmless double-load from two model outputs colliding.
- Check the two timestamp orderings, both of which are silent lookahead: knowledge_ts earlier than the close of as_of_date means the row claims to know a day's value before the day ended, and knowledge_ts later than computed_at is impossible, since inputs cannot become observable after the job that read them ran.
- Per as_of_date, take the moments of zscore_xs. It is winsorized at +/- 3 within universe_id, so the mean should sit near zero and the standard deviation a little under one; flag |mean| > 0.05 or std outside [0.85, 1.15]. Separately verify decile_rank is monotone in zscore_xs within the date and that each decile holds n/10 plus or minus one name.
- Measure effective coverage, not row coverage: put only coverage_flag = 'computed' in the numerator, and additionally flag instruments whose raw_value is unchanged for more than ten consecutive as_of_dates, which catches a feed that stopped updating without emitting a single null.
- Compute universe churn as the symmetric difference of the instrument sets on consecutive as_of_dates over the mean of the two sizes. Outside index reconstitution this should sit well under 1% a day, so flag above 5%. Report the is_backfilled share on the same frame: a spike is a rerun that rewrote history in place.
Worked solution 25 min
- Sort by (instrument_id, as_of_date). Build grain counts with groupby(key).size() and keep keys above 1.
- Express the two timestamp checks as boolean columns, then aggregate per as_of_date with sum for the count and idxmax for the example instrument.
- Per-date moments via groupby('as_of_date')['zscore_xs'].agg(['mean','std','count']), plus a Spearman check of zscore_xs against decile_rank within each date.
- Staleness runs: group by instrument_id, compare raw_value to its shift(1), start a run id with a cumsum over the change flag, and take run lengths.
- Universe churn from consecutive-date sets built with groupby('as_of_date')['instrument_id'].agg(set) and differenced pairwise.
Follow-up
- A date shows 4% of rows with knowledge_ts before the as_of_date close. How do you decide between dropping those rows, shifting their knowledge_ts, and quarantining the whole date?
- Which of these checks belongs in the daily job as a blocking gate and which as a report, and what does a false positive cost in each case?
- How would the thresholds change for a signal whose eligible universe is 120 names rather than 1,500?
Given a list of integers, how would you find the two numbers that sum …
Given a list of integers, how would you find the two numbers that sum up to a specific target?
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
How would you optimize a SQL query for performance?
How would you optimize a SQL query for performance?
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- 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 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 do you stay updated on the latest trends and technologies in data …
How do you stay updated on the latest trends and technologies in data science?
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.
- 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?
- Which segment would you cut first, and what would that rule out?
Given a dataset on financial transactions, how would you identify pote…
Given a dataset on financial transactions, how would you identify potential fraud?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Fix the population and the time window before naming any metric.
- 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?
Present a business case where data analysis influenced a significant d…
Present a business case where data analysis influenced a significant decision.
Approach
- 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.
- Fix the population and the time window before naming any metric.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
How would you evaluate the success of a data science project?
How would you evaluate the success of a data science project?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
- 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?
- Which segment would you cut first, and what would that rule out?
Explain the difference between supervised and unsupervised learning.
Explain the difference between supervised and unsupervised learning.
Approach
- State your assumptions explicitly before working the problem.
- Work from the decision backwards to the evidence you would need.
- Clarify what is being asked and what a complete answer would contain.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Measure forced trimming at a compliance threshold you cannot randomise
Compliance forces a trim whenever a position's weight_pct_nav in position_daily closes above the account's max_single_name_weight_pct from account_mandate, a hard 5.00 percent cap evaluated at the close and trimmed the next morning. Portfolio managers claim forced trimming destroys alpha, and compliance cannot be randomised. Over three years about 4,100 account-instrument-days sit within one percentage point of the cap. Identify the effect of forced trimming on the position's contribution to active return over the following twenty business days, and state what your estimate is and is not.
Approach
- Set it up as a sharp regression discontinuity in weight_pct_nav centred on the cap. Treatment is a deterministic function of the running variable, so the identifying assumption is only that potential outcomes are continuous at 5.00 percent. Nothing has to be randomised, which is the whole reason the design applies here.
- Test for manipulation before estimating anything. A density test on the running variable around the cap asks whether managers shave positions to 4.95 percent to stay under it. If the density has a hole just above the threshold, the design is dead and the correct deliverable is that the effect is not identified, not a number with a caveat.
- Estimate with local linear regression on each side, a triangular kernel and a data-driven mean-squared-error-optimal bandwidth rather than one chosen by eye, using robust bias-corrected confidence intervals. Report the estimate at that bandwidth and at half and double it to show the result is not a bandwidth artefact.
- State the estimand precisely. This is a local average treatment effect at a 5.00 percent weight, for positions large enough to reach the cap, in accounts whose mandate sets the cap there. It says nothing about trimming a 2 percent position and nothing about accounts with a 3 percent cap, unless you pool across caps by re-centring each observation on its own threshold, which is legitimate and enlarges the sample at the cost of assuming the discontinuity is the same at every cap level.
- Handle the two schema traps explicitly. account_mandate is SCD2, so an account whose cap was amended mid-history has two thresholds and each observation must be compared to the cap in force on its own business_date. And weight_pct_nav is derived from mark_px, so rows with mark_source of 'stale_prior_day' or 'model' carry a running variable measured with error, which in a discontinuity design attenuates the estimate and smears the jump. Exclude those rows and report how many were dropped.
- Say what would make you switch designs. If the cap is soft in practice, with a tolerance band, a grace day or discretionary waivers, the design is fuzzy rather than sharp: the indicator for being above the cap instruments for actually being trimmed, the estimate scales by the compliance rate, and the first-stage strength becomes something you have to report.
Worked solution 45 min
- Build the panel by joining position_daily to account_mandate on business_date between effective_from and effective_to, keeping account_id, instrument_id, business_date, weight_pct_nav, max_single_name_weight_pct and mark_source, and dropping rows whose mark_source is 'stale_prior_day' or 'model'.
- Construct the running variable as weight_pct_nav minus max_single_name_weight_pct, and the outcome as the position's cumulative contribution to active return over the next twenty business days.
- Run the density test at zero and report its p-value. If it fails, stop and report non-identification.
- Estimate local linear regression discontinuity with a triangular kernel at the optimal bandwidth and at half and double it, reporting robust bias-corrected intervals for each.
- Run falsification checks: the same discontinuity estimate on pre-determined covariates such as beta_to_benchmark, adv_20d and gics_sector_code must show nothing, and placebo cutoffs at plus and minus half a percentage point must show nothing.
- Cluster standard errors on account_id by instrument_id, because the same position recurs on consecutive days and its twenty-day forward outcomes overlap almost completely.
Follow-up
- How many observations actually fall inside the optimal bandwidth, and what effect size can that number detect?
- If the density test fails, what fallback design would you accept, and what would it now assume?
- Positions that reach the cap are the highest-conviction names in the book. Does that break the design, and if not, precisely why not?
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?
For a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.
Tell me about a time you had to work collaboratively in a team. What w…
Tell me about a time you had to work collaboratively in a team. What was your role?
Approach
- Close with what you would do differently, concretely.
- Pick a story where you drove the decision, not one where you observed it.
- State the situation in two sentences and spend the rest on your reasoning.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
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?
Explaining why two accounts in one strategy diverged 210 bps
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?
- 01
Tell me about a time you had to work collaboratively in a team. What was your role?
- 02
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.
- 03
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.
Is this an official Quantexa interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Quantexa. Rounds and questions reflect what candidates have reported, not a process Quantexa has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What is the typical interview difficulty and preparation time?
The interview process is generally considered difficult, requiring thorough preparation. Candidates should allocate several weeks to practice coding, review data science concepts, and prepare for case studies.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates often exhibit strong technical skills, a collaborative mindset, and the ability to communicate complex ideas clearly. Demonstrating a passion for data science and alignment with Quantexa's mission is also crucial.
PracHub interview research ↗What is the culture and working style at Quantexa?
Quantexa fosters a culture of innovation, collaboration, and continuous learning. Employees are encouraged to share ideas and work together to solve complex problems.
PracHub interview research ↗How long does the interview process typically take from start to offer?
The entire interview process can take anywhere from two to six weeks, depending on the scheduling of interviews and assessments.
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.
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.
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.
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.