Interviewer Area
RECRUITMENT / ENGINEERING JUDGMENT

Make the context clear. Let the thinking stand out.

A C++ challenge for engineers moving across domains. Understand what an order means, then show how you reason about events, correctness and edge cases.

Understand the challenge See how we assess

No prior financial-markets or FIX knowledge required.

01 / THE BUSINESS CONTEXT

Requests are intentions. Reports are facts.

A trader wants to buy 100 units. The exchange may trade them in several pieces.

  1. Trader / strategy

    Chooses quantity and price

  2. Gateway + OrderTracker

    Your code tracks state, fills and remainder

  3. Exchange

    Executes trades and sends reports

Trade instruction
Requests · New · Cancel · ReplaceReports · Acceptance · Fills · Outcomes
Keep the state, filled quantity and remaining quantity correct.

From gaming? Commands and server replies are separate events. Here, executed trades always count.

Six terms. Enough domain knowledge to begin.

Order
A request to trade a total quantity at a limit price.
Fill
A quantity actually traded. It contributes to the cumulative filled quantity.
Cancel
Ask to stop the unfilled remainder. Earlier trades still count.
Replace
Ask to change the total quantity and limit price. Old terms apply until confirmation.
Execution report
A message from the exchange: accepted, filled, changed, rejected or finished.
Price ticks & notional
Prices are integer ticks. Filled notional is the sum of each fill quantity × its execution price.
02 / FOLLOW ONE ORDER

The messages can cross in flight.

Choose a scenario. Step through its messages and see the tracker update. Illustrative examples.

LOCAL ORDER RECORDEvent 1 of 6

Send an order for 100 units

StatePendingNew
Total quantity
100
Already traded
0
Still open
100
Limit price10 ticks
Awaiting confirmation

The request has been sent. The exchange has not acknowledged it yet.

03 / YOUR IMPLEMENTATION CONTRACT

Build the tracker. Explain the decisions.

Implement OrderTracker. Process one event at a time. These six rules summarize the full statement.

  1. Requests

    Validate state and quantities. One pending request per order; false changes nothing.

  2. IDs

    true consumes an ID forever. Cancel/replace name the current ID; old IDs still identify the order.

  3. Fills

    Add quantity and notional, even while pending. Old terms apply until Replaced confirms the change.

  4. Replacement

    Apply new terms on confirmation. Keep every fill, even when filled exceeds the new total.

  5. Reports

    Ignore duplicate execId. Invalid reports: log a violation, keep the order unchanged, then continue.

  6. Finished orders

    Filled, Cancelled, Rejected, Expired: remaining = 0. Ignore late CancelRejected reports.

Keep the public interface, types and tests unchanged. All tests must pass.

Full statement & rules Download (EN)
04 / WHAT THE INTERVIEW ASSESSES

Make your reasoning observable.

We look at how you turn a written contract into reliable behavior: the questions you ask, the model you choose, the tests you use, and the trade-offs you can explain.

01

Behavioral correctness

Translate the rules faithfully. Keep identities, quantities and state consistent through delayed and repeated reports.

02

C++ design

Explain ownership, lifetimes, data structure choices and complexity. Keep the implementation readable.

03

Testing and investigation

Use meaningful event sequences and boundary cases. Explain a failure before changing the code.

04

Reasoning and communication

Clarify assumptions, state invariants, discuss trade-offs and respond thoughtfully to new information.

A suggested interview structure

  1. 10 min

    Align on the domain

    Walk through the visual and restate the requirements.

  2. 40–45 min

    Implement and test

    The supplied challenge timebox. Build incrementally and explain the choices that matter.

  3. 15 min

    Optional follow-up

    Outside the coding timebox: explore restart/replay, bounded memory, thread ownership and latency.

Ready to reason about the order?

Before coding, explain why a fill can arrive after a cancel request and why cancellation cannot erase an executed trade. Then use the fresh CoderPad session supplied by your interviewer.

The brief provides expected behavior. The implementation and problem-solving approach are yours.

Explore the events