FreeCareerPath
Quant Developer Interview Prep roadmap

A bounded blocking queue

Log in to save this

Saving keeps this in your list across devices. It's a free account — no card.

Log inCreate a free account

A fixed-capacity queue that blocks producers when full and consumers when empty, built in three stages. It turns on one follow-up: what does pop() hand back? Get that wrong and the rest doesn't matter.

Learn

mutex, condition_variable and the predicate form of wait, atomic, the C++ memory model, memory_order — start at seq_cst and earn the weaker orderings.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "A bounded blocking queue"
What I'm building: Build it three times: (1) one mutex and two condition variables — correct and slow; (2) with try_push/try_pop and timeouts; (3) a shutdown path that wakes every blocked thread and drains cleanly.
Concepts I need to own: mutex, condition_variable and the predicate form of wait, atomic, the C++ memory model, memory_order — start at seq_cst and earn the weaker orderings.

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

Build it three times: (1) one mutex and two condition variables — correct and slow; (2) with try_push/try_pop and timeouts; (3) a shutdown path that wakes every blocked thread and drains cleanly.

Check

You're done when all of these are true:

  • Clean under TSAN in a multi-threaded stress test — 'it passed 10,000 iterations' proves nothing about a race
  • No deadlock, no lost wakeup, and no lock held across a caller-supplied callback
  • You can answer: what does pop() return? A reference into storage another thread can overwrite is the trap; moving the value out is the safe answer, and naming the tradeoff is the real answer.
  • You can explain why empty() followed by pop() is a race even though each is individually safe
  • Shutdown never leaves a producer blocked forever

Ship

Repo with all three variants and a benchmark under contention.

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.

  • P0 — first contact (explain a genuinely new topic)
  • P2 — adversarial test suite (try to break my implementation)
  • P4 — live mock interviewer
  • P6 — defend your design decisions with the code closed

Resources