Quant developer HFT course · Module 10: Numbers and time
Drill: numbers and time
These questions look elementary and are not. Interviewers use them to find out whether you have been bitten by numbers and clocks, so be concrete about the failure and the fix.
Prompt 1: Equal doubles
The interviewer says
Why might two prices computed by different code paths compare unequal, and what would you do?
Before you answer
Question · choose every correct option
Which statements are right? Choose all that apply.
Precision does not fix representation; integers in ticks do.
Answers that lose the point
Compare with a tolerance of 1e-9.
Fragile at large magnitudes and treats a real one-tick difference near small prices as equal or not depending on scale.
A strong answer
Each path rounds at every operation, and most decimal prices are not exactly representable to begin with, so two computations of "the same" price can land on neighbouring doubles. For computed real numbers I would compare with a tolerance that has relative and absolute parts.
For prices specifically, I would not use doubles at all: integer ticks per instrument are exact, compare exactly, and work as keys and indices. A computed fair value is rounded to a tick once, in the direction the trade requires.
Prompt 2: Representing prices
The interviewer says
How do you represent prices in the system?
Before you answer
Question · choose every correct option
What belongs in the answer? Choose all that apply.
Integers give exactness and speed; strings are exact but useless for arithmetic and slow.
Answers that lose the point
Doubles, they have 16 digits of precision.
Precision is not representation; 0.1 still isn't 0.1.
A strong answer
As 64-bit integers counting ticks of the instrument, with tick size, multiplier and any price-dependent tick regime from reference data. Exchange prices convert to ticks once in the decoders and back once in the encoders; everything internal is exact integer arithmetic.
I would wrap it in a strong type so prices cannot be added to quantities or mixed between instruments, widen to 128 bits where notional calculations could overflow, keep averages as integer numerators and denominators until a real number is needed, and support negative prices.
Prompt 3: Negative variance
The interviewer says
A running variance using sum of squares minus square of sum goes negative. Why, and what's the fix?
Before you answer
Question · choose every correct option
Which statements are right? Choose all that apply.
More precision postpones the problem; a stable algorithm removes it.
Answers that lose the point
Clamp it at zero.
Hides the symptom; the positive values are also wrong.
A strong answer
The formula subtracts the square of the mean from the mean of the squares. For prices with a large level and small moves, both terms are huge and nearly equal, so the subtraction cancels the agreeing digits and leaves rounding error, which can be negative.
I would switch to Welford's update, which tracks the mean and the sum of squared deviations from it, so subtractions are between values of the size of the deviations and the result cannot go negative. Working with returns or with prices minus a reference has the same effect.
Prompt 4: Timestamps on the hot path
The interviewer says
We want a timestamp at every stage for every message. clock_gettime costs too much. What do you do?
Before you answer
Question · choose every correct option
Which choices are right? Choose all that apply.
The TSC is the cheapest monotonic source on x86; the wall clock is neither cheaper nor safe for durations.
Answers that lose the point
Use std::chrono::high_resolution_clock.
On most platforms it is one of the other two clocks; it does not solve the cost.
A strong answer
Read the time-stamp counter with rdtsc at each stage and store the raw counts in the message's trace record; on modern x86 with an invariant TSC it is constant-rate and consistent across cores, and costs a handful of cycles.
At start-up and periodically, I would calibrate it against CLOCK_MONOTONIC, and convert to nanoseconds in the thread that consumes the trace records, not on the hot path. Where a short region needs precise ordering I would use rdtscp or a fence. And I would verify the invariant TSC flags on the production hardware.
Prompt 5: Clocks across machines
The interviewer says
How do you make timestamps from different machines comparable, and what do regulators require?
Before you answer
Question · choose every correct option
Which statements are right? Choose all that apply.
NTP's software-level accuracy is typically far from what high-frequency requirements and internal latency analysis need.
Answers that lose the point
Each machine's TSC.
TSCs on different machines are unrelated.
A strong answer
Through PTP: GPS-disciplined grandmasters, PTP-aware switches, and network cards with hardware clocks, kept in sync by ptp4l, with phc2sys steering each host's system clock to its card. That gives sub-microsecond agreement across machines, and packet timestamps taken by the cards are directly comparable.
Regulators require traceability to UTC; under MiFID II, firms doing high-frequency algorithmic trading must stay within 100 microseconds of UTC with timestamps of microsecond granularity or finer, and the offsets must be monitored and recorded. Internally, the same synchronisation makes cross-machine latency measurements meaningful.
After the drill
That completes the course. Go back to the pattern map in Module 9 and check that, for every row, you can explain the cost, the mechanism and the code. Then work the drills again, out loud, without looking at the answers.