Hudson River Trading Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about HRT. They hire a brain, not a checklist.

• A huge share of trading volume on major exchanges flows through firms like this, and the edge is tiny and technical.
• They care more about how your brain moves than whether you've seen the exact problem.
• The AD role sits between software engineering and research.
• You will touch the actual trading systems, not a sandbox two layers removed from money.

2Getting the call (the part most guides skip)#

HRT reads resumes with real human eyes, especially for new grads from target CS programs and competitive-programming backgrounds. The fastest door is still a referral.

• A referral gets your resume actually opened instead of pattern-matched.
• At a firm this small (low thousands total, far fewer ADs), an internal vouch carries real weight.
• If you know anyone inside, ask. That is the single highest-leverage move before you touch LeetCode.

No connection? Two things move the needle.

• Competitive programming rating is basically a cheat code. Codeforces north of 1900, an ICPC regional or World Finals appearance, USACO Platinum, a top-few-hundred Putnam score. Put it top line, with the real number.
• "Codeforces Candidate Master, max rating 2043" beats "strong at competitive programming."
• A systems project reads louder than another CRUD app. A toy exchange, a tiny matching engine with price-time priority, a latency benchmark that reports real microsecond numbers.

Your bullets should be numbers, not adjectives. Weak: "Optimized a data pipeline for performance." Strong:

Cut p99 latency of a market-data parser from 840us to 110us by replacing heap allocation with a preallocated ring buffer, measured over 2B messages.

Why that bullet works:

• A specific technique, a specific result, and the scale it was measured at.
• It survives a skim and invites a good follow-up instead of a shrug.
• When a reviewer scans your resume, they want exactly one thing: proof you made something fast or correct and can tell them how.

ATS keywords worth having if they're true: C++, data structures, algorithms, low latency, concurrency, Linux, Python, competitive programming, probability, systems.

• Don't keyword-stuff. HRT recruiters are technical enough to notice.
• A wall of buzzwords with no numbers behind them reads as padding.

3The loop at a glance#

Read the table, then read the fine print.

• Exact mix varies by office and level.
• New grads tend to get more probability and games. Experienced folks get more systems and C++.
• The onsite is usually a single day, often virtual, back-to-back rounds with a short break, so stamina matters.
• By round five your brain is tired, and that is when sloppy arithmetic creeps in. Plan for it.

4The coding or technical rounds#

The coding bar is high but not exotic. They reuse the classic families.

• Arrays and two pointers, sliding window.
• Hash maps for counting and grouping.
• Stacks and monotonic stacks (lots of "next greater element" flavored problems).
• Binary search, including binary search on the answer.
• Heaps and priority queues (top-k, merge-k, streaming medians).
• Graphs: BFS, DFS, topological sort, shortest path.
• Dynamic programming, usually one meaty one.
• Intervals, sorting, and greedy.

Difficulty and the clock.

• Roughly LeetCode medium with a few hards.
• The clock is tighter than a normal tech company, and they expect clean code, not a mess you eventually patch into working.
• On the OA, 2 to 4 problems in 60 to 90 minutes means you cannot afford to stall.
• Spend 25 minutes on problem one and you lose. Budget time per problem up front and skip forward if one is fighting you.

How you actually win the round. This is what passes and fails people.

• Clarify first. Spend 60 seconds restating the problem and asking about input size and edge cases. Input size is not small talk, it tells you the target complexity. If n can be a million, your O(n^2) idea is dead before you write it.
• Talk while you think. The graded thing is your reasoning, not the final answer. "This is O(n log n) because of the sort, and I think I can get it to O(n) with a hash map, let me try." That one sentence moves you up a bucket.
• State complexity before you're asked. Time and space, every time. Skip it and the interviewer assumes you don't track it. In a hot loop that runs billions of times a day, someone who ignores cost is a real risk.
• Test your own code. Walk a small example by hand, then an edge case: empty input, a single element, all duplicates, the boundary of your binary search. Finding your own bug looks senior. Declaring "done" on code that crashes on empty input hands over a clean reason to say no.

