Hudson River Trading Coding: What to Expect

The Hudson River Trading coding interview for Core software engineers opens with a CodeSignal online assessment, then moves to human rounds. The assessment is a set of roughly four auto-graded problems, and the bar candidates chase is full AC, every hidden test passing, with speed as a tiebreaker. The problems are HRT's own, not stock LeetCode: stateful simulations, careful parsing, counting, geometry over points, and a data-structure design. Clear it and the loop turns to live algorithmic coding, a signature debugging round, and deep questions about C++ and the machine underneath it.

HRT's public reputation is a quant one: probability, statistics, market-making instincts. Almost none of that is on the software engineering loop. The firm hires into distinct roles with distinct interviews, and the single most expensive mistake here is preparing for the wrong one. So route yourself first. If you are interviewing for Core Development, the low-latency systems and infrastructure track that most software candidates want, your gate is the CodeSignal assessment and the C++ and systems rounds described below. If you are interviewing as an Algo Developer, HRT's quant-research seat, the loop front-loads a probability and statistics screen and leans on research judgment instead, and that is a different guide's territory. The prep barely overlaps, so confirm your track before you spend a week on the wrong surface.

The Hudson River Trading angle

HRT says out loud that it avoids "burst of insight" LeetCode, and it means it. The firm's own engineering writing is blunt that it strays away from puzzle problems that hinge on one clever trick, and that the top reason people fail is a shallow understanding of fundamentals. That single sentence reshapes how you prepare. The assessment rewards clean modeling and exact reading of a specification over a memorized pattern. The later rounds reward real command of C++ and the operating system beneath it over a catalog of solved problems. There is also no market-making game and no timed mental-math sprint anywhere on the software loop, so importing Jane Street or Optiver trader drills into your HRT prep buys you nothing. Study fundamentals until you can defend them. A memorized problem list won't survive these rounds.

How the coding loop runs

The first gate is a timed online assessment delivered on CodeSignal, the platform HRT's software pipeline settled on, though the label has rotated across cycles and older sittings show up under other names. It is roughly four problems, open-book in the sense that a language reference is allowed, and you may work in C++ or Python, with C++ the safe default for a Core seat. What decides it is not the visible checkmarks. Passing every case you can see does not guarantee you advance, because a set of hidden tests, along with your speed, is what sorts candidates. Input constraints are sized so that a brute-force solution times out, which quietly grades whether you reached for the right complexity rather than the first idea that compiled.

Clear the assessment and the loop turns human: roughly two phone interviews, then a full day of back-to-back onsite rounds that can run virtually or in person. One phone screen is a technical discussion across systems, data structures, and problem solving, and the other is a live programming round in the language you pick. The onsite is where HRT's real signal lives. Expect a dense algorithmic coding problem under time pressure. There is a technical design discussion pitched at trading systems and performance instead of boxes-and-arrows scaling, and a round that presses on C++ and OS internals. Then there is the round HRT is known for: a debugging session in an unfamiliar codebase. Behavioral signal is folded into these rounds rather than gated separately, and communication is weighted heavily, so thinking out loud is part of the grade.

The Hudson River Trading angle

The debugging round and the C++ depth are where a Core loop is really won or lost. Most candidates over-invest in the assessment and under-invest in the two rounds that best separate a strong systems engineer from a competent problem solver. The debugging round hands you code you did not write, sometimes on an HRT machine you connect into, and asks you to find and fix real bugs. It tests how you read an unfamiliar system, form a hypothesis, and confirm it. It does not measure how many problems you have memorized. The C++ and systems round goes under the hood: what happens when you call malloc, how a virtual class compiles, move semantics, templates, custom allocators, and how memory, I/O, and processes behave. Budget your preparation the way the loop does, and give the debugging and systems layer at least as much time as the coding drills.

The signature: bespoke problems you model, not memorize

HRT's coding problems do not come from a public problem bank, which is exactly why grinding a tagged problem list underprepares you. The problems are the firm's own, and they cluster into five recognizable archetypes. The signature is stateful simulation and parsing. One example is a one-line "mini vi" text editor that consumes a keystroke stream across command and insert modes and returns the final buffer. Another is a code-length calculator that strips line and block comments and counts what is left. Both reward exact state handling over any trick. The second is math and counting, from number-theory encodings to combinatorics. The third is geometry over a set of points, such as counting the axis-aligned squares or rectangles you can form from a coordinate list. The fourth is grid traversal, a BFS or DFS over a room with state, like escaping a space while avoiding guard sightlines. The fifth is design and data structures, such as a scalable hit counter extended with payloads and a disk-spill requirement when the data outgrows memory.

Marks come from correctness under the full hidden test set, the right algorithm for the stated constraints, and clean, idiomatic code. Edge-case initiative and clear communication count alongside the output. The visible examples are minimal by design, so you debug against your own reasoning instead of a green checkmark. The large inputs mean the naive approach fails on time even when it is correct. Each archetype gets worked end to end elsewhere in this section. One habit carries across all of them, and HRT keeps naming it. Understand the specification completely before you write, then model the state cleanly.

The lessons in this section

This section takes the Core software coding loop apart in order. The assessment comes first, then the bespoke problem families at its heart. Last come the two rounds that most often decide the onsite, debugging and C++ internals. Start with whichever sits furthest from your current strength.

Common questions