Behavioural and 'why quant'

I'm preparing for a quant developer interview and I'm implementing: "Behavioural and 'why quant'"
What I'm building: Write out answers to: why quant/trading, why this firm specifically, the hardest bug you've debugged, and a time you were wrong.
Concepts I need to own: What each firm actually does, and how it differs from the others. Generic answers read as 'I applied everywhere'.

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.