FreeCareerPath
Quant Developer Interview Prep roadmap

Implement unique_ptr

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

Write your own unique_ptr from scratch. Small enough for thirty minutes, deep enough to expose whether you actually understand ownership — which is why it opens so many loops. The interview is not the happy path; it is self-move, the deleter, and the array specialisation.

Learn

RAII, move semantics, the rule of five, explicit constructors, why a deleter belongs in the type rather than at the call site, and what the T[] specialisation has to do differently.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "Implement unique_ptr"
What I'm building: Implement UniquePtr<T, Deleter>: move constructor and move assignment, release, reset, swap, get, operator*, operator->, operator bool, deleted copy operations, a deleter supplied as a template parameter, and a T[] specialisation with operator[].
Concepts I need to own: RAII, move semantics, the rule of five, explicit constructors, why a deleter belongs in the type rather than at the call site, and what the T[] specialisation has to do differently.

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

Implement UniquePtr<T, Deleter>: move constructor and move assignment, release, reset, swap, get, operator*, operator->, operator bool, deleted copy operations, a deleter supplied as a template parameter, and a T[] specialisation with operator[].

Check

You're done when all of these are true:

  • Self-move neither leaks nor double-frees — write the test that proves it
  • Copy operations are `= delete`, not merely private or omitted
  • The deleter is a template parameter, and you can say why that beats storing a std::function
  • sizeof(UniquePtr<T>) == sizeof(T*) with a stateless deleter, and you can explain how
  • The T[] specialisation calls delete[] and has no operator->
  • Clean under ASAN, including a loop that throws partway through

Ship

A repo with the implementation and its test suite, including the self-move and throwing cases.

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.

  • P9 — implementation coach: reviews and probes, never writes the code
  • P2 — adversarial test suite (try to break my implementation)
  • P3 — HFT-style code review, ends in hire/no-hire
  • P6 — defend your design decisions with the code closed

Unlike the rest of this track, this one is deliberately the real question — firms ask it by name. Ship it knowing the follow-ups are where the round is decided.

Resources