C++ Interview Questions: Define, Cost, Example

Most C++ interview questions look like definitions, but they are trade-off questions in disguise. A definition can be memorised; a trade-off cannot. When you answer these c++ interview questions, define the feature precisely, name what it costs, and give one concrete example — then stop and let the follow-up come. That shape is what makes you sound like someone who has used the language, not just read about it. This article gives you the reusable script and works it through on virtual functions, move semantics, smart pointers and memory.

Why do C++ interviewers ask about trade-offs instead of definitions?

Anyone can recite that a virtual function enables runtime polymorphism. The interviewer learns almost nothing from that sentence. The signal is in the next question: when would you not use this, what does it cost, what would break, show me in code.

Every concept question has a shadow question behind it. "What is a virtual function?" is really "do you know what dynamic dispatch costs and when you would avoid it?" "What does std::move do?" is really "do you know it is a cast, not a move?" If you answer only the surface question, the interviewer has to dig, and digging often looks like you did not understand.

So treat each concept as a decision. The interviewer is checking three things: whether you know the feature, whether you know what it costs, and whether you can defend a choice. Answer all three and the conversation moves forward instead of stalling.

The three-move answer: definition, cost, example

Use the same short script every time. It keeps your answer under about 60 seconds and gives the interviewer a natural place to follow up.

"X does Y. The cost is Z. For example, in this situation I would…"

Say the definition in one sentence, name the cost in the second, and give a one-line example in the third. Then pause. Naming the cost early signals seniority, because it shows you think about consequences, not just mechanics. The example makes it concrete without turning into a story.

Here is a weak answer to "What is a virtual function?"

"It's a function that can be overridden in a derived class so you get polymorphism."

That is correct and forgettable. Here is the stronger version:

"A virtual function lets a call be resolved at runtime through the object's vtable, so a base-class pointer can dispatch to a derived override. The cost is an extra indirection per call and the compiler usually cannot inline it. For example, I would use it for a draw interface with several shape types, but not inside a tight per-pixel loop where the indirection matters."

The second answer invites the follow-up "when would you not use it?" — and you have already started answering it.

Virtual functions and polymorphism: what does the vtable cost you?

Dynamic dispatch works through a vtable: each polymorphic class has a table of function pointers, and each object carries a pointer to it. The call goes through that pointer, which means an extra indirection and, in most cases, no inlining. That is the cost. It is usually small, but it is real in hot code.

When would you avoid virtual? In tight loops where the call overhead and lost inlining add up; for small value types where a vtable pointer is a large fraction of the object; and when the set of types is known at compile time, where templates or CRTP give you static dispatch with no runtime cost.

A worked answer to "When would you not make a function virtual?"

"I'd avoid it when the type is fixed at compile time and the call is hot. For a small numeric type used in a loop, a vtable pointer and an indirect call are overhead I don't need, so I'd use a template or CRTP for static dispatch. I'd also avoid making every function virtual by default, because it blocks inlining and signals the class is designed for inheritance when it may not be."

Move semantics: when is a move not actually a move?

The common misconception is that std::move moves something. It does not. std::move is a cast to an rvalue reference; it marks the object as movable so a move constructor or move assignment can be selected. The actual work happens in that constructor or assignment.

A moved-from object is valid but unspecified: you can destroy it or assign to it, but you should not rely on its contents. Moving is not automatically cheaper — for small types like an int or a small struct, a copy can be as cheap or cheaper than a move, and move constructors that are not noexcept can affect whether a vector chooses to move or copy elements on reallocation.

A worked answer to "What does std::move do, and when is returning by value fine?"

"std::move is a cast to an rvalue reference — it doesn't move anything by itself. The move constructor does the work, and after it the source is valid but unspecified, so I don't read from it. For small types a copy is often just as cheap. And returning a local by value is usually fine because of copy elision and RVO: the compiler constructs the result directly, so I don't write std::move on a return, which can actually block elision."

Smart pointers: unique_ptr, shared_ptr, weak_ptr — and the cost of each

The one-line rule and the cost:

unique_ptr — sole ownership, zero overhead beyond the pointer itself. Use it as the default.
shared_ptr — shared ownership, but you pay for a control block and an atomic reference count on every copy.
weak_ptr — a non-owning observer that breaks reference cycles, at the cost of a lock to get a usable pointer.

A common follow-up is "When would shared_ptr be the wrong choice?" A concrete answer: when ownership is not actually shared. If one object clearly owns another, shared_ptr adds atomic refcounting and a control block for no benefit, and it hides the ownership model from the reader. Use unique_ptr and pass a raw pointer or reference to code that only needs to observe.

Before you choose an ownership model in an answer, ask yourself three questions:

Who owns this? One owner means unique_ptr; genuinely shared means shared_ptr.
Could there be a cycle? If two shared_ptrs can point at each other, one side should be a weak_ptr.
Does this need to own at all? Observers should take a reference or raw pointer, not a smart pointer.

