Quant Developer Interview Prep roadmap

What is a mutex?

Log in to save this

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

Deliberately the most basic question here, because it is the one that most reliably separates memorised vocabulary from a working mental model. An answer can say 'mutual exclusion', 'lock', 'atomic', 'critical section' and still be wrong.

Exam

Answer these to pass this module.

Start here rather than at the reading. Whatever you miss tells you which part of Learn you actually need — and anything you get right is a part you can skip.

  • Thread A takes mutex M before writing a shared counter. Thread B writes the same counter without taking M. Is the counter protected?

  • What does std::lock_guard give you that calling lock() and unlock() by hand does not?

  • What is the sharpest difference between a mutex and an atomic?

Explain mode

What is a mutex?

Write your answer in a text box, out loud, or to a rubber duck — no notes, no compiler. Two or three sentences. Then check it against the criteria below rather than against a definition you find online.

Your own words, two or three sentences, nothing looked up. The rubric unlocks once you submit.

Graded against a set rubric. Three a day on a free account. Need more? Ask on our Facebook page — it's free.

 

Log in to answer

Answering marks your choice and explains why each option is right or wrong. It's a free account — no card, and your progress is kept.

Learn

Mutual exclusion, blocking versus spinning, what the mutex actually protects, why releasing has to be automatic, and why std::lock_guard exists at all.

Ask an AI to teach you this

I'm preparing for a quant developer interview on "What is a mutex?"
Concepts I need to own: mutual exclusion, blocking versus spinning, what the mutex actually protects, why releasing has to be automatic, and why std::lock_guard exists at all.

Run this as interview practice, not a lecture. One concept at a time.
Wait for my answer before moving on.

Per concept:
1. Teach it. Lead with the one-line core claim, then a few short
   paragraphs. Assume I write C++ but have never had this explained
   properly. No jargon without defining it.
2. "The 60-second version" — what a strong candidate would SAY out loud.
   First person, spoken register, no bullets, no headers. That's what I'm
   rehearsing.
3. Ask me one question that exposes whether I only think I understood it.

When I answer, reply in exactly this shape:

  Verdict: correct / partly correct / wrong — one line on what's wrong.
  What you missed: only if something's missing. 2-3 sentences.
  Vocabulary: only if I used a wrong or vague term. Give the right one.
  Example answer: the model spoken answer, 30 seconds max, 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 who gave
  that model answer.

Skip any section that doesn't apply. Don't pad. If I'm 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

Write your answer in a text box, out loud, or to a rubber duck — no notes, no compiler. Two or three sentences. Then check it against the criteria below rather than against a definition you find online.

Ship

Your written answer, kept. The point of the file is to re-read it after M5 and see what you did not know yet.

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.

  • P8 — grade my explanation against the rubric, and name what I left out
  • P1 — Socratic tutor (refuses to write code)