Hudson·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

Hudson SWE interview with a C++ systems coding question, pretty focused on low-level design and understanding an existing codebase before touching anything. Not a whiteboard-from-scratch situation, more like 'here's a real system, extend it properly.'

Questions Asked (1)

You're given a C++ trading system with client/server architecture that already handles AddOrder and CancelOrder. Add a ModifyOrder request that updates price and quantity, with proper validation and rejection logic, and explain how you'd navigate the existing codebase before writing any new code.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

The implementation part was manageable but the 'what would you inspect before making changes' angle tripped me up a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by explaining how you would navigate the existing codebase to understand the current architecture, message flow, and validation patterns for AddOrder and CancelOrder. Then outline a design for ModifyOrder that reuses existing patterns, includes robust validation and rejection logic, and considers trade-offs like atomicity and performance. Finally, discuss how you would implement and test the new request end-to-end.

Pro tip: Emphasize that you would first look for existing abstractions and utilities (e.g., validation helpers, order book interfaces) to avoid reinventing the wheel, and that you would write unit tests for edge cases like modifying a non-existent order or invalid price/quantity before writing production code.

1. Explore the codebase

Identify the main components: client, server, order book, message handlers, and validation logic. Trace the flow of AddOrder and CancelOrder from client request to server processing to understand patterns and extension points.

2. Define ModifyOrder semantics

Clarify what 'modify' means: does it update price and quantity in-place, or cancel and replace? Determine validation rules: order must exist, new price/quantity must be valid (e.g., positive, within limits), and whether modification is allowed based on order state.

3. Design the message and handler

Add a new message type for ModifyOrder, following the existing serialization format. Implement a server-side handler that validates the request, updates the order book, and sends appropriate acknowledgments or rejections.

4. Implement validation and rejection logic

Reuse existing validation utilities where possible. Handle edge cases: order not found, invalid price/quantity, modification of a filled or cancelled order, and concurrency issues. Return specific rejection reasons.

5. Test and integrate

Write unit tests for the handler and integration tests for the end-to-end flow. Ensure backward compatibility and consider performance impact (e.g., locking, order book updates).

Key Points to Mention

Codebase navigation: use IDE tools, grep for AddOrder/CancelOrder, read documentation, and understand the message protocol.
Reuse existing patterns: follow the same structure for message definition, serialization, and handler registration.
Validation: check order existence, price/quantity validity (e.g., positive, tick size), and order state (e.g., not filled).
Rejection logic: provide clear error codes/messages and ensure atomicity (e.g., no partial updates).
Trade-offs: in-place modification vs. cancel-replace, performance implications, and concurrency control.
Testing: unit tests for validation, integration tests for client-server interaction, and edge cases.

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