Trexquant Investment · Data Scientist
Updated · 2026-09-22

Trexquant Investment Data Scientist
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

At Trexquant Investment, a Data Scientist operates at the intersection of quantitative finance, machine learning, and high-performance software engineering. As a technology-driven systematic investment firm, Trexquant relies on its data science and quantitative research team to discover alpha—trading signals that predict price movements across global equity and futures markets. Unlike traditional tech companies where data science may focus on consumer app features, a Data Scientist at Trexquant builds predictive models, analyzes massive datasets, and develops algorithmic trading strategies that directly drive investment portfolio performance.

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

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

Separate forecast decay from execution costMeasure shortfall against arrival, not VWAPModel impact and borrow before claiming capacity

35 min read

Practice 17 Data Scientist prompts
10Candidate experiences ↗Read their reports
17Practice promptsAcross five skill areas
3With worked solutionsIncluded in the practice prompts

At Trexquant Investment, a Data Scientist operates at the intersection of quantitative finance, machine learning, and high-performance software engineering. As a technology-driven systematic investment firm, Trexquant relies on its data science and quantitative research team to discover alpha—trading signals that predict price movements across global equity and futures markets. Unlike traditional tech companies where data science may focus on consumer app features, a Data Scientist at Trexquant builds predictive models, analyzes massive datasets, and develops algorithmic trading strategies that directly drive investment portfolio performance.

The impact of this role is immediate and measurable. You will transform terabytes of structured and alternative market data into mathematical models and statistical features. Whether you are engineering alpha signals, developing NLP strategies to ingest unstructured text, or building automated simulation frameworks, your quantitative output directly feeds Trexquant's systematic production trading engines. The firm's proprietary platform processes thousands of input features, requiring candidates to demonstrate exceptional statistical rigor, clean production-ready Python code, and deep intuition for empirical data patterns.

Candidates joining the Trexquant Investment team enter an environment that balances rigorous academic research with high-frequency quantitative execution. You will work on complex mathematical problems, evaluate market dynamics, and build production pipelines where algorithmic efficiency and code accuracy are paramount. Succeeding in this role requires strong mathematical maturity, resilience under technical scrutiny, and an ability to translate abstract statistical concepts into actionable, high-performing trading algorithms.

01

Initial Coding Challenge

reported

Before anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.

What to demonstrate

  • Whether an ambiguous term becomes a specific column and filter before any computation happens
  • Whether you read the schema for keys and cardinality rather than only for column names
  • Whether the result answers the question at the grain it was asked at, per user or per session or per day

How to prepare

  • Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
  • On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
  • Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
PracHub interview research
02

Technical Interviews

reported

Before anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.

What to demonstrate

  • Whether an ambiguous term becomes a specific column and filter before any computation happens
  • Whether you read the schema for keys and cardinality rather than only for column names
  • Whether the result answers the question at the grain it was asked at, per user or per session or per day

How to prepare

  • Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
  • On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
  • Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
PracHub interview research
03

Behavioral Assessments

reported

This round decides whether you owned a decision or watched one happen nearby. Interviewers for data roles listen for the point where the analysis stopped being a report and started changing what someone did, so build each story around that hinge: what was going to happen by default, what you found, and what happened instead. The most common weakness is a story that ends at delivery. If you can name the decision your work changed and the number that moved because of it, most follow-ups become easy.

What to demonstrate

  • Whether the decision was yours to influence, or whether you are narrating a team outcome in the first person
  • The counterfactual: what would have been done without your analysis, and why that default was worse
  • How far your involvement ran past the handoff, and whether you checked that the change did what you predicted

How to prepare

  • Pick three projects and write one sentence for each naming the decision-maker, the choice in front of them, and what they chose after seeing your work. If you cannot name a person and a choice, the story is not ready for this round.
  • Reconstruct the baseline for your strongest project from the original query or dashboard rather than memory, so the before-number survives a follow-up asking where it came from.
  • Prepare an honest version of a project where your recommendation was overruled, including what you did with the analysis afterwards.
PracHub interview research

10 candidate reports. Individual accounts describe a particular role and hiring cycle.

Data Scientist

Trexquant Investment Data Scientist interview with ML, DSA, and onsite superday

Online Assessment → Technical Screen → Onsite

My interview process started when HR reached out. I then completed an online assessment covering ML and DSA style material, followed by a technical question round with one or two LeetCode problems in the medium to hard range. I expected more direct data science or machine learning questions, but those topics didn't really come up beyond the assessment. The next stage was an onsite superday. It we…

Read full experience
Quantitative Analyst

Trexquant Investment Quantitative Analyst interview: Hangman ML project

Take-home Project → Technical Screen

