Katkat
Back

Design a reusable event-driven framework for trading strategies

CubistSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

Design a reusable, event-driven framework for trading strategies that a team can keep extending after a take-home handoff. It tests event modeling and dispatch ordering, strategy interfaces, backtest and live parity, order and risk management, and the tests and documentation that make a framework maintainable.

As a take-home project, build a framework for trading strategies, including an event-handling layer, that a team will keep using and extending after you hand it over. Team members write strategies; the framework delivers events to them, such as new market data, and carries out the orders the strategies decide to send.

Describe and sketch the framework you would build: its architecture, its core interfaces, and the path of an event from its arrival to a strategy's decision to an order. Explain how the framework stays easy for the team to extend with new strategies, data sources and execution venues.

Constraints and Clarifications

  • The take-home brief, as reported, asks only for a strategy trading framework with event handling that the team can continue to use. Asset class, data sources, venues, latency targets and language are not given: ask, or state your assumptions.
  • The deliverable is code that other people will maintain, so the interfaces, tests and documentation are part of the answer, not extras.

Clarifying Questions

  • Should the same strategy code run in historical backtests, in simulated (paper) trading and in live trading?
  • Which events must be supported: quotes, trades, bars, order acknowledgements, fills, rejections, timers, others?
  • How many strategies run at once, and do they share market data subscriptions, positions or risk limits?
  • Is there a latency requirement, and does it outweigh ease of writing strategies?
  • Which language should the framework use, and is there existing market data or order-routing infrastructure to build on?

Hints

Hint 1

One timeline: Imagine market data and order fills reaching a strategy through separate paths, each with its own idea of the current time. Think about what that does to event ordering, and to whether a historical test agrees with live trading.

Hint 2

What the team will change most: List what the team will add most often after you leave, such as new strategies, new data sources or new venues, and make each of those a small, isolated extension point.

Hint 3

Between a decision and an order: Consider what should sit between a strategy deciding to trade and an order reaching a venue, so that a single faulty strategy cannot run away with positions.

Follow-up questions

  • A strategy's event handler throws an exception during a live session. What should the framework do with that strategy and its open orders?
  • How would you make a backtest deliver events in exactly the order a live session would have seen them?
  • One strategy needs to react within microseconds. What in your design would you change, and what would you give up?
  • How would two strategies share one market data subscription without a slow strategy delaying the other?