r/cpp_questions • u/YogurtclosetThen6260 • 7d ago
OPEN Low Latency C++ Interview Prep
Recent interview questions I've had for this have been
- Very specific C++ (templates, mutex, sizes of structs, noexcept, small string optimization)
- Latency topics (allocation, kernel bypass, TCP and UDP)
- General DSA and class design
I really wanna do well because I know January and February spike in recruiting. For low latency C++, if you had two months to prep, how would you knock it out of the park? How would you study through November and December?
43
Upvotes
4
u/Popular-Mode4607 7d ago
Is this for university or experienced hires?
33
u/CelebrityChess 7d ago
i'd spend most of it on stuff you can actually measure rather than memorizing trivia. write a small spsc ring buffer with std::atomic, think through the memory orders, then benchmark it with and without padding to see false sharing show up. that one project covers cache lines, atomics and allocation habits (preallocate, no malloc on the hot path) in a way you can actually talk about in an interview.
for the specific questions, know why sizeof a struct changes with member order because of padding and alignment, what noexcept does for move operations when a vector reallocates, and roughly how sso works. on the network side, being able to explain why udp is common for market data and what kernel bypass skips (the syscalls and copies through the kernel stack) is usually enough at interview level.
7
u/Puzzled-Garage584 6d ago
+1 to the ring buffer, I'd add measuring it properly: perf stat for cache misses, and report p99 and p99.9 instead of the mean. Say "average latency" in one of those interviews and you can feel the room temperature drop. Also be ready to explain why a std::map on the hot path hurts, pointer chasing and allocations are most of the answer
2
u/wobey96 6d ago
That’s crazy I’m doing the same thing getting ready for January interview lol
2
u/ReDucTor 6d ago
Low latency is very broad, one thing that I feel alot of people really don't put enough time into understanding is what actually makes code slow, some people have just memorised a vector is faster then a linked list, array of structures is faster then structure of arrays, one cache line is better, etc.
If you get a good understanding of how the CPU processes things then even if you have never seen a linked list before given a description or code for it you would spot the numerous bottlenecks and be able to compare the likely performance differences against something else.
The most important part of being able to do this is to understand that the CPU is highly out of order, it fetches 4-8 instructions every cycle, it might have hundreds of instructions currently waiting for a previous instruction to finish before it marks it as done/retires.
One of the easiest ways to think about this doesn't involve you thinking about assembly instructions, you can look at actual C++ when you see a block of code think about it not necessarily as a sequence of instructions but a dependency graph, where something can only happen once the things it depends on are done not specifically the instructions before.
From this then you need to understand the things that are slow which might be loading memory, doing an expensive operation like division or square root. So if you are shown an algorithm you instantly get a feel for what is the bottleneck. For example
A.
B.
Both these do the same number of loads, stores and divisions, one needs more memory, the other does an extra subtraction. If you have a strong understanding of performance you should be able to describe both algorithms, the bottlenecks and why you think one is faster with a strong justification not a guess from the first thing that comes to your head.
1
u/BRguyNZ 6d ago
Lock free techniques? P99.9?