Hudson River Trading Software Engineer Interview: Every Round, Decoded

Most candidates walk into an HRT loop prepped for FAANG. They've grinded 150+ LeetCode problems, done a system design pass, and feel ready. The phone screen happens. Suddenly someone is asking them to explain virtual function dispatch and memory layout with class hierarchies, and their prep starts to feel a lot like bringing a rubber duck to a knife fight.

Hudson River Trading is a quant firm, not a product company. Founded in 2002, they trade equities, futures, options, and currencies across 100+ markets. In 2014, they accounted for roughly 5% of all US trading volume. The code driving that has to work correctly at microsecond latency. That changes what they hire for.

HRT's stated philosophy: "We want engineers with strong fundamentals but stay away from obscura and tricks." That's not marketing copy. It means they'll keep pulling on a thread until they find where your understanding actually stops. Pattern-matching your way through LeetCode is not sufficient prep here.

Trading Tech vs. R&D: Pick Your Track First

HRT splits engineering into two divisions, and your prep changes depending on which you target.

Trading Tech builds and maintains live trading infrastructure. Roughly 70% C++, 30% Python. The constraint is latency. Research and Development handles data pipelines, storage systems, and researcher tooling. About 70% Python, 30% C++. The constraint is scale.

Both divisions hold the same technical bar. C++ candidates face hard questions on memory layout, move semantics, and cache behavior. Python candidates still need systems knowledge, just with less hardware specificity.

Decide which track you're targeting before you start prepping, because the prep is meaningfully different. Trying to prepare for both at once is a great way to prepare adequately for neither.

The Interview Pipeline

Stage	Format	Length	Focus
Online Assessment	CodeSignal	60-90 min	DSA, 3 coding problems
Phone Screen(s)	Video call, 1-2 rounds	45-60 min each	Coding + systems/probability
Onsite	Virtual or in-person	Half-day, 3-5 rounds	Coding, systems, behavior

The total process runs 4-8 weeks from OA to offer. Your recruiter briefs you before each stage. That briefing is real. Use it.

Stage 1: Online Assessment

Three problems via CodeSignal. Difficulty is roughly easy to medium. This stage filters for baseline coding competence, not brilliance.

Write clean, efficient code, and optimize wherever the opportunity is obvious. It's timed. If LeetCode mediums under a clock are still uncomfortable, fix that before applying. This is the floor, not the ceiling.

Stage 2: The Phone Screen That Surprises Everyone

This is where the FAANG-prepped candidate runs into a wall. A FAANG phone screen is a LeetCode medium with light follow-up. The HRT version adds two things: systems questions and probability. Most candidates have prepared for neither, because nobody told them to.

For the C++ track, the systems bar activates at the phone screen, not the onsite. Interviewers will probe virtual function dispatch, memory layout with inheritance, move semantics, and cache behavior in the first call. "I can write C++" is not sufficient. You need to know what the compiler produces and what happens at the CPU.

There's a meaningful difference between writing C++ and understanding C++. HRT's interviewers live on the side of the street where that gap is visible from a mile away.

Python is versatile. Java is robust. C++ is... C++.

Every other language gets a flattering adjective. C++ is just C++. HRT will ask you to explain exactly why that is.

For Python candidates, systems fluency still matters. The GIL, reference counting, garbage collection, Python's object model and its costs. Less depth than the C++ path, but not optional.

Then there's probability. Expect expected value problems, conditional probability setups, and intuitive explanations of the central limit theorem. The goal is not formula recall. It's whether you can build a solution from first principles and sanity-check that the answer makes intuitive sense. Most SWE candidates skip this prep entirely because "I'm not applying for a quant role." That framing is wrong. Probability appears across the entire loop.

Stage 3: The Onsite

Three to five rounds in a single day. One bad round typically ends things. There is no averaging.

Coding

LeetCode medium to hard. HRT explicitly avoids "burst of insight" problems, so you won't get ambushed by a trick you either know or don't. The point is watching you reason through something real.

The conversation after a working solution is where candidates actually separate. Interviewers ask why you chose a deque instead of an array, whether the memory layout of that choice is cache-friendly, and what the performance tradeoff looks like in practice. Getting to correct is the entry ticket. The conversation that follows is what differentiates.

Graphs, dynamic programming, and standard data structure problems all appear. Nothing exotic. The bar is high because HRT engineers are strong, not because the problems are trick-laden.

Systems and Low-Level (C++ Track)

This is HRT's signature round and the one that trips up the most people. It does not look like a FAANG system design round. It goes much further down the stack, all the way to the point where you're expected to have opinions about what the CPU is doing.

Topics that appear regularly:

Memory layout with class hierarchies and virtual dispatch
Move semantics, copy elision, and when the compiler generates each
Cache lines, false sharing, spatial vs. temporal locality
Lock-free data structures and atomic operations
C++ memory ordering semantics (acquire, release, seq_cst, and why each exists)

