0% found this document useful (0 votes)
12 views5 pages

Multi-Timeframe Trading Strategy Assignment

The Numatix-Quant Developer Assignment requires the design and implementation of a rule-based quantitative trading strategy using a multi-timeframe approach in Python. Key requirements include a class-based architecture for both backtesting and live trading on Binance Testnet, along with detailed logging and trade matching validation. Submissions must include source code, trade logs, and a summary document, with a focus on engineering rigor rather than strategy profitability.

Uploaded by

amzxchng
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views5 pages

Multi-Timeframe Trading Strategy Assignment

The Numatix-Quant Developer Assignment requires the design and implementation of a rule-based quantitative trading strategy using a multi-timeframe approach in Python. Key requirements include a class-based architecture for both backtesting and live trading on Binance Testnet, along with detailed logging and trade matching validation. Submissions must include source code, trade logs, and a summary document, with a focus on engineering rigor rather than strategy profitability.

Uploaded by

amzxchng
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Numatix-Quant Developer Assignment

Multi-Timeframe Strategy Execution & Trade Matching

Deadline: 30th December, 11:59 PM

Objective
The goal of this assignment is to evaluate your ability to:

●​ Design a rule-based quantitative trading strategy


●​ Implement it in a clean, modular, class-based Python architecture
●​ Ensure identical behavior between backtesting and live trading
●​ Demonstrate discipline in execution, logging, and validation

Strategy profitability or complexity is NOT a selection criterion or required for this


assignment

We are evaluating engineering rigor, correctness, and execution parity, not alpha.

Core Requirements
1. Strategy Design (Multi-Timeframe)

●​ Design a multi-timeframe trading strategy, for example:


○​ 15-minute timeframe for entries
○​ 1-hour timeframe for confirmation / filter
●​ Clearly define:
○​ Entry rules
○​ Exit rules
○​ Position sizing logic
○​ Trade direction (long / short)

The strategy must be deterministic and rule-based.


2. Class-Based Architecture (Mandatory)

You must implement the strategy using Python classes.

Important constraint:

The same strategy class must be used for both:

●​ Backtesting
●​ Live trading

No duplicate logic.

No “similar but separate” implementations.

This is a hard requirement.

3. Backtesting Implementation

●​ Use [Link] to run historical simulations


●​ Log every trade with:
○​ Timestamp
○​ Symbol
○​ Direction (BUY / SELL)
○​ Entry price
○​ Exit price
●​ Save backtest trades to a CSV file:

backtest_trades.csv

4. Live Trading System (Binance Testnet)

●​ Implement a live trading system using Binance Testnet REST API


●​ Use a modular, class-based structure
●​ Execution logic must:
○​ Use the same strategy class as backtesting
○​ Follow the same signal generation and execution flow
●​ No hardcoded signals or shortcuts

Live trades must be saved to:

live_trades.csv
5. Trade Matching & Validation (Critical)

●​ Compare backtest trades vs live trades


●​ Tally:
○​ Number of trades
○​ Direction
○​ Approximate timing
●​ Trades executed on Binance Testnet must closely match those generated during
backtesting

Small differences due to:

●​ Latency
●​ Candle close timing​
are acceptable, but logic mismatches are not.

6. Logging & Observability

You must include:

●​ Clear logging of:


○​ Signal generation
○​ Order placement
○​ Order execution
●​ Logs should make it easy to trace:

Market Data → Signal → Order → Fill

7. Documentation & Summary

Submit a short summary (1–2 pages or README) covering:

●​ Strategy logic (high-level)


●​ Architecture overview
●​ How parity between backtest and live execution was ensured
●​ Observations from trade matching
8. Interview Walkthrough (Mandatory)

You will be required to:

●​ Walk through your code


●​ Explain:
○​ Strategy logic
○​ Class design
○​ Execution flow
○​ Trade matching approach

Inability to explain your own code will result in rejection.