I started with the Hangman project, which was also mentioned as one of the stages other people had gone through for this company. It was a take-home coding challenge focused on improving the model's guessing performance. Later, the interviewer asked me directly how I'd make it better. After that, I discussed the project with an interviewer. The conversation was strongly focused on machine learnin…

Read full experience
Quantitative Analyst

Trexquant Investment Quantitative Analyst interview: one-month process ending with a CEO round

HR Screen → Technical Screen → Onsite → Other

I first spoke with a recruiter about my background and general fit. That was followed by an online technical interview with a quant researcher focused on my analytical and quantitative skills. After that, I attended an onsite superday with several back-to-back interviews with different team members. The final stage was an interview with the CEO. The process took around a month. The recurring topi…

Read full experience
Quantitative Analyst

Trexquant Investment Quantitative Analyst, medium LeetCode-style technical screen

Technical Screen

About a week after the recruiter call, I had a technical screen. We went through my resume, then I solved a medium LeetCode-style coding problem. It felt like a straightforward test of whether I could turn my background into clean, working code. I eventually reached the next step, which sounded like it was leading toward a superday. I hadn't completed the onsite portion yet, so the process stoppe…

Read full experience
Quantitative Analyst

Trexquant Investment Quantitative Analyst medium coding round

HR Screen → Technical Screen → Other

I started with an HR call and then moved straight into a first technical round with a senior researcher. We discussed my resume, including follow-up questions, and then I was given a LeetCode medium problem. Depending on what came up from my experience, there was also room for probability or statistics questions. The coding portion felt like a direct test of fundamentals: arrays, clean implementa…

Read full experience

PracHub editorial advice for the preparation topics above.

01

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.

02

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.

03

Ending an analysis without a recommendation or next step

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

04

Over-explaining the method and under-explaining the implication

Lead with the answer and what you would do about it, then give the approach when asked. Roughly one sentence of method per three of implication is the right ratio for a stakeholder-facing answer; the interviewer already knows what a regression is.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

14 technical prompts3 include a worked solution

Walk through a mathematical proof demonstrating the properties of cond…

medium
statistics and probability

Walk through a mathematical proof demonstrating the properties of conditional probability and how Bayes' theorem can be applied to iterative pattern matching.

Approach
  1. Say what the estimate is of, and over what population it generalises.
  2. Sanity-check the answer against a simple bound or a simulated case.
  3. Translate the result into the decision it informs, in one plain sentence.
Follow-up
  • Which assumption here is most likely to be violated in practice?
  • What sample size would you need to detect an effect half this size?

How do you design an A/B testing framework to evaluate the performance…

medium
machine learning and modelling

How do you design an A/B testing framework to evaluate the performance of two competing execution algorithms operating in live financial markets?

Approach
  1. Say how the offline result would be validated online before it is trusted.
  2. Frame the prediction: the label, the moment of prediction, and the action it triggers.
  3. Check what information would not exist at prediction time, and exclude it.
Follow-up
  • What would you monitor after launch to know the model is still valid?
  • How would you choose the decision threshold, and who owns that choice?

Permutation test for mean IC with overlapping forward returns

hardWorked solution
permutation testsignal evaluationautocorrelation

panel has as_of_date, instrument_id, zscore_xs and fwd_ret_5d_excess, the five-trading-day forward return in excess of the universe's cap-weighted mean, for 252 dates and roughly 1,500 instruments a date. Compute the daily Spearman rank IC and its mean. Then build a permutation null from scratch and report a two-sided p-value. Compare it with a naive t-test on the 252 daily ICs and with a Newey-West t using four lags. State which null hypothesis your permutation scheme actually tests.

Approach
  1. Compute the daily IC by ranking both columns within as_of_date with method='average' and taking the Pearson correlation of the rank vectors. Decide explicitly how to treat dates where the universe shrinks, because an unweighted mean gives a 40-name date the same weight as a 1,500-name date.
  2. The obvious permutation shuffles zscore_xs within each as_of_date. That is the right exchangeability for the null 'the signal carries no cross-sectional ordering on any given day', and it preserves the daily sample size and the cross-sectional return structure, factor effects included.
  3. But it makes the permuted daily ICs independent across dates, and the real ones are not. A five-day forward return sampled every day shares four days with its neighbour, and the signal itself is persistent, so the observed IC series is strongly autocorrelated. Under an i.i.d. daily return null the variance of the mean of overlapping h-period observations inflates by a factor of h, so the within-day null is too narrow by about sqrt(5) and its p-value is anti-conservative.
  4. Fix it by permuting at the date level: circularly shift the whole signal panel's as_of_date labels by a random offset, keeping each day's cross-section and the signal's serial persistence intact while breaking its alignment with the returns. The 252 distinct shifts give an exact randomization test with a p-value floor of 1/252.
  5. Report all three numbers. The naive t and the Newey-West t with 4 lags (h-1 for h = 5) should differ by a factor near sqrt(5), and the shift-permutation p should agree with the Newey-West figure rather than the naive one. If it does not, one of the two is implemented wrongly and you have a cheap way to find out which.