const, references and value categories: the questions that expose gaps

const correctness is a habit, not a fact. Marking member functions const documents what they do not change and lets you call them on const objects. For read-only parameters, const T& is the default because it avoids a copy and accepts both lvalues and rvalues.

Value categories in one sentence each: an lvalue is an expression with a name you can take the address of; an rvalue is a temporary without a persistent identity. That distinction is exactly what move semantics is built on — rvalue references bind to temporaries so they can be moved from.

A worked answer to "Why pass by const reference instead of by value?"

"For a read-only parameter of a non-trivial type, const reference avoids a copy and accepts both lvalues and temporaries. I'd pass by value when the type is cheap to copy, like an int or a small struct, or when I want to take a copy anyway and let the caller's temporary be moved in."

Memory and undefined behaviour: answer without hand-waving

Stack versus heap is about lifetime and cost: stack allocation is fast and scoped, heap allocation is flexible but slower and needs an owner. RAII is the organising idea — tie resource lifetime to object lifetime so cleanup happens automatically, even on exceptions.

Undefined behaviour is not "it crashes sometimes". It means the standard places no requirements on what the program does. "It works on my machine" is not an answer, because the compiler is allowed to assume UB never happens and optimise accordingly.

A short script for "What is undefined behaviour and why does it matter?"

"Undefined behaviour means the standard imposes no requirements on the result. For example, reading past the end of an array is UB, and the optimiser can assume it never happens, so the bug can appear only in release builds. That's why I prefer bounds-checked access or containers that make the mistake harder."

The trade-off on memory: manual new and delete is defensible in low-level code where you control every path, RAII wrappers are the default, and smart pointers are RAII with ownership expressed in the type. Pick one and say why.

The follow-up question: how to keep the conversation going

Follow-ups usually take one of four shapes. Have a starting sentence ready for each.

"When would you not…" — "I'd avoid it when the cost isn't worth it, for example…"
"What does it cost…" — "The main cost is… and the secondary cost is…"
"What would break…" — "The risk is… and I'd guard against it by…"
"Show me in code" — "Here's the smallest version: I'd write… and then check…"

A bridging phrase buys you a second to think without going silent. For narrating your reasoning while you write code, see Think Out Loud Interview: How to Narrate Your Reasoning. The follow-up technique for another language is covered in PHP Interview Questions: Nail the Follow-Up Answer, and the shape is the same.

Common mistakes and a 20-minute practice routine

The three most common mistakes on C++ concept questions:

Reciting definitions. It answers the surface question and leaves the trade-off unanswered. Fix: add the cost sentence every time.
Ignoring cost. Saying a feature is "good" without saying what it costs sounds like you have not used it. Fix: name one cost and one situation to avoid it.
Guessing instead of saying "I would check the standard". Inventing a detail is worse than admitting uncertainty. Fix: say what you would check and why it matters.

A 20-minute solo routine:

Pick three concepts from this article.
Write the three-move answer for each: definition, cost, example.
Say each one aloud, timed, aiming for under 60 seconds.
Ask yourself one follow-up from the four shapes and answer it out loud.

Use detail from your own projects so the examples are real, not invented. If you are short on project detail, Resume Context Interview Assistant: Practise With Your Own Detail shows how to mine your own experience for examples. Practising aloud is what makes the script available under pressure.

Before you walk in

Every C++ concept question is a trade-off question. Define the feature, name the cost, give one example, then pause and let the follow-up come. That shape keeps you under a minute and shows you think about consequences. Pick three concepts tonight — virtual functions, std::move, shared_ptr — and write the three-move answer for each. Say them aloud once. The first time is awkward; the third is yours.

Frequently asked questions

Should I say "I don't know" if I can't remember a C++ standard detail?

Yes, then say what you would check. "I don't remember the exact rule for that overload; I'd check the standard or cppreference and confirm the value category." This is more credible than guessing, because interviewers often know the detail and a confident wrong answer costs more than an honest gap. Pair it with what you do know about the trade-off.

Do I need to know C++11/14/17/20 features for every interview?

No. Match the level to the role. A modern C++ role usually expects move semantics, smart pointers and at least awareness of later features; a legacy codebase may care more about the older style you will actually maintain. Ask the recruiter which standard the team uses, and be ready to say which features you have used and which you have only read about.

How much code should I write when asked a C++ concept question?

Usually a few lines, not a program. Write the smallest snippet that shows the idea — a class with one virtual function, a move constructor, a unique_ptr declaration — then narrate what it does and what it costs. Offer more only if the interviewer asks. Long code blocks eat time you may need for the follow-up.

Is it bad to mention a feature I've only read about but never used at work?

Not if you label it honestly. Say "I've read about that but haven't used it in production" and then give the trade-off as you understand it. Interviewers usually respect the boundary; what damages you is claiming experience you do not have and then failing the follow-up questions that expose it.

Practise your three-move answers aloud before the real round.