Quant Dev Interviews Are Built Different (Trust

Coding Jesus (real name: Tor) and Zack Light just dropped a mock quant developer interview on Exponent's channel, and I need you to understand something: this isn't your standard FAANG "reverse a linked list" energy. This is "implement a fundamental C++17 type from scratch while explaining memory layout decisions" territory.

The vibes? Immaculate and terrifying in equal measure.

They're tackling [std::any](https://en.cppreference.com/w/cpp/utility/any)—a type-erased container introduced in C++17 that can hold literally any type while maintaining type safety. Think of it as the responsible adult version of a void pointer, the kind that actually remembers what it's holding and won't let you accidentally interpret your cat photos as financial data.

When "Show Your Work" Means Show Your Entire Memory Model

Zack starts by explaining the theoretical groundwork, which honestly feels like watching someone explain the rules of a game where you're already three levels deep. "Whose responsibility is it to manage the type that's in std::any?" he asks.

"Yeah, it's std::any's responsibility," Tor responds. "Basically it requires the type to have a destructor. Basically, you like shouldn't give a type that has like a deleted destructor."

This casual exchange? It's doing Olympic-level conceptual lifting. They're talking about type erasure—a technique where you hide concrete types behind a generic interface without templates or virtual functions. It's the programming equivalent of those Russian nesting dolls, except each doll is managing its own memory and knows exactly what kind of doll it is.

Tor's approach is chef's kiss: he's not just implementing std::any, he's implementing it with small object optimization (SSO). Translation: small types live on the stack (fast access, no heap allocation), large types get heap storage (because you can't just YOLO 5MB onto the stack and expect your program to be chill about it).

The requirements are very specific and very unforgiving:

Implementation must be ≤80 bytes
Small types (just int for this exercise) go on the stack
Everything else gets heap allocation
Must properly deallocate heap objects
Wrong type cast? Throw std::bad_cast

It's like being asked to build a very specific type of house, with exact room dimensions, while explaining why you chose each nail.

The Devil Lives in the Template Specializations

Here's where it gets spicy. Tor starts sketching out his implementation strategy, and it's genuinely beautiful to watch someone think through systems-level decisions in real-time:

"I need a way to check the type... when I do any cast so I can throw the correct exceptions. And so I'm going to have like a store like a type... it's type info pointer that's 8 bytes."

He's constructing a mental model on the fly—storing type information (8 bytes), a small object buffer (32 bytes for stack storage), and a unique pointer with custom deleter (16 bytes: 8 for the resource, 8 for the deleter). Math checks out at 56 bytes. Under budget. ✨

But then comes the really interesting part: he needs to use [if constexpr](https://medium.com/@sagar.necindia/cpp-if-constexpr-ebe46c3da9cf)—a C++17 feature that does compile-time branch elimination. Not runtime branching where both code paths exist and one gets skipped. Actual "this branch doesn't exist in the compiled binary" elimination.

There's a moment where Tor second-guesses himself on when if constexpr was introduced (it's C++17, not C++20), and honestly? Relatable. The C++ standard moves fast enough that version-tracking becomes its own skill. "Things started getting blurry" after C++20, Zack admits. Mood.

Type Erasure Is Just Polymorphism Wearing a Trench Coat

The explanation of type erasure deserves its own paragraph because it's genuinely one of the cleaner explanations I've heard:

"Type eraser is basically it's like a way to build like a generic interface. You basically just you can it's kind of like doing polymorphism but you don't have to do templating and you don't have to do like virtual functions," Tor explains.

You're hiding implementation details while maintaining a clean interface. The std::any object doesn't know or care what type you stuffed into it at compile time—it figures it out through stored type information and custom deleters that "bake in" the type at construction.

When Tor implements the small object path, he's doing placement new (constructing an object at a specific memory location), managing alignment with alignas(std::max_align_t), and using std::launder—a C++17 utility that's genuinely arcane. Even Zack admits "the launderer is not my strong suit." It's basically telling the compiler "yes I did cursed memory things, please treat this pointer as valid anyway."

Without std::launder, you're technically in undefined behavior territory even if it works in practice. With it, you're telling the compiler "I know what I'm doing" (whether or not that's true is between you and the segfault gods).

What This Actually Reveals About Finance Tech

Here's the thing that makes this interview fascinating beyond the technical flex: this is what quant dev interviews actually look like. Not "design Twitter" or "tell me about a time you failed." It's "here's a fundamental building block of the standard library, reimplement it while making intelligent tradeoffs about memory layout."

The implicit skillset being tested is wild:

Deep understanding of memory models and allocation strategies
Comfort with template metaprogramming
Knowledge of C++ standard evolution across versions
Ability to reason about compile-time vs runtime decisions
Fluency with type systems and their practical implications

This isn't gatekeeping for gatekeeping's sake (okay, maybe a little). Quantitative finance runs on performance-critical C++ code where the difference between stack and heap allocation can matter. Where type safety isn't a nice-to-have—it's the thing preventing your pricing model from treating market data as garbage.

The interview format itself reveals something about how knowledge transfers in this space. Tor runs Get Cracked, a platform specifically for software engineers interested in quant trading. The fact that this niche exists—that there's demand for "how to pass quant dev interviews" content—tells you the skills gap is real and the on-ramp is steep.

Watching Tor work through the implementation, there's this constant dialogue between theoretical understanding and practical constraints. He's not just writing code that works; he's writing code that fits within an 80-byte limit while optimizing for both performance (stack allocation for small types) and safety (proper type erasure and destruction).

That's the game. Not higher complexity, not lower. Just... orthogonal to what most software engineering interviews test for. You can be an incredible engineer at a FAANG and get absolutely bodied by this kind of interview, not because you're not smart enough, but because you've never had to think about whether std::construct_at was introduced in C++17 or C++20 (it's C++20, by the way).

The quant dev pipeline is its own parallel universe, with its own knowledge requirements and its own interview meta. Tor and Zack are mapping that universe, one std::any implementation at a time. Whether that universe should require this level of C++ archaeology is a different question—but if you're trying to break in, this is the terrain.

— Yuki Okonkwo