← Hudson River Trading Interview Insights

Hudson River Trading·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
May 2026

Summary

HRT algo dev interview where the whole thing was a live coding exercise in an existing C++ trading system codebase. You're not writing from scratch, you're reading someone else's code and extending it. Felt more like a real work task than a typical interview problem.

Questions Asked (1)

Q1

You're given an existing C++ trading system with client/server architecture that already handles add and cancel order operations. Extend it to support a modify order operation, end-to-end, following the same patterns already in the codebase.

System DesignAPI & IntegrationsTechnical Trade-offs
Author's notes

The tricky part wasn't the implementation, it was spending enough time reading the existing code before touching anything.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the existing architecture and patterns for add/cancel, then walk through the end-to-end flow for modify: client API, network protocol, server-side order book handling, and persistence. Emphasize consistency with existing code patterns and discuss trade-offs like idempotency, error handling, and performance.

Pro tip: Highlight the importance of atomicity and idempotency in modify operations, and mention how you would test the new functionality, including edge cases like modifying non-existent orders or partial modifications.

1. Understand Existing Patterns

Review how add and cancel are implemented across client, server, and persistence layers to identify reusable components and conventions.

2. Design Modify API

Define the client-facing API for modify, including parameters (order ID, new price/quantity) and response handling, ensuring consistency with existing APIs.

3. Implement Server-Side Logic

Extend the order book and matching engine to handle modify requests, ensuring atomic updates and proper validation (e.g., order exists, new values valid).

4. Handle Persistence and Recovery

Update the persistence layer to log modify operations and ensure recovery mechanisms can replay them correctly.

5. Test and Validate

Write unit and integration tests covering normal and edge cases, and consider performance implications under load.

Key Points to Mention

  • Idempotency: Ensure modify requests can be safely retried without unintended effects.
  • Atomicity: Modify should be atomic—either fully applied or not at all.
  • Error Handling: Define clear error codes for invalid modifications (e.g., order not found, invalid price).
  • Performance: Minimize latency and avoid blocking the matching engine during modifications.
  • Consistency: Follow existing code patterns for API design, serialization, and logging.
  • Testing: Include edge cases like modifying partially filled orders or concurrent modifications.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.