Hudson River Trading OA Experience: Two Trading-Style Coding Questions Breakdown

I recently completed the online assessment for Hudson River Trading (HRT), and my biggest takeaway was this: the questions themselves were not impossible, but the time pressure was very real.

A lot of people assume HRT OAs are purely math-heavy or probability-focused, but my assessment was much more centered around coding implementation, algorithm efficiency, and handling edge cases under pressure. The problems still had a clear trading-firm flavor, but this round felt closer to strong engineering execution than pure quant math.

OA Timeline

I received the OA roughly one week after submitting my application. The platform was straightforward:

• Problem statement
• Built-in coding editor
• Custom test execution
• Final submission

Compared with firms like Jane Street or Citadel that sometimes include probability games, brain teasers, or mental math rounds early in the process, HRT felt much more direct—open the assessment and start coding immediately.

Question 1: Order Matching Engine Simulation

The first problem was heavily inspired by trading systems.

You were given a stream of buy and sell orders with:

• Price
• Quantity
• Timestamp
• Order type

The task was to simulate an order matching engine:

• Buy orders match the lowest sell price first
• Sell orders match the highest buy price first
• If prices are equal, earlier timestamps have priority
• Return all remaining unmatched orders

Example input looked similar to:

buy 100 5
buy 101 3
sell 100 4
sell 99 2

At first glance, this looked like a basic heap problem, but the real difficulty came from implementation details:

• Partial fills
• Duplicate price handling
• Timestamp ordering
• Edge-case-heavy logic

I initially used sorted containers but quickly realized performance issues would appear on larger test cases.

The better approach was:

• Max heap for buy orders
• Min heap for sell orders
• Immediate matching on every new order

Overall complexity: O(n log n)

Question 2: Market Signal Profit Optimization

The second problem felt like a dynamic programming variation of stock trading problems.

You were given an array of market signals:

[4,2,8,1,6,9...]

You could perform a limited number of operations to maximize total profit under several constraints:

• Cooldown periods
• Transaction limits
• Switching costs

This felt harder than standard stock-buy-sell interview questions because multiple constraints interacted at the same time.

My initial greedy solution passed sample tests but failed hidden cases.

I eventually switched to a DP solution using states like:

dp[i][k][state]

Where state represented:

• Holding position
• Not holding
• Cooldown state

That ended up solving the hidden test failures.

What Made It Difficult?

The hardest part of the HRT OA wasn’t algorithm difficulty—it was speed.

• Fast implementation
• Debugging under time pressure
• Managing hidden edge cases
• Writing optimized code quickly

I spent nearly half the total time on question one alone, which made the second question much more stressful.

How It Compares to Other Trading Firms

Jane Street: More probability-heavy and game-focused

Citadel: More mixed between math and coding

HRT: Stronger emphasis on implementation quality

If you only practice standard LeetCode interview questions, HRT problems may feel unfamiliar because of their trading-system context.

Preparation Tips

I’d strongly recommend practicing:

• Heap simulations
• Order book problems
• Stock DP variations
• Binary search optimization
• Probability fundamentals

Reading interview experiences from HRT, Jane Street, Citadel, and Two Sigma can also help you recognize recurring patterns.

Final Thoughts

For trading firms like HRT, the OA is only the beginning. Later rounds may include:

• Technical interviews
• Probability rounds
• Low-latency systems discussions
• Behavioral interviews

The biggest lesson from this OA: the problems may look manageable, but execution speed matters a lot more than most candidates expect.