The short answer
The Tower Research Capital interview process commonly moves from an application and technical assessment to interviews with researchers, developers or members of the hiring trading team. Quant trading and research applicants face probability, Python, statistics and market reasoning; engineering applicants face algorithms, debugging and systems fundamentals.
One 2026 quantitative-research applicant reported a two-hour, in-person assessment. A 2025 Core Intern applicant reported a separate two-hour HackerRank test with 10 CS questions and three coding problems.
How the Tower Research Capital interview process works
Tower has dozens of independent trading teams supported by shared engineering and research infrastructure. That makes the interviews unusually sensitive to the specific desk and job. The strongest recent applicant accounts show a practical four-part progression:
- Application and shortlist. The recruiter or trading team reviews your academic, research and technical background. An experienced hire may begin with a recruiter or team conversation.
- Technical assessment. Quant candidates work through maths, probability, Python or coding problems; engineering candidates solve algorithm and computer-science tasks. Some assessments are taken in person.
- Technical interviews. Expect detailed questions with follow-ups from researchers or engineers. Your projects, code, statistics and reasoning are all fair game.
- Team or final-round interviews. Several conversations may be grouped into a final onsite, including deeper technical work and discussion with the people you would join.
Two 2026 quantitative-research applicants illustrate the pattern: a Paris report describes a two-hour assessment followed by two researcher interviews; a London report describes a proctored HackerRank assessment, video interviews and a final onsite. These are two specific recruitment experiences, not a promise that the order is identical for everyone.
Application, internships and team matching
Start by deciding whether you're applying for Quantitative Trader, Quantitative Researcher, Quantitative Developer or Software Engineer. Tower's official career material distinguishes research that finds trading signals from development that builds the research and execution systems. The same firm can therefore ask very different technical questions.
For 2027, Tower's internship listings include quantitative trader/researcher opportunities in London, New York and Chicago, researcher internships in Asia-Pacific offices including Sydney, quantitative developer internships, and US software engineering internships. London also lists a quantitative trader/researcher graduate programme. Its 2027 TACTIC intern programme is designed around rotations with two trading teams. These are useful programme names to match against your invitation; the role description is the best clue to your technical focus.
Make a single project easy to interrogate. For a research application, know the data, target, statistical assumptions and how you avoided look-ahead bias. For a developer, be ready to explain data structures, resource costs and a design decision you would change. For an experienced researcher, also prepare to discuss trading strategy work without disclosing confidential details from previous employers.
Tower Research Capital online assessment (OA)
HackerRank appears in both quant and engineering applicant reports. The assessment may be proctored at an office or campus, rather than sent as a link to complete at home. The practical difference is the subject matter: a quantitative role may mix mathematics and Python, while a software role can combine algorithmic coding, debugging and computer-science multiple-choice questions.
| Reported role / intake | Observed assessment | What to practise |
|---|---|---|
| Quantitative Researcher, London (Sept–Oct 2026) | One applicant described a two-hour in-person assessment with Python, maths/probability and problem-solving. Another described in-person, proctored HackerRank. | Python implementation; conditional probability, expected value, distributions and mathematical reasoning. |
| Core Intern, Post-Trade team (2025) | Two hours on HackerRank: 10 MCQs on OS, databases, networking, OOP and algorithms; three coding tasks involving dynamic programming, graphs and trees. | Two-hour contest practice with mixed coding and CS fundamentals. Test complexity and boundary cases. |
| Software Development Intern (candidate report) | Two-hour assessment: three difficult coding problems, one C++ debugging exercise and MCQs on time complexity, operating systems and networking. | Debug an unfamiliar C++ program; practise complex algorithms and predict the behaviour of real code. |
Observed formats: 2026 London research accounts, a named 2025 Core Intern interview account, and a Software Development Intern account on LeetCode. The last account has no verified public interview date.
What makes the OA hard?
For coding roles, the difference between a partial solution and a strong one is often whether it survives hidden cases and scales. In the 2025 Core Intern account, the algorithm section was described as medium-to-hard; the separate SDE Intern account described its three coding tasks as around LeetCode Hard. Review graph traversals, tree operations, dynamic programming, sorting and greedy invariants, then practise spotting overflow, invalid indices and time-limit problems.
For quant research, practise explaining the mathematics before starting to code. Be able to derive a conditional probability, turn the result into a short Python calculation and explain any modelling assumption. This closely matches the mix of mathematics and programming described in the London assessment.
Practice benchmark, not a Tower test specification: for quant research, try a 120-minute mock split into 40 minutes of probability and statistics, 55 minutes of Python, and 25 minutes of checking. For engineering, try three algorithm tasks and 10 CS fundamentals questions within 120 minutes, then review your wrong answers in detail.
Technical phone and video interviews
In quant interviews, the questions become less about selecting an answer and more about defending your reasoning. A September 2026 Quantitative Trader report describes an assessment on probability, coding and mental maths, followed by two technical discussions with researchers and a conversation with the team lead. Another 2026 trader described rounds on statistics, machine learning, market making and previous research work.
A natural progression is to start with a probability model, identify the distribution or expectation, and then explain how it would change if the assumptions were relaxed. For example, an interviewer might ask whether two apparently profitable signals really carry independent information, or whether a backtest survives costs and time-based validation. Practise arriving at a clear answer without losing track of what is being conditioned on.
Quant Developer and engineering interviews can go deep into implementation. A March 2026 Quant Developer candidate described an OA plus four video technical rounds, covering Python, data processing, storage, OOP, TCP versus UDP and later live coding. A different September 2026 Quant Developer report describes two virtual rounds mixing probability and algorithms. These are useful examples of what each team chooses to probe.
For software candidates, one detailed 2025 Core Intern experience covered custom data structures, graphs, Java string equality, object-oriented design, database sharding and designing a file system. In a separate SDE Intern account, the first interview combined a medium coding question with operating-system fundamentals and C++ STL internals. Being able to explain why your code works matters as much as writing it.
Onsite and final-round interviews
The last stage is often a series of technical conversations with the group you might join. An October 2026 Quantitative Researcher described three individual calls followed by four back-to-back onsite technical interviews. A September 2026 Quantitative Trader described several virtual rounds followed by a similar set of onsite discussions. These reports are a better reason to expect depth than to memorise an exact number of rounds.
For research and trading, expect follow-up questions about your models: how you formed a hypothesis, what a negative result taught you, whether a result was robust to regime changes, and how execution would affect the economics. For development, prepare to walk through unfamiliar code, justify memory or concurrency choices and redesign a component when the interviewer adds requirements.
Bring one technical project you can explain from first principles. Know its failure cases and trade-offs. Tower describes its own hiring philosophy as a practical conversation about what you have done and can achieve, and this is where specific details from your own work become valuable.
Interview questions by Tower Research Capital role
Select the track closest to the vacancy. These role descriptions follow Tower's actual quantitative trading and engineering functions, together with the technical topics described in recent applicant interviews.
Quantitative Trader: decisions, probability and market making
Recent trader reports mention mental arithmetic, probability, statistics, machine learning and market making. Practise converting a prediction into a trade: compute expected value after spread and fees, explain how inventory changes the quote you would post, and identify when a signal is too weak to trade.
A useful interview drill is to price a binary payoff, update the price after receiving a noisy signal, and then quote a bid and ask with an inventory limit. Explain both the probability calculation and the cost of being wrong. Market-making games are a good next step once the maths is comfortable.
Quantitative Researcher: statistical evidence and Python
London research accounts report a mix of Python, maths and problem-solving. Prepare conditional probability, expectation, distribution reasoning, regression, model evaluation and short coding tasks. Your answers should connect the statistical model to how you would test it on time-ordered data.
Pick one research project and explain the labels, train/validation split, leakage controls, transaction costs and stability across periods. A strong follow-up answer often explains why a striking in-sample result might vanish out of sample. Practise deriving an expression and checking it with a small simulation.
Quantitative Developer: algorithms plus trading infrastructure
Quant Developer interviews reported in 2026 mix problem-solving with Python internals, data storage, object-oriented design and sometimes probability. Be able to compare a Python list, tuple and array; reason about time and memory; and explain TCP versus UDP when market-data messages arrive late or out of order.
Practise implementing a bounded event buffer that detects gaps in sequence numbers, or a rolling statistic that updates without rescanning the full history. Then explain the failure mode when the stream contains duplicates, dropped packets or a restart. For low-latency C++ positions, add object lifetime, ownership and concurrency.
Software Engineer and Core Engineering: coding, debugging and systems
The clearest engineering reports include dynamic programming, graphs and trees; C++ debugging; complexity questions; networking and operating systems; and deeper project/design discussion. One 2025 Post-Trade candidate was asked about Java equality, database scaling and a file-system class design.
Write your solution, test it on small examples, give its complexity, then discuss the data structure you deliberately chose not to use. For C++, trace ownership and invalidation; for Java, explain equality and object behaviour; for backend systems, discuss sharding, idempotence and concurrency. Start with programming interview practice rather than treating a systems job as a mental-maths contest.
Tower Research Capital-style questions with solutions
These are original EverythingQuant practice exercises chosen for the relevant skills, not claimed verbatim past Tower questions. The coding example adapts a problem family described in a named 2025 Core Intern interview account.
1. Probability: hitting an asymmetric price barrier
A price starts at zero. Each tick changes it by +1 or −1 with equal probability, independently. Trading stops when the price first reaches +3 or −2. What is the probability it reaches +3 first, and the expected number of ticks until it stops?
Show solution
Write p for the chance of reaching +3 first. Because the price is a fair random walk, its expected value at the stopping time is the starting value, zero: 3p − 2(1 − p) = 0. Therefore p = 2/5.
For a fair walk, the expected increase in squared position per tick is one. The expected stopping time is therefore the expected squared terminal position: E[T] = 9(2/5) + 4(3/5) = 6 ticks. This is also the gambler's ruin result (0 − (−2))(3 − 0) = 6.
Follow-up: If upward moves are slightly more likely, the exit probability changes and neither fair-walk shortcut is valid without modification. Set up the state recurrence instead.
2. Research and trading: does a signal have positive value?
A stock has a 30% chance of rising next interval. Your model emits BUY on 70% of up intervals and 20% of down intervals. Conditional on the true direction, a buy earns +$0.03 if it rises and loses $0.04 if it falls. Trading costs $0.004. After BUY appears, is entering the position profitable in expectation?
Show solution
By Bayes' rule, P(up | BUY) = (0.70 × 0.30) / [(0.70 × 0.30) + (0.20 × 0.70)] = 0.60.
The expected net profit is 0.60 × $0.03 − 0.40 × $0.04 − $0.004 = −$0.002. The model has a useful-looking 70% hit rate when the price rises, but the trade still has a negative expected return after losses and costs.
Follow-up: Ask what happens if the signal changes the price you can actually execute at. A prediction is not a trading strategy until execution and costs are included.
3. Coding: smallest sum that cannot be formed
Given a list of positive integers, each usable at most once, return the smallest positive integer that cannot be made by summing a subset. For [1, 1, 3, 8], the answer is 6. Aim for better than exploring every subset.
Show Python solution
After sorting, let missing be the smallest value not yet representable. Initially it is 1. If the next value is no greater than missing, it extends the contiguous range of sums we can build. Otherwise the gap at missing cannot be filled.
def smallest_missing_sum(values):
missing = 1
for value in sorted(values):
if value > missing:
break
missing += value
return missing
assert smallest_missing_sum([1, 1, 3, 8]) == 6
assert smallest_missing_sum([1, 2, 3, 4]) == 11
assert smallest_missing_sum([2, 3, 4]) == 1
assert smallest_missing_sum([]) == 1Sorting costs O(n log n) time; the scan is O(n). The proof is the invariant: before processing the next item, all integers from 1 through missing − 1 are achievable. A 2025 Core Intern report describes a related greedy subset-sum question in a technical round.
4. Systems: TCP or UDP for market data?
You need to receive a fast sequence of market-data updates, each with a sequence number. Compare TCP and UDP. If you use UDP and receive messages numbered 104, 105 and 107, what should the receiver do?
Show solution
TCP provides a reliable, ordered byte stream, but delivery can stall behind missing data. UDP delivers datagrams with no built-in delivery or order guarantee; the application must handle gaps and duplicates. Receiving 107 after 105 reveals a missing 106.
A robust receiver tracks the expected sequence number, flags the gap, and follows its feed protocol's recovery mechanism, such as a retransmission or snapshot. It should not silently assume that message 106 never mattered. Discuss how you would buffer later updates and resume without corrupting state.
A March 2026 Quant Developer interview report specifically mentions TCP versus UDP among the technical topics; this scenario and answer are EQ's own practice exercise.
How difficult is the Tower Research interview?
Expect a demanding technical interview. The toughest engineering reports combine multiple algorithm problems with debugging and theory under time pressure. The more challenging quant rounds ask you to move between mathematical reasoning, coding and applied judgement while explaining the same idea to different researchers.
The useful standard is not the number of puzzles you've memorised. Can you derive a probability, explain why the result is reasonable, implement the key part correctly, and defend the assumptions when the interviewer changes one? For engineering, can you find a bug, prove the complexity and discuss the real system around the algorithm?
Tower's own careers page emphasises thoughtful, practical conversations rather than trick questions. The first-hand reports still show substantial technical depth. Prepare to reason clearly, not to perform a rehearsed script.
How to prepare for Tower Research Capital interviews
Build your preparation around the next stage and the job title. Use these four tasks as a focused plan rather than working through every possible quant interview topic.
- Recreate the assessment conditions. For engineering, practise a two-hour session of three coding problems and 10 CS questions; add a timed C++ debugging task if the role involves C++. For research, use the maths-and-Python mock described above. These are practice drills built from reported question families.
- Go deeper on the role's fundamentals. Quant traders should price decisions after fees and handle conditional signals. Researchers should revisit statistical validation and simulation. Quant developers should understand data structures and data-feed behaviour. Engineers should debug real code and explain systems design.
- Run one spoken mock interview. Spend 45–60 minutes solving a mathematical or coding problem aloud. Have someone change the assumptions halfway through. Explain what you would test before calling the solution finished.
- Rehearse a technical project discussion. Walk through one substantial project, the problem it solved, the hard engineering or statistical choice, an actual failure and what you learned. Experienced candidates should use non-confidential detail.
Probability & research
Probability for Quants moves from conditional probability and expectations into stochastic and research problems.
Market decisions
Market Games helps practise quoting, fair value and making decisions under uncertainty.
Programming & systems
Use coding interview problems and the DSA course to strengthen algorithms before timed mocks.
Tower Research Capital interview FAQs
Does Tower Research Capital use HackerRank?
Yes. HackerRank appears in a named 2025 Core Intern interview account and a 2026 London Quantitative Researcher report. A London applicant described taking the assessment in person under supervision.
Is the Tower Research online assessment two hours long?
Two hours is the reported duration for a 2026 London Quantitative Researcher assessment and a 2025 Core Intern assessment. The question mix was different: maths and Python for the former, 10 CS MCQs and three coding problems for the latter.
What questions are asked in Tower quantitative trading interviews?
2026 trader candidates reported probability, mental maths, statistics, machine learning, coding and market-making discussions. Practise computing an expectation after new information, then explaining the trading decision after fees and inventory risk.
Can I interview in Python or C++?
Both are relevant at Tower. The firm's internships material names Python and C++ as core languages; its engineering systems also use Rust. One SDE Intern applicant specifically reported a debugging section requiring C++, so practise in the language stated in your invitation.
What if I'm applying to Limestone or another Tower trading team?
Limestone is a Tower trading group. Expect your discussion to reflect the team, not just the corporate name. A 2023 Limestone internship account described an OS/networking and competitive-programming test, then two technical rounds on probability, statistics and data structures. Use the older report as a preparation clue, while prioritising the current team and job description.
How long does the Tower Research interview process take?
One October 2026 London Quantitative Researcher candidate reported around four weeks; a Paris candidate interviewed in June 2026 reported a two-month process. Allow time for multiple technical interviews and possible onsite scheduling.
Do I need a finance degree or trading experience?
No finance degree is necessary for many early-career roles. Tower's internships FAQ explicitly welcomes candidates with backgrounds such as maths, physics, computer science and engineering. For an experienced trading position, the technical experience of the team will matter more.
Sources and editorial notes
Interview details are drawn from Tower's careers information, its internship and role descriptions, dated 2026 candidate interviews, a 2025 firsthand Core Intern account, and a SDE Intern report. The worked problems here are EQ practice, not reconstructed confidential assessment questions.