Senior C++ — C++ interview questions

How do cache misses shape the way you lay out data?

A miss to main memory costs on the order of a couple of hundred cycles, so a structure that is theoretically better can lose badly to a contiguous array. That leads to laying data out the way it will be traversed — structure-of-arrays when you touch one field over many objects, packing hot fields together, and avoiding pointer chasing in the inner loop. False sharing is the same problem inverted: two threads writing to different variables in one cache line serialise on it, and the fix is padding to a cache line.

When is lock-free worth it, and what is the difference from wait-free?

Lock-free guarantees that some thread makes progress; wait-free guarantees every thread makes progress in a bounded number of steps. Lock-free is worth it under real contention on a small, well-understood structure — a queue, a counter — where a mutex measurably dominates. It is not worth it as a default: the code is hard to write correctly, hard to test, and a well-used mutex is fast in the uncontended case, so the honest answer usually starts with a measurement.

Explain memory ordering in `std::atomic`.

seq_cst is the default and gives a single total order across all threads — correct, and the easiest to reason about. acquire/release pairs establish a happens-before between the releasing store and the acquiring load, which is what a lock does internally and is enough for most producer-consumer patterns. relaxed guarantees only atomicity, no ordering, and is appropriate for things like a statistics counter. Weakening the ordering is a measured optimisation, not a starting point.

A project takes twenty minutes to build. How do you attack it?

Measure first — which translation units and which headers dominate. Then cut the header graph: forward declarations instead of includes, PIMPL on the widely included classes, and moving templates out of headers where instantiation cost is real. After that come the mechanical wins — precompiled headers, ccache, parallelism, unity builds, and a linker like lld or mold. Modules solve it properly where the toolchain is ready for them.

Code is slower than it should be. What is your method?

Start from a reproducible measurement, because intuition about C++ performance is wrong often enough to be dangerous. Profile to find where the time actually goes, then look at the algorithm before the micro-optimisations. Check what the optimiser did rather than assume — the generated code answers questions that reading the source cannot. And control the environment: build flags, warm caches, frequency scaling and noise from other processes will otherwise produce numbers that are not real.