Interview Questions

If a class manages a resource directly, it usually needs a custom destructor, and then also a copy constructor and copy assignment (Rule of Three), and since C++11 a move constructor and move assignment too (Rule of Five), because the compiler-generated versions would copy the raw handle and cause double frees. The Rule of Zero is the goal: do not manage resources in ordinary classes at all; hold them in members that already manage themselves (std::vector, std::string, std::unique_ptr) and write none of the five.

What they are really testing: The Rule of Zero as the preferred design.

Moving transfers resources from an object that is about to be discarded instead of copying them: moving a std::vector steals its buffer pointer in O(1). Rvalue references (T&&) bind to temporaries and to objects cast with std::move, selecting the move constructor or move assignment. std::move itself moves nothing: it is a cast to an rvalue reference that permits a move. The moved-from object is left in a valid but unspecified state (typically empty) and may only be assigned to or destroyed.

What they are really testing: That std::move is only a cast, and moved-from state.

When a function returns a local object by value, the compiler constructs it directly in the caller's storage instead of copying or moving it. Since C++17 this is guaranteed for returning a prvalue (return Widget{...};), and named return value optimisation (NRVO, return result;) is applied in practice by all major compilers. So returning a large std::vector by value is cheap. Writing return std::move(local); is a pessimisation: it prevents NRVO.

What they are really testing: Returning by value is cheap, and not to std::move a return.

Each class with virtual functions has a vtable, a static table of function pointers, one per virtual function. Each object of such a class holds a hidden vptr pointing at its class's vtable, set by the constructor. A virtual call loads the vptr, indexes the table and calls through the pointer. The costs: one pointer per object, an indirect call that is hard to inline, and possible cache misses. Inside constructors and destructors, virtual calls dispatch to the class currently being constructed, not the most derived one.

What they are really testing: vtable/vptr, the costs, and the constructor caveat.

static_cast: compile-time conversions between related types (numeric conversions, up and down a class hierarchy without a check). dynamic_cast: a checked downcast in a polymorphic hierarchy, returning null (pointers) or throwing std::bad_cast (references) if the object is not of that type; it needs RTTI and costs a runtime lookup. const_cast: adds or removes const; modifying an object that was really declared const is still undefined. reinterpret_cast: reinterprets bits, for low-level code only. C-style casts try all of these silently, which is why they are avoided.

What they are really testing: Which one is checked, and why C-style casts are discouraged.

A single-argument constructor is also an implicit conversion: with Meters(double), the call walk(5.0) silently builds a Meters. Marking it explicit requires walk(Meters{5.0}), preventing accidental conversions and overload surprises. The same applies to conversion operators (explicit operator bool()). Good default: make single-argument constructors explicit unless implicit conversion is the point (like std::string from a literal).

What they are really testing: Implicit conversions as a source of bugs.

"Pointer to implementation": a class holds only a std::unique_ptr<Impl> to a privately defined implementation struct, declared in the header and defined in the .cpp. Changing the private members no longer changes the header, so dependent files do not recompile, and ABI stays stable for shared libraries. Costs: a heap allocation and an extra indirection per call. The destructor must be defined in the .cpp, where Impl is complete.

What they are really testing: Compile-time and ABI firewalls, and the destructor detail.

noexcept promises a function will not throw; if it does, std::terminate is called. It enables optimisations, and crucially, std::vector only moves elements during reallocation if their move constructor is noexcept; otherwise it copies them to keep the strong exception guarantee. So a type with a throwing (or not marked) move constructor makes vector growth slow. Mark move operations, swap and destructors noexcept (destructors are implicitly).

What they are really testing: The vector reallocation consequence.

A template is a pattern the compiler instantiates for each set of template arguments at compile time, generating fully typed code with no runtime dispatch: that is why std::sort with a lambda can outperform C's qsort. Trade-offs: definitions must be visible (usually in headers), each instantiation adds compile time and binary size, and errors used to be notoriously long (concepts help). Techniques: specialisation, variadic templates, if constexpr, and SFINAE or concepts to constrain.

What they are really testing: Compile-time instantiation and its costs.

Concepts (C++20) are named compile-time predicates on types: template <std::integral T> or a custom concept HasArea = requires(T t) { t.area(); };. They constrain templates declaratively, select overloads by constraint, and give short errors ("constraints not satisfied") at the call site. SFINAE achieved similar selection with std::enable_if tricks that were hard to read and gave cryptic errors.

What they are really testing: Readability and diagnostics.

std::map is a balanced binary search tree (a red-black tree in practice): O(log n) operations, keys kept sorted, requires operator<, iterators stay valid on insertion. std::unordered_map is a hash table with buckets of nodes: O(1) average, O(n) worst case, requires std::hash and ==, no ordering, and rehashing invalidates iterators. Both allocate a node per element; for performance-critical code, flat hash maps (Abseil, Boost) store elements contiguously and are much faster.

What they are really testing: Data structures and complexity, plus knowledge of flat maps.

push_back(x) takes an existing object and copies or moves it into the vector. emplace_back(args...) constructs the element in place from constructor arguments, avoiding a temporary: v.emplace_back("Asha", 30) for a Person. For an object you already have, they are equivalent. Caveat: emplace_back can call explicit constructors, so std::vector<std::unique_ptr<T>> v; v.emplace_back(new T) compiles, and leaks if the vector's reallocation throws.

What they are really testing: In-place construction, and the explicit-constructor caveat.

