Quant SWE Foundations
Connect C++, machine behavior and latency into interview answers you can support with evidence.
Prerequisites: You can solve basic coding problems and read C++ functions and classes. Start with the Coding Interviews track if needed.
This is a systems foundation path for Quant SWE. It is not a complete trading-systems course or preparation for quant research/trader interviews. Native measurements belong in your local environment; browser visualizations are models.
Saved in this browser. Self-checks are separate from your scored interview results.
Session 1 · To work through
Explain what Big-O leaves out
Reason about locality, allocation and dependency chains without inventing timings.
Learn and practice
Your exercise
Compare a vector scan and a linked-list scan over the same values. Predict the bottleneck before running a local benchmark. Record data size, compiler, optimization flags and warm-up procedure.
Before moving on
- I explain why both scans can be O(n) and still have different costs.
- I separate a locality hypothesis from an actual measurement.
- My comparison keeps useful work and data size equivalent.
Session 2 · To work through
Trace ownership and shared state
Say who owns an object, how long it lives and which threads may touch it.
Learn and practice
Your exercise
Draw the ownership and lifetime of a buffer passed to a worker. Compare passing a copy, moving ownership and sharing a reference. Explain what happens if the producer destroys or resizes the buffer too early.
Before moving on
- I distinguish lifetime safety from synchronization.
- I identify when a copy is acceptable and when ownership can be transferred.
- I can explain why one successful run does not establish absence of undefined behavior.
Session 3 · To work through
Establish ordering before optimizing locks
Explain publication and visibility with a happens-before relationship.
Learn and practice
Your exercise
Describe a producer writing a payload and publishing a ready flag. State the synchronization required before the consumer reads the payload. Then explain why padding adjacent counters might affect speed but cannot repair missing synchronization.
Before moving on
- I distinguish atomic access from ordering other memory operations.
- I identify the communication edge between producer and consumer.
- I treat false sharing as a performance issue separate from logical correctness.
Session 4 · To work through
Follow a message through the system
Locate where scheduling, buffering and transport can add delay or change delivery behavior.
Learn and practice
Your exercise
Sketch a feed receiver from socket to application queue. Discuss packet loss, process descheduling and a consumer that falls behind. Identify what the application would need to detect a gap and rebuild its state.
Before moving on
- I separate transport guarantees from application-level sequence and recovery rules.
- I explain where queueing can occur.
- I have an explicit policy for a slow consumer rather than unlimited buffering.
Session 5 · To work through
Read a latency report critically
Distinguish typical response time, tail behavior, throughput and offered load.
Learn and practice
Your exercise
Design a measurement for a bursty workload. Name start/end timestamps, load generation, sample count and percentiles. Explain how a client that waits for each response can hide overload.
Before moving on
- I report distributions and load conditions rather than only an average.
- I separate service time from queueing and end-to-end response time.
- I can describe a measurement flaw that would make an apparent improvement misleading.
Session 6 · To work through
Defend a diagnosis under follow-up questions
Move from observation to hypothesis, discriminating measurement and safe change.
Learn and practice
Your exercise
Choose an unfamiliar investigation. Spend 30 minutes explaining the symptom, two competing causes, one measurement that distinguishes them and a change you would test. State what would disprove your hypothesis.
Before moving on
- I considered more than one plausible cause.
- My next measurement changes what I would do.
- I can explain the expected trade-off and the evidence needed before calling the change successful.
Test transfer on something unfamiliar
Revisiting a solution tests recall. Choose a different problem, explain your assumptions and record what you still need help with.
Build and recover an order book →