What We Are Evaluating


Strong Signals

●​ Single source of truth for strategy logic


●​ Clean separation of:
○​ Data
○​ Strategy
○​ Execution
●​ Discipline in logging and validation
●​ Awareness of live vs backtest differences

Not Evaluated

●​ Strategy returns
●​ Sharpe ratio
●​ Alpha complexity
●​ Overfitting

Submission Requirements
Your submission must include:

●​ Python source code


●​ backtest_trades.csv
●​ live_trades.csv
●​ README / summary document

Ensure the repository is clean, well-documented, and reproducible.


Important Notes
●​ You may use external libraries and tools
●​ Use of LLM’s is prohibited.
●​ You must understand and explain your implementation

Common questions

Powered by AI

The rationale for using a class-based architecture is to promote modularity and reusability in the codebase. It allows for a clean separation of concerns between data handling, strategy logic, and execution, facilitating the maintenance and scalability of the code. Additionally, this approach supports the requirement for the same strategy class to be used for both backtesting and live trading, thus ensuring execution parity .

Logging and observability are crucial for tracing and validating the trading strategy execution process. Specific elements that must be logged include signal generation, order placement, and order execution. These logs facilitate the tracking of the flow from market data to signal, order, and fill, ensuring that the execution process is transparent and any issues can be traced and resolved efficiently .

The assignment ensures parity between backtesting and live trading by mandating the use of the same strategy class for both scenarios, prohibiting duplicate logic or 'similar but separate' implementations. This includes using the same signal generation and execution flow. Additionally, trades executed on the Binance Testnet are compared to those in backtesting for number, direction, and approximate timing to ensure close matches, allowing for small differences due to latency and candle close timing .

Challenges in comparing backtest trades to live trades include dealing with discrepancies arising from latency and timing of candle closes. Acceptable differences include small variations attributable to these factors. However, logical mismatches are not acceptable; the core execution logic must match between the two environments to ensure the strategy behaves identically under backtesting and live conditions .

The interview walkthrough requires participants to demonstrate their code and explain aspects including the strategy logic, class design, execution flow, and trade matching approach. This ensures participants fully understand their implementation and can articulate the mechanics of their strategy and the reasoning behind design choices. Inability to explain the code results in rejection .

Avoiding hardcoded signals or shortcuts is critical to ensure that the live trading system faithfully represents and executes the logic defined in the backtesting phase. This consistency is crucial for execution parity between testing and live environments. It ensures that the strategy is scalable, robust, and adaptable to real market conditions, rather than reliant on fixed or external conditions that may not persist .

Documentation and summary play a crucial role by providing a high-level overview of the strategy logic, explaining the architecture, and detailing how execution parity between backtesting and live trading was ensured. This information demonstrates the candidate's understanding of the strategy and supports evaluators in understanding the design and implementation choices, enhancing the overall assessment process .

Using a single source of truth for strategy logic ensures consistency and accuracy across different components of the trading system. This practice minimizes the risk of discrepancies and errors that could arise from using duplicated or inconsistent logic in different parts of the system. It reinforces good coding practices by promoting reliability, maintainability, and correctness, thereby supporting robust trading strategy implementation and ensuring integrity and parity between backtesting and live trading .

Submission requirements include providing the Python source code, backtest_trades.csv, live_trades.csv, and a README or summary document. These submissions ensure a thorough evaluation by allowing reviewers to verify the strategy’s implementation, examine trade execution consistency between backtesting and live environments, and assess the clarity and thoroughness of documentation. A clean and reproducible repository enhances the assessment of the implemented strategy and its execution .

The key components required for designing a multi-timeframe trading strategy include: defining entry rules using one timeframe (e.g., 15-minute for entries) and confirmation or filtering rules using another (e.g., 1-hour), specifying exit rules, position sizing logic, and specifying trade direction (long/short). The strategy must be deterministic and rule-based .

You might also like