The ranges library lets algorithms take whole ranges (std::ranges::sort(v)), adds projections (std::ranges::sort(people, {}, &Person::age)), and introduces views: lazy, non-owning adaptors composed with | (v | views::filter(pred) | views::transform(f)). Views compute elements on demand with no intermediate containers, and can be infinite (views::iota(1)). Pitfalls: a view must not outlive its underlying container, and some views cache state, so iterating a const view may not compile.

What they are really testing: Laziness, projections and lifetime pitfalls.

Passing arguments through a wrapper function while preserving whether each was an lvalue or an rvalue, so the inner call copies or moves exactly as a direct call would. It uses a forwarding reference (template <typename T> void wrap(T&& arg), where T is deduced) and std::forward<T>(arg). std::make_unique, emplace_back and std::thread's constructor all rely on it. T&& is only a forwarding reference when T is deduced in that very call.

What they are really testing: Forwarding references versus rvalue references.

const means "not modified after initialisation"; the value may be computed at run time. constexpr on a variable means it is computed at compile time and usable in constant expressions (array sizes, template arguments). A constexpr function can run at compile time when given constants, and at run time otherwise; consteval functions must run at compile time. Since C++20, constexpr allows loops, std::vector and std::string inside the function, so whole lookup tables can be built by the compiler.

What they are really testing: Compile-time versus immutability.

Virtual functions suit an open set of types: new derived classes can be added (even in plugins) without touching existing code, at the cost of heap allocation per object and indirect calls. std::variant suits a closed set known up front: values are stored inline with no allocation, std::visit dispatch can be inlined, and the compiler checks that every alternative is handled, but adding a type means editing the variant and every visitor. Adding operations is easy with variant and hard with inheritance, and vice versa.

What they are really testing: The open versus closed trade-off.

Provide equality (operator==, which can be defaulted in C++20) and a hash: specialise std::hash<Key> or pass a hasher type as the map's third template argument. Combine the members' hashes carefully (for example with a hash_combine function), and keep the hash consistent with equality: equal keys must hash equally. For std::map, provide operator< or a defaulted operator<=> instead.

What they are really testing: Hash and equality consistency.

Two threads access the same memory at the same time, at least one writes, and nothing orders the accesses. In C++ that is undefined behaviour, not just a wrong value. Prevent it by protecting shared data with a std::mutex (locked through std::lock_guard or std::scoped_lock), by using std::atomic for single variables, or by not sharing: give each thread its own data and combine results afterwards. ThreadSanitizer (-fsanitize=thread) detects races in tests.

What they are really testing: That a race is UB, RAII locking, and TSan.

A deadlock occurs when threads each hold a lock the other needs. Avoid it by always acquiring multiple mutexes in one global order, or by locking them together with std::scoped_lock(m1, m2), which uses a deadlock-avoidance algorithm. Hold locks for as short a time as possible, never call unknown code (callbacks, virtual functions) while holding a lock, and prefer designs such as message queues where only one thread owns each piece of data.

What they are really testing: Lock ordering, scoped_lock and design-level avoidance.

std::atomic<T> makes single operations on a value indivisible (fetch_add, compare_exchange) and visible across threads, without a mutex. By default operations are sequentially consistent, the easiest to reason about. Weaker orders (memory_order_acquire/release for publishing data from one thread to another, relaxed for plain counters) allow more optimisation but are easy to get wrong. Atomics protect one variable; invariants across several variables still need a mutex.

What they are really testing: Atomicity versus ordering, and not overusing relaxed orders.

Modern CPUs are dominated by memory access costs. A vector's elements are contiguous, so iteration streams through cache lines and the hardware prefetcher predicts the next access. A list scatters nodes across the heap: every step is a pointer chase and a likely cache miss, plus an allocation per element. So for typical sizes, a vector with O(n) insertion in the middle often beats a list's O(1) insertion, because finding the insertion point in the list is O(n) cache misses anyway. Measure before choosing a node-based container.

What they are really testing: Cache awareness over textbook Big-O.

Measure first, on an optimised build with debug symbols (-O2 -g) and realistic input. Use a sampling profiler (perf, Instruments, VTune, the Visual Studio profiler) to find the hot functions, then fix the biggest cost: a better algorithm or data structure first, then fewer allocations (reserve, reuse buffers, avoid copies), better memory layout, and only then micro-optimisations. Use Google Benchmark for micro-benchmarks, and verify each change with numbers.

What they are really testing: A measure-first process with tools.

Modern implementations use "zero-cost" table-based exception handling: no runtime cost on the path where nothing is thrown, but throwing is expensive (unwinding the stack, looking up handlers), and the tables increase binary size. So exceptions suit genuinely exceptional failures, not control flow in hot loops. Some domains (games, embedded, low-latency trading) disable exceptions with -fno-exceptions and use error codes or std::expected.

What they are really testing: Happy-path versus throw cost, and why some codebases ban them.

The ODR says each non-inline function and variable must have exactly one definition in the whole program, and inline functions, classes and templates defined in several translation units must be token-for-token identical. Violations: defining a non-inline function in a header included by two .cpp files (a "duplicate symbol" link error), or two different classes with the same name in different files (no error, silent undefined behaviour). Mark header function definitions inline, and put file-local helpers in an anonymous namespace.

What they are really testing: Both the loud and the silent violations.

std::thread starts a thread immediately; you must join() or detach() it before its destructor runs, or the program terminates. std::jthread (C++20) joins automatically in its destructor and supports cooperative cancellation through a std::stop_token, so it is the better default. std::async runs a function (possibly on a new thread) and returns a std::future for its result and exceptions; the future it returns blocks in its destructor until the task finishes.

What they are really testing: jthread as the RAII default, and the async future pitfall.