AkunaCapital·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Jun 2026

Summary

Akuna Capital software engineer interview with a pretty involved C++ design problem centered on market making logic. The question had a lot of moving parts and felt more like a mini system design than a typical coding screen.

Questions Asked (1)

In C++, design and implement an InstrumentQuoter class that manages bid and offer orders for a single instrument on a BBO market. The class must enforce a minimum offset from a theoretical price, align prices to exchange tick sizes, avoid crossing the exchange BBO, and handle per-side state transitions so no new order is sent on a side until the previous one is confirmed removed.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This one took me a while to even mentally decompose.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, then outline the class design with clear separation of concerns: pricing logic, order state management, and exchange interaction. Emphasize the state machine for per-side order lifecycle and the validation rules (min offset, tick alignment, BBO crossing). Finally, discuss trade-offs and potential edge cases.

Pro tip: Demonstrate awareness of real-world exchange behavior: orders can be rejected or partially filled, so the state machine must handle asynchronous confirmations and failures gracefully. Also, mention that tick alignment and offset checks should be applied in the correct order to avoid unnecessary rejections.

1. Clarify Requirements and Constraints

Ask questions to understand the exact meaning of 'minimum offset', 'theoretical price', 'tick size', and 'BBO'. Confirm whether the class is responsible for sending orders or just managing state, and how it receives market data updates.

2. Design the Class Interface and State Machine

Define public methods (e.g., updateTheoreticalPrice, updateBBO, placeBid, placeOffer, onOrderConfirmed, onOrderRemoved) and internal state per side (e.g., enum: Idle, PendingNew, Active, PendingRemove). Ensure no new order is sent until removal is confirmed.

3. Implement Price Validation and Alignment

For a desired price, first apply the minimum offset from the theoretical price (e.g., bid <= theo - offset, offer >= theo + offset), then align to the nearest tick (round bid down, offer up). Finally, check against BBO to avoid crossing (bid < bestOffer, offer > bestBid).

4. Handle Asynchronous Order Events and Transitions

Implement callbacks for order confirmations, rejections, and removals. On removal confirmation, transition the side to Idle and allow new orders. Handle errors by logging and possibly retrying or alerting.

5. Discuss Trade-offs and Edge Cases

Talk about trade-offs: e.g., aggressive vs. passive quoting, handling of stale theoretical prices, and race conditions. Mention edge cases like tick size changes, BBO updates while order pending, and partial fills.

Key Points to Mention

State machine per side to enforce no new order until removal confirmed
Order of operations: apply offset, then tick alignment, then BBO check
Use of integer arithmetic for price calculations to avoid floating-point errors
Handling asynchronous confirmations and rejections from exchange
Thread safety considerations if market data and order events come from different threads
Logging and monitoring for debugging and compliance

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