|
|
||
|---|---|---|
| .cursor | ||
| .github/workflows | ||
| .vscode | ||
| setup_utils | ||
| solution | ||
| .gitignore | ||
| .gitmodules | ||
| README.md | ||
| TODO.md | ||
README.md
Career Kickstarter - Optivex
This repository contains the code for the Tech Career Kickstarter program. In this program, participants build a simulated financial exchange called Optivex.
The project is organized into the following directories:
setup_utils/: The setup utilities for the program.solution/: The solution code for the program. Contains the system tests and the UAT continuous deployment daemon.x_template/: The template code for the program. This is a submodule pointing to the template repository.
Notes to Program Managers
- Instruct participants on designing iteratively so they can optimize for testing through the week.
- Expect struggles with modelling client handler vs publishing messages to all clients. Requires abstracting stuff away to avoid circular dependency.
- There will always be trade-offs between performance and robustness. Are they aware of them?
Interesting Observation Points for Assessment
-
How do they handle the race conditions? There will always be trade-offs between performance and robustness. Are they aware of them?
- Between creating an order book and creating an instrument in Info?
- Between inserting an order and executing a trade?
- Between subscribing to an order book and receiving updates?
-
How do they design their initialization logic? Is it clear, maintainable and robust against race conditions?
-
How do they handle precision issues when dealing with floating point numbers, like price?
Guidelines for Participants
-
You have access to all the "framework" code you need to implement your solution, like the Application class, the TCP connection manager and the message codec. Navigate through the code to understand how it works and how you can use it to your advantage. This is a phylosophy we extensively follow at Optiver.
-
You can control the level of complexity you have to deal with all at once by tuning the abstraction layers in your code, like when you merge together two classes that became too similar or rather split up the ones that got too large.
Tech Setup
This program is designed to run on AWS EC2 instances. The dev machines are EC2 instances that are used by the participants to develop their solution. The UAT machine is an EC2 instance that is used to run the system tests against the participants' solution.
Each machine must have installed:
- Linux: The operating system used to run the program. Recommended: Red Hat Enterprise Linux 9. Make sure you have
sshand that the every machine can access Github. - git: For cloning the repository and pushing changes.
- python3.11: The version of Python used to run the project.
- uv: The package manager for the project, used to build the project and install dependencies.
- protobuf-compiler: For generating the Python files from the protobuf files. Version 3.25.0 or higher is required.
UAT Instance
The program manager should use this machine as their main working machine during the program. It must be set up to have easy ssh access to the dev machines.
This machine must be set up with the following:
- A SSH identity key in
$HOME/.ssh/id_optivex. - Environment variables:
- CK_DEPLOYMENT_DIR: The directory where the deployment files will be stored.
- CK_TESTS_DIR: The directory where the tests (under
solution/tests) are checked out in this server. - CK_TEMPLATE_REPO_URL: The URL of the template repository to be cloned on the dev machines.
- A clone of this repository.
The setup_utils directory contains important scripts for setting up the dev environments of the program. Once this machine is set up, execute setup_utils/setup_dev_machine.sh for every dev machine to set them up. This script will:
- Copy the SSH identity key to the dev machines.
- Copy
setup_utils/deploy_to_uat.shinto the dev machines and make it available in their path. - Configure the following environment variables on the dev machines:
- CK_UAT_USER: The username of the UAT user.
- CK_UAT_HOST: The hostname of the UAT machine (the public IP of the UAT machine).
- CK_UAT_DEPLOYMENT_DIR: The directory where the deployment files will be stored on the UAT machine.
- Clone the template repository on the dev machines under
~/optiver-career-kickstarter.
Finally, you're ready to run test_finder.py.
Continuous Deployment Daemon
Inside the solution/ directory, the continuous_deployment/test_finder.py script continuously monitors for new deployments on the UAT machine and trigger system tests against them. It must be run on the UAT machine.
The script runs from within the project's solution. First you must create a virtual environment install the required dependencies. You can do this with uv sync from within solution/, then activate it with source .venv/bin/activate.
Now you can run the script with python test_finder.py.
This script will look for new deployments in the CK_DEPLOYMENT_DIR directory on the UAT machine. If it finds a new deployment, first it creates a new virtual environment and installs the deployed package (wheel) there. Then it runs the system tests against the deployed package. The test results will be copied back to the dev servers.
Dev Instances
The dev machines must be set up with an user account matching the machine name. For example, if the machine name is dev-1, the user account must be dev-1.
After the machine is properly set up by the program manager, participants will have access to:
- ~/optiver-career-kickstarter: A clone of this repository's template already at a new branch named after the participant's username.
- deploy_to_uat.sh: This file must be made available to the participants in their dev server. It builds their project using
uv buildand copies the results onto the UAT server, where automated system tests will be run against it.