RehearseAI
C++ interviews have a well-earned reputation for trivia. Somebody will ask you what mutable does, or to recite the rule of five, and it can feel like the whole thing is a memory test.
It usually is not. The trivia is a filter. What decides the outcome is whether you reason about ownership and lifetime the way someone who has debugged a real crash reasons about them.
Here are the questions that come up, and what a strong answer sounds like.
Memory and ownership
"What is RAII?"
The most important idea in the language, and the one to answer with a sentence about why rather than a definition. Resource acquisition is initialisation: a resource is owned by an object, the destructor releases it, and so it is released correctly even when an exception unwinds the stack. That last clause is the point of the whole technique.
"unique_ptr versus shared_ptr — which do you reach for?"
The right answer has a default. unique_ptr first, because single ownership is easier to reason about and costs nothing. shared_ptr only when ownership genuinely is shared, because it is not free — atomic refcounting, and the possibility of a cycle that never frees.
Then mention weak_ptr and cycles unprompted. It signals you have actually hit that bug.
"Explain the rule of five."
Destructor, copy constructor, copy assignment, move constructor, move assignment. Then the version that matters in practice: the rule of zero. If you design so that members manage their own resources, you write none of them, and that is the goal.
"What is a dangling reference and how do you get one?"
Returning a reference to a local. Holding a reference into a vector that then reallocates. Keeping a string_view onto a temporary. Be able to name at least two.
Move semantics
"What does std::move actually do?"
The question that catches out people who have only read about it. It does not move anything. It is a cast to an rvalue reference — it marks the object as eligible to be moved from. Whether anything is moved depends entirely on the type's move constructor.
"When would a move not happen?"
If the type has no move constructor, or if the object is const. Saying this unprompted is a strong signal.
The language questions
"Virtual destructors — when do you need one?"
Whenever you delete through a base pointer. Without one it is undefined behavior and the derived destructor never runs. A one-line answer, and worth having crisp.
"What is undefined behavior, and why is it worse than a crash?"
Because a crash at least tells you. Undefined behavior lets the optimiser assume it cannot happen, so the program may work perfectly until the day it does not. Mentioning that you build with sanitisers is a good move here.
"const correctness — why bother?"
It is documentation the compiler enforces, and it lets you pass objects around without wondering who might modify them.
The debugging question
Sooner or later: "the program crashes once every few hundred runs, only in release builds. Where do you start?"
Narrate a method:
"Intermittent and release-only points at undefined behavior or a race, so first I would try to make it reproducible — run it under AddressSanitizer and ThreadSanitizer, since those catch most of this class. I would check whether it still happens with optimisations off, because that narrows it a lot. If it is threading, I would look for shared state without synchronisation before anything else."
Naming the sanitisers specifically is what separates the answer.
Say the hard ones out loud
Pick three: RAII, what std::move really does, and the intermittent crash. Answer each aloud in ninety seconds.
The std::move one in particular is where people who understand it perfectly still produce two minutes of circling, because it is a subtle idea and speaking it is different from knowing it.
If you want the follow-ups too, RehearseAI asks them out loud for the role and stage and tells you where the answer sagged. Every account gets one free 5-minute interview a month, no credit card required.
Quick answers
Which C++ standard should I know? Whatever the job uses — ask. Being comfortable through C++17 and aware of what C++20 added is a safe baseline.
Will I have to write code live? Usually. Often small: implement a smart pointer, fix a memory bug, write a simple container.
Do they still ask about raw pointers? Yes, because legacy code exists. Know how to reason about them; say you would prefer not to own memory that way.
What if I have not used templates much? Say so. Being honest about depth is better than an answer that collapses on the first follow-up.
If the interview turns behavioral, the STAR method is the shape to use. More on why I built this.