For practice: do timed sets. Two mediums in 40 minutes, no IDE autocomplete, talk the whole time even alone.

If you claim C++, know the real stuff.

• References vs values and when a copy sneaks in.
• Move semantics and what std::move actually does.
• Where cache misses come from.
• Why std::vector beats std::list almost always: contiguous memory, prefetching, no per-node allocation.

5The probability, puzzles, and market-making round#

This is the round that separates HRT from a normal software company, so give it real prep.

Probability topics that come up again and again.

• Expected value. Dice, coins, cards, "expected number of flips until two heads in a row." The answer to that one is 6, and knowing why, via a two-state recursion, is the kind of thing they want built live.
• Conditional probability and Bayes. Classic: given a positive test, what's the real probability you're sick. The trap is the base rate. A 99% accurate test for a 1-in-10000 disease still leaves you far more likely healthy than sick. They want you reaching for base rates, not panic.
• Combinatorics. Counting arrangements, birthday-paradox style problems (23 people, better-than-even odds two share a birthday, and the intuition for why it's that low).
• Linearity of expectation. The single highest-leverage trick. Add expectations even when events depend on each other. Expected fixed points in a random permutation is exactly 1, and you get there by summing indicator variables without touching the messy dependence.
• Random walks and gambler's ruin.
• Simple game theory and fair-value pricing.

A framework you can actually use live.

1. Define the random variable in one sentence. "Let X be the number of rolls until I see a 6."
2. Decide if there's structure: independence, symmetry, a recursion, or linearity of expectation.
3. Set up the equation before plugging numbers. For expected-value-until-event, a one-line recursion usually falls out: E = 1 + (prob of not done) times E. For the single die, E = 1 + (5/6)E gives E = 6, and saying that out loud is worth more than the 6.
4. Sanity check the magnitude. "Expected 0.3 flips" for something that needs at least one flip means you slipped. A probability above 1 or negative means stop and find the error before you say the number.

The market-making game is interactive, and it rattles people the first time.

• The interviewer invents a quantity (number of windows in a building, sum of two hidden dice) and you quote a bid and an ask.
• You trade against them, they update, you update.
• What they watch: do you set a sensible spread given your uncertainty, do you tighten it as you learn, do you manage your position instead of chasing, do you stay calm when a trade goes against you.

Two concrete mistakes sink people here.

• Quoting a spread that stays wide forever even as you gather information, which looks like you can't learn.
• Ignoring that the interviewer's willingness to trade is itself a signal. If they keep lifting your offer, your number is probably too low, so move it.

You don't need to win. You need to reason coherently about uncertainty and edge. Narrate it: "I'm uncertain, so I'll quote wide, 40 bid at 60. If you lift my offer, that's information, I'll move up, 50 bid at 65."

Mental math.

• Practice 2-digit multiplication, percentages, and fractions-to-decimals in your head, plus quick estimation (piano tuners in Chicago, eggs eaten in the US per day).
• Zetamac set to addition, subtraction, multiplication, and division is the standard drill. Aim for 40+ correct in two minutes and you'll feel calm under pressure.
• Speed and composure matter more than perfection. A fast approximate answer with a stated error bar beats a slow exact one.

6Behavioral and culture fit#

HRT's culture is genuinely nerdy in the good way. The values show up in how they interview.

• Deep intellectual curiosity.
• A flat, collaborative environment with no thick management layer between you and the code that moves money.
• Intellectual honesty. They love "I was wrong, here's what I learned."
• A strong allergy to ego and politics.
• They work in small teams and they ship. They want people who get excited about a hard problem for its own sake, the kind who would still tinker with the puzzle after the interview ended.

Prepare 4 or 5 STAR stories: a hard technical problem, a time you were wrong, a conflict you resolved, and a project you drove. Always end with a number. "It got better" is forgettable. "Error rate fell from 4% to 0.3%" is not.

One worked example.

• Situation: Our backtest and live results for a signal were diverging by a frustrating margin and nobody could explain why.
• Task: I owned the data layer, so I took finding the cause.
• Action: Instead of guessing, I built a replay that fed the exact same historical ticks into both paths and diffed the output message by message. I found we were using the exchange-receive timestamp in backtest but the local-receive timestamp live, a gap that averaged 1.3ms and poisoned the signal at open.
• Result: After aligning the timestamps, backtest-to-live tracking error dropped by about 70%, and we caught two other code paths with the same bug before they hit production.

Why that story lands. It ends on a number and shows honesty plus method: a measurement, not a guess, and a fix that generalized. If your story is "I had a hunch and it worked out," rewrite it so the method does the work.

7Your prep plan#

4-week plan.

• Week 1: DSA foundations. 5 problems a day across arrays, hashing, two pointers, stacks. Timed.
• Week 2: Graphs, DP, heaps, binary search on the answer. Keep timing yourself.
• Week 3: Probability and brain-teasers daily. Work a problem book, drill expected value, Bayes, linearity of expectation. Mental math reps every morning on Zetamac.
• Week 4: Full mock loops. One coding, one probability, one market-making game with a friend. Polish STAR stories. Rest the day before.

2-week plan.

• Days 1 to 5: timed mediums, 3 a day, all the core patterns.
• Days 6 to 9: probability + mental math + one DP hard a day.
• Days 10 to 12: market-making game practice and brain-teasers.
• Days 13 to 14: mocks and STAR stories.

2-day crash plan.

• Day 1: 10 timed mediums across patterns. Review the ones you missed instead of just moving on, because the pattern you skip is the one they'll ask. Two hours of expected value and Bayes.
• Day 2: Mental math reps, one market-making game walkthrough, write 3 STAR stories, sleep. A rested brain does mental math faster than a crammed one.

8Why people get rejected at HRT#

Every one of these is avoidable, and each maps to a value they screen for.

• Coding in silence. If the interviewer can't hear your reasoning, they can't pass you, even if the code works. They are hiring the thinking, and silence hides it.
• Guessing on probability. Blurting a number without setting up the model reads as "memorized, doesn't understand." A right number with no derivation scores worse than a wrong number with clean reasoning.
• Claiming C++ depth you don't have. One follow-up about move semantics or cache behavior and the bluff is obvious.
• Freezing in the market-making game. Panicking or going silent kills it. Narrate, even badly. A messy out-loud process beats a confident blank stare.
• No edge-case testing. Code that crashes on empty input after you said "done" is a real ding.
• Ego. Arguing with the interviewer, or being unable to say "I don't know." HRT specifically filters for intellectual honesty, and digging in on a wrong answer after a hint is a fast way out.

A wrong number with clean reasoning beats a right number you can't explain.

9The offer, comp and negotiation#

Realistic ranges, all-in and region-dependent.

• US new grad: roughly 250k to 450k+ total comp, base plus a large bonus and sometimes a signing bonus. Experienced hires go well past that. The headline swings hard on the bonus, which is performance and firm driven, so two new grads with the same base can land far apart.
• London: often 120k to 200k+ GBP base with a meaningful bonus on top.
• India/APAC: smaller office footprint, strong-for-region packages, commonly 60L to 1Cr+ INR for strong new grads, very dependent on level and team.
• Canada: largely tracks the US pipeline.

Negotiation tips specific to HRT.

1. Competing offers are your strongest lever. HRT competes directly with Jane Street, Citadel, Two Sigma, and HFT peers, and they know the market rate down to the last 10k. A real competing offer moves numbers. A vague "I've heard others pay more" does not.
2. Negotiate total comp and bonus structure, not just base. At trading firms the bonus is where the real money lives. Get clarity on how it's determined, the guaranteed year-one portion, and what a typical and a strong year look like in dollars. A high base with a mushy bonus can be worth less than the reverse.
3. Be straightforward and low-ego about it. State what you'd need to sign, give your reasoning, and don't play games or invent fake deadlines. The same intellectual honesty they grade in the loop applies when you negotiate. They respect a clean, honest ask more than theatrics.

If you want, map these rounds onto your actual calendar and build a dated, week-by-week plan around your interview date so nothing gets left to the last night.