Interviewers will ask you to implement something and then probe whether you understand the performance characteristics of what you just wrote. "It's O(n)" is not enough. "It's O(n) but the cache miss pattern looks like this" is the answer.

You need a mental model that runs from source code down to hardware execution. If you haven't worked through CS:APP (Computer Systems: A Programmer's Perspective) or equivalent, you're missing the foundation this round assumes. Go read it. Genuinely.

Probability

Probability shows up across the loop, not just in a dedicated round. Common territory: expected value problems across multiple stages, order statistics (given n random draws, what is the expected maximum?), Bayes' theorem applied to a real scenario, and intuitive explanations of the central limit theorem and law of large numbers.

Practice building from first principles rather than jumping to a formula, and always sanity-check against a simple case. "Does this answer make sense at the extremes?" is a question they'll expect you to ask yourself.

Behavioral

HRT cares about teachability more explicitly than most firms. The signal they watch for: do you apply feedback within the same session?

If an interviewer suggests a better approach mid-problem, do you incorporate it or keep pushing your original direction? Candidates who use earlier discussion to inform later answers stand out as engineers who actually learn on the job. Arguing with feedback is documented as a failure mode in HRT's own post-mortems. Not "documented as a concern." Documented as a failure mode.

HRT vs. Big Tech: Different, Not Just Harder

Strong FAANG prep (150+ LeetCode problems, one system design pass) gets you through the OA and maybe the phone screen. It does not get you through the onsite.

Skills needed to get a job: skills to do the job vs. interview skills

This chart is unfair everywhere, but at HRT the interview skills bar is also measuring hardware knowledge, probability, and whether you know what your compiler emits.

The candidates who struggle here are usually overfit on pattern recognition and underinvested in understanding what computers actually do. The acceptance rate is roughly 1-2%. That's not because the problems are obscure. It's because the genuine fundamentals bar is high and most candidates' fundamentals are shallower than their resumes suggest.

This isn't a dig. It's an accurate diagnosis. The prep for HRT is a different shape than the prep for most big tech loops. Both require solving algorithmic problems. One additionally requires that you know why your solution performs the way it does, at the hardware level, with numbers to back it up.

Prep Strategy

C++ track:

Work through "Effective Modern C++" by Scott Meyers, items 1-42 minimum. Focus on move semantics, perfect forwarding, and copy elision.
Read the memory and caching chapters of CS:APP. This gives you the hardware model the interview assumes.
Implement a lock-free queue and a simple memory pool allocator. Analyze cache behavior and thread safety for each.
Solve 50+ LeetCode mediums with a timer. Focus on graphs and DP. Practice narrating your approach out loud.
Work through probability puzzles from "Fifty Challenging Problems in Probability" by Frederick Mosteller.

Python track:

Understand CPython well enough to discuss the GIL, reference counting, garbage collection, and the memory layout of Python objects.
Same 50+ LeetCode medium target.
Same probability baseline.

Both tracks: the silent-but-correct coder is a weaker signal at HRT than the communicative engineer who thinks out loud. Voice-based mock interviews on SpaceComplexity give you rubric-based feedback on where your narration breaks down before the onsite does.

Timeline

4-6 weeks if you're currently working in C++ or systems code and have interviewed elsewhere recently. Spend most of this time on probability and deepening the low-level C++ layer.

6-8 weeks if you have solid DSA fundamentals but haven't touched systems programming deeply. Budget half this time on CS:APP and C++ internals, the rest on DSA and probability.

10-12 weeks if there's a real gap in your systems knowledge or you haven't written C++ professionally. Both the probability and the systems depth take genuine time to build. Don't rush it.

What Gets Candidates Cut

Treating this like a FAANG loop. The DSA overlap is real, but the systems depth required is different enough that FAANG-only prep leaves a large gap. You'll feel it the second the interviewer asks about cache behavior.

Shallow C++ knowledge. Writing C++ and understanding C++ are different. If you can't explain what the compiler does when you pass a vector by value, you're not ready for the C++ track. Practice that explanation on your next-door neighbor. If they're confused, you might be too.

Skipping probability prep. SWE candidates consistently underprepare here because "I'm not applying for a quant role." That framing is wrong. Probability appears across the interview. Budget real time for it.

Diving in before clarifying. HRT lists this as an explicit failure mode. Spend the first few minutes understanding the problem before writing a single line. Restating the problem, confirming constraints, asking about edge cases. It's not stalling. It's what good engineers do.

Arguing with feedback. Hint responsiveness is a scored signal. See also: how to handle hints in a coding interview.

For more on what interviewers actually score during a loop, see what interviewers look for in coding interviews and how to think out loud.