Worked solution 45 min
  1. ranks = panel.groupby('as_of_date')[['zscore_xs','fwd_ret_5d_excess']].rank(method='average'); daily IC is the per-date Pearson correlation of the two rank columns.
  2. Within-day scheme: one rng.permutation of the signal rank vector inside each date, 10,000 replications of the mean IC.
  3. Shift scheme: remap as_of_date through a circular offset over the sorted unique dates, re-join to the returns on (shifted_date, instrument_id), and record how much of the panel drops because an instrument is absent on the shifted date, since a large loss biases the null.
  4. naive_t = mean(IC)/(std(IC, ddof=1)/sqrt(252)); Newey-West t with a Bartlett kernel and 4 lags.
  5. Put the three p-values, the two t-statistics, the replication count and the p-value floor in one table.
EXPECTED RESULTThe within-day permutation p-value tracks the naive t and is the smallest of the three. The Newey-West t is smaller than the naive t by a factor near sqrt(5) = 2.24, and the shift-permutation p sits close to it. A mean IC of 0.03 with a daily IC standard deviation near 0.10 gives a naive t around 4.8 and a Newey-West t around 2.1, which is the difference between 'obvious' and 'worth one more year of data'.
Follow-up
  • With 252 circular shifts and the observed statistic the largest among them, what is the smallest p-value you can report, and is it small enough for the decision being made?
  • How would you redo this on non-overlapping five-day samples, and how much power do you surrender?
  • The signal has a 12-day decay half-life. Does that change your shift block length or your Newey-West lag choice?

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.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Design 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 ↗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.

Have two ready. In one, the data was on your side and you had to move someone who outranked you. In the other, the pushback was correct and you changed position. The second is the harder story and it lands better, because it shows you separate being right from being attached to an answer. Name the person's actual objection.

Walk me through a time when an interviewer or senior executive rigorou…

medium
behavioural and stakeholder questions

Walk me through a time when an interviewer or senior executive rigorously challenged the authenticity or implementation details of your code. How did you handle the high-pressure interaction?

Approach
  1. Quantify the outcome, including what you would not claim credit for.
  2. Name the disagreement or constraint, and how you resolved it with evidence.
  3. Pick a story where you drove the decision, not one where you observed it.
Follow-up
  • What would you do differently if you ran that project again?
  • What did you decide not to do, and why?

Defending a backtest correction that removes an allocated strategy

medium
stakeholder pushbackbacktest integritylookahead bias

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

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

Explaining why two accounts in one strategy diverged 210 bps

easy
client communicationattributionreconciliation

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

    Walk me through a time when an interviewer or senior executive rigorously challenged the authenticity or implementation details of your code. How did you handle the high-pressure interaction?

  • 02

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

  • 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.

PracHub interview preparation framework
Is this an official Trexquant Investment interview guide?

No. It is PracHub's own research and practice material for the Data Scientist role at Trexquant Investment. Rounds and questions reflect what candidates have reported, not a process Trexquant Investment has published, and they change over time. Confirm the current format and scope with your recruiter.

PracHub interview research
How difficult is the Trexquant Data Scientist interview process?

The process is challenging and technically rigorous. It tests both theoretical knowledge (probability, proofs, ML mathematics) and practical execution (live coding, the 1-week Hangman challenge, and SQL window functions). Focused preparation on core fundamentals is essential.

PracHub interview research
How much time should I invest in the initial take-home assignment?

Candidates report dedicating significant time (often 10–20 hours across the week) to optimize their Hangman Challenge submission. Reaching an accuracy threshold well above 50% significantly improves your chances of advancing to the technical interview rounds.

PracHub interview research
What is the tone of the final CEO / Executive interview round?

The CEO round is short, direct, and highly focused on technical verification. Expect direct questions about your project code, live adaptation requests, and scrutiny regarding individual code ownership. Approach this round with clarity, objectivity, and confidence.

PracHub interview research
Are financial markets or trading domain knowledge strictly required?

While prior exposure to quant finance or factor models is beneficial, strong candidates from pure Computer Science, Physics, Mathematics, or Data Science backgrounds frequently excel if they demonstrate exceptional mathematical, statistical, and coding talent.

PracHub interview research
Sources & methodology 3 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.