Build a string interner

Map every distinct string to a stable integer id, once. It is a real thing every tick-handling system has, and it forces you to build an open-addressed table and then explain your win in cache terms rather than adjectives.

Learn

Chaining vs open addressing, linear probing, load factor, why std::unordered_map is node-based and pointer-chasing, and how arena-allocating the string bytes changes the picture.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "Build a string interner"
What I'm building: An open-addressed table mapping string to id, with the bytes packed into an arena rather than stored as individual std::strings. Ids must stay stable across a rehash.
Concepts I need to own: Chaining vs open addressing, linear probing, load factor, why std::unordered_map is node-based and pointer-chasing, and how arena-allocating the string bytes changes the picture.

Run this as implementation coaching, not a lecture. One design decision at
a time. Wait for my code before moving on.

Per decision:
1. Frame it. State the decision in one line, then the options and what each
one costs. Assume I write C++ but have never had this explained properly.
No jargon without defining it.
2. "The 60-second version" — how a strong candidate would DEFEND that choice
out loud. First person, spoken register, no bullets, no headers. That's
what I'm rehearsing.
3. Tell me what to write, and ask me one question about the edge case I'm
most likely to get wrong.

When I show you code, reply in exactly this shape:

Verdict: correct / partly correct / wrong — one line on what's wrong.
What breaks: the input or sequence that breaks it. Only if something does.
Vocabulary: only if I used a wrong or vague term. Give the right one.
Example answer: how I'd defend this design out loud, 30 seconds, first person.
More info: define any term I probably don't know, one line each.
Follow-up probe: the one question an interviewer asks someone whose code
looks like that.

Skip any section that doesn't apply. Don't pad. If it's wrong, say wrong —
don't soften it.

Do not write my implementation for me. If I ask, refuse and ask what I'd
try instead — I need to defend this code with the editor closed.

Do

An open-addressed table mapping string to id, with the bytes packed into an arena rather than stored as individual std::strings. Ids must stay stable across a rehash.

Check

You're done when all of these are true:

Beats an equivalent std::unordered_map<std::string, uint32_t> on a lookup-heavy benchmark
You explain the win in cache terms — not 'it's more optimised'
Ids survive a rehash, and you can say why that constrains what you're allowed to store in the table
You can state your collision and load-factor policy without looking at the code

Ship

Repo, benchmark, and the written explanation of why it wins.

Practice with AI

Use these to make the AI your examiner, not your author. If the AI wrote the code, this node doesn't count — you can't defend a design you didn't make.

P5 — explain the slowdown at the hardware level
P3 — HFT-style code review, ends in hire/no-hire

Resources

Curated resources for this node are on the way. Use what you already know how to search for, and check back soon.