At Susquehanna International Group (SIG), data is not just an asset—it is the lifeblood of the entire firm. As a Data Scientist, you will operate at the intersection of quantitative research, software engineering, and live trading. Unlike traditional technology companies where data science might focus on user growth or product features, at SIG, your work directly impacts financial market-making, algorithmic execution, and risk management. You will build, test, and deploy highly sophisticated predictive models that analyze massive, high-frequency market datasets to identify pricing anomalies and execute trades in fractions of a second.
This role is highly critical because SIG is a leading global proprietary trading firm. The models you build will directly influence how capital is allocated across options, equities, derivatives, and other complex financial instruments. You will collaborate closely with quantitative researchers, traders, and systems engineers to translate mathematical theories into highly optimized, real-world trading strategies.
The environment is fast-paced, intellectually rigorous, and deeply collaborative. Whether you are optimizing existing option-pricing models or exploring alternative datasets to find novel signals, your day-to-day work will involve solving some of the most complex mathematical and computational challenges in the financial industry. For individuals who thrive on immediate feedback, quantitative rigor, and high-impact problem-solving, this role offers an unparalleled opportunity to see your work directly affect the firm's bottom line.
Online Assessment
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Recruiter Phone Screen
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
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
Take-Home Data Exercise
reportedYour submission is read asynchronously by someone who cannot ask you a clarifying question, and who will usually skim it before reading it properly. That changes what good looks like. The conclusion belongs near the top with the supporting analysis beneath it, and the code should run start to finish on a clean machine without a manual step you forgot to document. A reviewer forced to reconstruct your reasoning from the order of notebook cells is already discounting the work. The submissions that land are the ones where a busy reader gets the answer immediately and can verify it if they want to.
What to demonstrate
- Whether the answer arrives before the methodology, so a reader who stops after the first page still has the recommendation
- Whether the code runs end to end from the submitted files, with dependencies and data paths declared rather than assumed
- Whether each chart is legible on its own, carrying axis labels and units, and exists to support a claim made in the text
How to prepare
- Restructure a past analysis so the opening paragraph holds the recommendation and the number behind it, then check that nothing later in the document quietly contradicts it
- Copy your own submission into an empty directory, run it in a clean environment, and fix everything that breaks; hidden local state is caught here or by the reviewer
- For every chart, write the one sentence it is meant to prove, and delete the chart if you cannot write that sentence
Superday
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
PracHub editorial advice for the preparation topics above.
Computing a t-statistic on daily observations of an h-day forward return as if the observations were independent.
Sampling an h-day forward return every day means consecutive observations share h-1 days of the same return, which induces strong positive autocorrelation. The naive standard error is too small by a factor on the order of sqrt(h), so a 5-day-horizon signal with a genuine t of 1.3 can present as 2.9. Either use non-overlapping samples, which costs power, or use a Newey-West or Hansen-Hodrick covariance with at least h-1 lags, and state which one was used.
Judging execution quality against interval VWAP and treating a favourable number as proof of good trading.
Interval VWAP is a benchmark the trader partly determines: trading in line with volume tracks VWAP almost by construction, and stretching an order over a longer interval makes the benchmark easier while exposing the position to price drift that the benchmark never charges. Arrival price is the benchmark aligned with the decision, because it charges both the spread and the drift between decision and completion, including the unfilled remainder. Reporting both, and reporting the opportunity cost of unfilled quantity, is what separates a real TCA from a flattering one.
Writing SQL without stating NULL and tie-breaking behaviour
Before calling a query finished, say what it does with NULLs, ties and empty groups. NOT IN against a subquery containing a single NULL returns no rows at all, and RANK, DENSE_RANK and ROW_NUMBER differ precisely on ties, so name which one the question requires.
Accepting a metric definition without asking about the denominator
Pin down the denominator, the eligibility filter and the time window before computing anything: conversion rate per session, per user, per eligible user and per new user are four different numbers with different behaviour. Restate the definition in one sentence and get agreement before you analyse.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
If you roll three fair six-sided dice, what is the probability that th…
If you roll three fair six-sided dice, what is the probability that the sum of the numbers rolled is exactly 10?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Sanity-check the answer against a simple bound or a simulated case.
- Write down the assumption the method needs before you use the method.
Follow-up
- Which assumption here is most likely to be violated in practice?
- How would you explain this result to someone who does not know statistics?
What is the probability of getting a Head-Tail-Head (HTH) sequence bef…
What is the probability of getting a Head-Tail-Head (HTH) sequence before a Head-Head-Tail (HHT) sequence when flipping a fair coin repeatedly?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Translate the result into the decision it informs, in one plain sentence.
- Write down the assumption the method needs before you use the method.
Follow-up
- Which assumption here is most likely to be violated in practice?
- How would you explain this result to someone who does not know statistics?
You are flipping a fair coin. What is the expected number of flips req…
You are flipping a fair coin. What is the expected number of flips required to get two consecutive heads?
Approach
- Translate the result into the decision it informs, in one plain sentence.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Say what the estimate is of, and over what population it generalises.
Follow-up
- What sample size would you need to detect an effect half this size?
- Which assumption here is most likely to be violated in practice?
Explain Bayes' theorem and walk through a scenario where you must calc…
Explain Bayes' theorem and walk through a scenario where you must calculate the posterior probability of a rare disease given a positive test result with a known false-positive rate.
Approach
- Translate the result into the decision it informs, in one plain sentence.
- Sanity-check the answer against a simple bound or a simulated case.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
Follow-up
- What sample size would you need to detect an effect half this size?
- Which assumption here is most likely to be violated in practice?
Annualized information ratio with an honest standard error
You are given active, one row per (account_id, business_date) with active_return: the daily arithmetic portfolio-minus-benchmark return, net of all costs, as a decimal. Three accounts, roughly 750 business days each. Rows are absent on exchange holidays and on days before an account's funded_date. Per account, compute the annualized information ratio (mean times 252, divided by standard deviation times sqrt(252)) and an approximate standard error for that ratio, then report a 95% interval. Do not reindex onto a calendar. State what T you used and why.
Approach
- Drop null active_return per account rather than filling it. T must be the number of days the account actually traded: holidays and pre-funding days are not evidence, and treating them as such changes both the point estimate and the interval.
- Compute the daily mean m and the daily standard deviation s with ddof=1. The annualized IR is (m/s)*sqrt(252), because the 252 in the numerator and the sqrt(252) in the denominator collapse to a single sqrt(252) factor. Say that out loud instead of writing two separate annualizations that can drift apart.
- Take the standard error at the frequency the statistic is estimated at: SE(SR_daily) is approximately sqrt((1 + SR_daily^2/2)/T) for i.i.d. normal returns, then scale it by sqrt(252), the same factor as the point estimate. At daily frequency SR_daily^2/2 is of order 1e-3, so the SE is effectively sqrt(252/T) and depends only on elapsed years.
- Report IR plus or minus 1.96*SE per account, and check the lag-1 autocorrelation of active_return. The i.i.d. assumption behind that SE is the same assumption that justifies the sqrt(252) scaling, so if the series is autocorrelated both numbers need widening and you should say by how much.
Worked solution 20 min
- groupby('account_id'), dropna on active_return, and record n per account before anything else.
- Per account compute m = mean, s = std(ddof=1), ir = m/s*sqrt(252).
- sr_d = m/s; se_ann = sqrt((1 + sr_d**2/2)/n)sqrt(252); interval = ir +/- 1.96se_ann.
- Compute lag-1 autocorrelation of active_return per account and print it in the same table as the interval.
Follow-up
- The shortest account has 14 months of history. How much of the spread between the best and worst account IR is explainable by sampling noise alone?
- One account carries mark_source = 'vendor_eval' on 30% of days. What does that do to the denominator, and to the independence assumption behind the standard error?
- How many years of daily data would you need to distinguish an IR of 0.8 from an IR of 1.1 at 95% confidence?
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.
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.
Reconstruct a point-in-time universe from effective-dated reference data
instrument_master is effective-dated: one row per instrument_id per version, valid over [effective_from, effective_to), with effective_to NULL while the version is open. Other columns include ticker, asset_class, primary_exchange_mic, status, is_shortable, listing_date and delisting_date. Write one query returning every instrument that was a listed, shortable equity as of 2023-06-30 17:00 UTC: one row per instrument_id, carrying the ticker in force at that instant. The result must still contain names that have delisted since.
Approach
- Predicate on the validity window rather than on the latest row:
effective_from <= :ts AND (effective_to > :ts OR effective_to IS NULL). The half-open form is what guarantees exactly one row per instrument_id when one version ends at the same instant the next begins. - Read the attributes from that version, not from today's row:
asset_class = 'equity',is_shortable, andstatusas recorded in the version. Today'sstatusis the wrong fact for a past date. - Bound the lifecycle separately:
listing_date <= :ts::date AND (delisting_date IS NULL OR delisting_date > :ts::date), so pre-IPO shells and names already dead on that date drop out on that date's own terms. - Probe uniqueness with
GROUP BY instrument_id HAVING COUNT(*) > 1. A duplicate means the source has overlapping versions, which is a data-quality finding to escalate, not something to paper over with DISTINCT. - Confirm the temporal behaviour by re-running with the timestamp moved past a known delisting and checking the name disappears then, and only then.
Worked solution 20 min
- Write the range predicate as a CTE parameterised on the cutoff timestamp so the same text is reusable per date.
- Add the attribute filters inside the CTE, then the listing/delisting bounds in the outer select.
- Run the duplicate probe on instrument_id and confirm it returns no rows.
- Re-run with
effective_to IS NULLsubstituted for the range predicate and diff the two result sets. - Inspect the diff: every row present only in the correct version should have a non-null
delisting_dateor a later reference-data amendment.
Follow-up
- The vendor backdates a correction, so
effective_fromfor a new version precedes an existing one and your query returns two rows for one instrument_id. How do you resolve it, and what doesloaded_atlet you express thateffective_fromcannot? - Someone proposes joining research panels on
tickerbecause it is human-readable. Give a concrete failure mode with a date attached. - How would you turn this single-date query into one that produces the universe for every date in a range without a loop?
You are offered a bet where you flip a coin. If it lands heads, you wi…
You are offered a bet where you flip a coin. If it lands heads, you win $2. If it lands tails, you lose $1. If you can play this game indefinitely, how much of your bankroll should you wager on each flip to maximize your long-term growth rate?
Approach
- Say what you would check first and why it is the highest-information step.
- Work from the decision backwards to the evidence you would need.
- 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?
A drawer contains 20 black socks and 20 white socks. If you pull socks…
A drawer contains 20 black socks and 20 white socks. If you pull socks out at random in the dark, what is the minimum number of socks you must pull out to guarantee you have at least one matching pair?
Approach
- Clarify what is being asked and what a complete answer would contain.
- Say what you would check first and why it is the highest-information step.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Define promotion criteria for a candidate cross-sectional signal
A researcher proposes promoting a new signal_id in signal_score to the live book. You have zscore_xs, decile_rank, knowledge_ts, universe_id and coverage_flag per instrument_id per as_of_date, plus daily forward returns for the same universe. The book rebalances every five trading days. Define success for the promote or do-not-promote decision: one primary metric with its estimation window and its error bar, two guardrails with numeric thresholds, and one result that would make you refuse promotion even when the primary metric looks strong.
Approach
- Set the primary as mean daily Spearman rank IC between zscore_xs and the 5-day forward return in excess of the universe cap-weighted mean, over the trailing 252 dates, with the panel filtered on knowledge_ts at or before the decision cutoff rather than on as_of_date. Report it with a Newey-West standard error using at least 4 lags, because daily samples of a 5-day forward return share 4 days of the same return.
- Translate the IC into the quantity the decision actually needs. IR is approximately IC times the square root of breadth, times a transfer coefficient once constraints bind. State the assumptions out loud: independent bets and risk-proportional sizing. Breadth is not the number of names multiplied by the number of rebalances, because cross-sectional returns are correlated through common factors, so treat that product as an upper bound and not an estimate.
- Guardrail one is signal decay half-life computed as in the metric tree: IC(h) for h in 1 to 21, half-life interpolated where IC(h) first falls below half of IC(1). A half-life shorter than the 5-day rebalance means the measured edge is not reachable at the trading frequency, whatever the headline IC says.
- Guardrail two is marginal contribution, not standalone quality. Regress the candidate's daily long-short return on the existing live composite's and judge the residual, because a signal with IC 0.04 that is 0.9 correlated with what is already traded adds close to nothing and costs turnover.
- Make the refusal condition explicit before seeing the number: state how many configurations were tried, deflate the result for that search, and require an untouched holdout period. A high IC on the 40th variant of a feature is an order statistic, not an estimate.
Worked solution 25 min
- Build the instrument-by-date panel: signal_score joined to forward returns, keeping rows where knowledge_ts is at or before the decision cutoff on as_of_date, and resolving universe membership through instrument_master effective_from and effective_to rather than status = 'active'.
- Compute the per-date Spearman rank correlation across instruments to get a daily series of 252 IC values; record the series standard deviation as well as its mean.
- Compute the naive standard error as the series standard deviation over the square root of 252, then the Newey-West standard error with 4 lags, and report both so the inflation factor is visible.
- Compute IC(h) for h in 1 to 21 and interpolate the half-life; compare it to the 5-day rebalance horizon.
- Regress the candidate's daily long-short return on the live composite's return and compute the information ratio of the residual.
Follow-up
- Your mean IC is 0.03 with a Newey-West t of 2.7 and the team tested 60 configurations. What is your deflated view, and what evidence would still justify promotion?
- The IC is concentrated in the bottom quintile of adv_20d. How does that change the decision, and which guardrail should have caught it?
- Coverage_flag is 'imputed' for 8 percent of the universe. How does imputation bias the measured IC in either direction?
Backtest IC improved on unchanged history after deployment
After a scheduler release, the research backtest for one signal reports mean daily IC of 0.041 over a fixed five-year window, against 0.024 for the same window and the same model_version before the release. Nothing in the model changed. Table: signal_score (signal_id, model_version, instrument_id, as_of_date, knowledge_ts, raw_value, zscore_xs, universe_id, coverage_flag, is_backfilled, computed_at). Explain why this result is disqualifying on its face, then give the ordered checklist that finds the mechanism and the test that proves it. Deliverable: the verdict plus the query you would run first.
Approach
- State the disqualifying argument before investigating anything. A backtest over a frozen past window is a function of data fixed before the release. If the number moved, the data moved. No deployment can improve an estimate of history without rewriting history, so the only live questions are which rows changed and whether their new values were knowable at the time they are dated.
- Diff the panel rather than the metric. Compare row counts and value hashes per as_of_date against a pre-release snapshot. Rows whose zscore_xs changed for a past as_of_date are the population of interest, and is_backfilled should already flag them.
- Compare the distribution of knowledge_ts minus as_of_date before and after. A rerun that stamps knowledge_ts from its own computed_at, or that inherits the original row's knowledge_ts while recomputing raw_value from restated inputs, collapses that lag and admits restated fundamentals, revised index membership and retroactively applied split adjustments into dates that preceded them.
- Recompute IC restricted to is_backfilled = FALSE, and separately restricted to rows whose knowledge_ts lag matches the pre-release distribution. If the lift disappears under either restriction the mechanism is confirmed, and the size of the lift is the size of the leak.
- Turn the finding into an assertion the pipeline enforces: for any as_of_date, knowledge_ts must be at or after the observation time of the latest input, and must never decrease when a row is rewritten. That is a constraint code can check on every write, not a line in a review checklist.
Follow-up
- Which upstream vendor artefacts produce exactly this signature, and which of them would show up in raw_value rather than only in zscore_xs?
- The team argues the reruns fixed genuine bugs in past rows, so the new values are more correct. How do you answer that without conceding the backtest?
- What would you add to the research harness so a backtest physically cannot consume rewritten history?
Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and set a baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
- Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
- Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.
Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Worked solution ↗02One query pattern, written three times
- Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
- On the third attempt, write the grain of every CTE as a comment before writing its body.
- Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.
Deliverable: Three independent versions of the same query plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗03Only the statistics you will be asked to defend
- Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
- Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
- Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.
Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.
Practice prompt ↗Practice prompt ↗04One case, and the assumptions holding it up
- Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
- Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
- Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.
Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
- Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in a longer weekend block
- Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗Practice prompt ↗07Taper
- Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
- Re-read only your own notes from this week, and open no new material.
- Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
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.
Tell me about a time you made a mistake in a data analysis project. Ho…
Tell me about a time you made a mistake in a data analysis project. How did you identify the error, and what did you do to rectify it?
Approach
- 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.
- State the situation in two sentences and spend the rest on your reasoning.
Follow-up
- What did you decide not to do, and why?
- How did you know the outcome was caused by your change?
What are your favorite board games or card games, and what strategic p…
What are your favorite board games or card games, and what strategic principles do you apply when playing them?
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Close with what you would do differently, concretely.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Answering whether a six-week-old signal is working yet
A new signal has been live six weeks: 30 trading days of realized cross-sectional IC against a 5-day forward return, mean 0.030, standard deviation across days 0.12. An executive with no statistics background asks in a Monday meeting whether it is working and wants a yes or a no. You have the daily IC series and nothing else. Give an answer in three sentences plus one number the executive can hold onto, and say when the question becomes answerable.
Approach
- What is probed: whether you can be honest about statistical power without hiding behind the word significant and without giving a yes that gets quoted back at you in three months.
- Compute the interval before you speak. The standard error of the mean daily IC is 0.12 divided by the square root of 30, which is 0.022, so a mean of 0.030 sits about 1.4 standard errors from zero. That is the optimistic bound and it is already not a yes.
- Adjust for overlap and say that you did. A 5-day forward return sampled every day shares four of five days with its neighbour, so the honest standard error uses a Newey-West estimator with at least 4 lags and lands materially above 0.022. Presenting the naive figure without that caveat is the same error as the signal's own author would make.
- Convert power into a date rather than a verdict. Detecting a true mean IC of 0.03 at two standard errors needs roughly (2 x 0.12 / 0.03)^2 = 64 independent days, and with the overlap inflation of a 5-day horizon that is on the order of 300 trading days, so the question becomes answerable around fifteen months in, not six weeks.
- Give one number and one decision, because wait is useless on its own. Offer a tripwire that makes waiting active: a pre-committed stop if the trailing 60-day mean IC turns negative, and a named review date.
Follow-up
- Another desk called their signal working after four weeks. What do you say when the executive raises that?
- What single observation before the review date would make you stop the signal early?
- The six-week mean is minus 0.03 instead. Does your answer change in substance or only in sign?
- 01
Tell me about a time you made a mistake in a data analysis project. How did you identify the error, and what did you do to rectify it?
- 02
What are your favorite board games or card games, and what strategic principles do you apply when playing them?
- 03
A new signal has been live six weeks: 30 trading days of realized cross-sectional IC against a 5-day forward return, mean 0.030, standard deviation across days 0.12. An executive with no statistics background asks in a Monday meeting whether it is working and wants a yes or a no. You have the daily IC series and nothing else. Give an answer in three sentences plus one number the executive can hold onto, and say when the question becomes answerable.
Is this an official Susquehanna International Group interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Susquehanna International Group. Rounds and questions reflect what candidates have reported, not a process Susquehanna International Group has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Online Assessment, and how should I prepare for it?
The OA is notoriously difficult due to strict time limits (typically 17 questions in 60 minutes). The questions cover combinatorics, probability, and logic puzzles. To prepare, practice solving math competition-style problems and probability puzzles under timed conditions without using a calculator.
PracHub interview research ↗Does SIG require prior financial experience for the Data Scientist role?
No. SIG cares far more about your core mathematical talent, logical reasoning, and coding capabilities. They have an industry-leading internal training program that will teach you the necessary financial and option-pricing concepts once you join.
PracHub interview research ↗What is the culture like on the trading floor for Data Scientists?
The culture is highly meritocratic, collaborative, and fast-paced. There is very little hierarchy, and decisions are made based on data and logical merit. The environment is competitive but friendly, with a strong emphasis on continuous learning and game theory.
PracHub interview research ↗Where are the primary locations for this role, and is there a relocation requirement?
The primary global headquarters is in Bala Cynwyd, PA (just outside of Philadelphia). There are also offices in New York, Sydney, Dublin, and London. Depending on the desk, some roles may require you to spend your first year at the headquarters in Pennsylvania for training and integration.
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.