C++ interview questions

What a strong answer covers

• Define pointers as variables holding memory addresses, allowing null values and reseating.
• Define references as aliases to existing objects, requiring initialization and disallowing null or reseating.
• Discuss use cases: Pointers for dynamic memory, optional parameters, C-style arrays; References for function parameters (pass-by-reference), operator overloading, avoiding copies.
• Mention safety aspects: References are generally safer due to non-null and non-reseatable properties.

Where people lose the point

• ×Confusing syntax or claiming references can be null or reseated.
• ×Failing to mention the performance implications (avoiding copies) for references.
• ×Not discussing the 'ownership' aspect often associated with raw pointers vs. non-owning references.

What a strong answer covers

• Explain `const` with variables (compile-time constant, read-only).
• Discuss `const` with pointers: pointer to `const` data (`const int* p`), `const` pointer (`int* const p`), and `const` pointer to `const` data (`const int* const p`).
• Detail `const` with function parameters (pass-by-const-reference/pointer to prevent modification).
• Explain `const` member functions (guaranteeing the function won't modify the object's state) and `mutable` keyword.

Where people lose the point

• ×Incorrectly distinguishing between `const int* p` and `int* const p`.
• ×Forgetting to mention `const` member functions and their importance for `const` objects.
• ×Not explaining the 'bitwise constness' vs 'logical constness' concept implicitly.

What a strong answer covers

• Define stack memory: automatic allocation/deallocation for local variables, function calls; fixed size, fast access.
• Define heap memory: dynamic allocation/deallocation via `new`/`delete`; flexible size, slower access, potential for fragmentation.
• Discuss use cases: Stack for small, fixed-size, short-lived data; Heap for large, variable-size, long-lived data (e.g., objects whose lifetime extends beyond function scope).
• Mention risks: Stack overflow, heap memory leaks, fragmentation, dangling pointers.

Where people lose the point

• ×Confusing the allocation/deallocation mechanisms for stack vs. heap.
• ×Failing to mention the speed difference or size limitations.
• ×Not connecting heap memory to `new`/`delete` or smart pointers.

What a strong answer covers

• Define virtual functions as member functions declared with the `virtual` keyword in a base class, allowing derived classes to override them.
• Explain how they enable runtime polymorphism (dynamic dispatch) when calling a function through a base class pointer or reference.
• Describe the 'virtual table' (vtable) as a mechanism used by the compiler to resolve virtual function calls at runtime.
• Discuss the overhead associated with virtual functions (vtable lookup, increased object size).

Where people lose the point

• ×Confusing compile-time (static) polymorphism with runtime (dynamic) polymorphism.
• ×Incorrectly stating that virtual functions work with objects directly (they require pointers/references).
• ×Failing to mention the performance implications or the concept of object slicing without pointers/references.

What a strong answer covers

• Define RAII: a programming idiom where resource acquisition is tied to object initialization, and resource release is tied to object destruction.
• Explain its purpose: to guarantee proper resource management (e.g., memory, file handles, mutexes) even in the presence of exceptions.
• Provide an example using `std::unique_ptr` or `std::lock_guard` to demonstrate automatic resource cleanup.
• Discuss how constructors acquire resources and destructors release them.

Where people lose the point

• ×Only mentioning memory management and not other resources like file handles or locks.
• ×Failing to emphasize the 'guarantee' of cleanup even with exceptions.
• ×Not providing a concrete C++ example of RAII in action.

What a strong answer covers

• Describe `std::unique_ptr`: exclusive ownership, non-copyable (movable), lightweight, ideal for single ownership.
• Describe `std::shared_ptr`: shared ownership, reference counting, copyable, resource released when last `shared_ptr` goes out of scope.
• Discuss use cases: `unique_ptr` for local scope, factory functions returning ownership; `shared_ptr` for multiple owners, complex object graphs.
• Explain `std::weak_ptr`: non-owning observer, used with `shared_ptr` to break circular references and prevent memory leaks.

Where people lose the point

• ×Confusing the ownership semantics or copyability of `unique_ptr` and `shared_ptr`.
• ×Not explaining *why* `weak_ptr` is needed (circular references).
• ×Failing to mention the overhead of `shared_ptr` (reference count, control block).

What a strong answer covers

• Define lvalues as expressions that refer to a persistent object (e.g., named variables, `*p`).
• Define rvalues as expressions that refer to a temporary object or value (e.g., literals, function return values, `x+y`).
• Explain move semantics: transferring resources from a temporary (rvalue) object to a new object instead of deep copying.
• Describe rvalue references (`&&`) as the mechanism to bind to rvalues, enabling move constructors and move assignment operators, and how `std::move` facilitates this.

Where people lose the point

• ×Incorrectly identifying lvalues and rvalues in examples.
• ×Claiming `std::move` actually moves data, rather than just casting to an rvalue reference.
• ×Not explaining the performance benefit (avoiding deep copies) or the 'valid but unspecified' state of moved-from objects.

What a strong answer covers

• Define templates as a feature for generic programming, allowing functions and classes to operate on generic types.
• Discuss function templates and class templates, providing simple examples for each.
• Explain template specialization (full and partial) as a way to provide a different implementation for specific types or categories of types.
• Provide scenarios for specialization: performance optimization for specific types, handling types that don't fit the generic implementation, or providing specific behavior for pointer types.

Where people lose the point

• ×Confusing templates with polymorphism (runtime vs. compile-time).
• ×Failing to explain *why* specialization is needed (e.g., generic code doesn't work or isn't optimal for a specific type).
• ×Not distinguishing between full and partial specialization.

What a strong answer covers

• Describe `std::vector`: dynamic array, contiguous memory, O(1) random access, O(N) insertion/deletion in middle, O(1) amortized push_back.
• Describe `std::list`: doubly linked list, non-contiguous memory, O(N) random access, O(1) insertion/deletion anywhere (given iterator).
• Discuss memory locality and cache performance: `vector` generally better due to contiguous memory.
• Recommend use cases: `vector` for random access, frequent appending; `list` for frequent insertions/deletions in the middle, stable iterators.

Where people lose the point

• ×Incorrectly stating random access complexity for `std::list`.
• ×Failing to mention iterator invalidation rules for each container.
• ×Not discussing memory overhead or cache performance implications.

What a strong answer covers

• Define a pure virtual function as a virtual function declared with `= 0` in the base class, having no implementation.
• Explain that a class containing at least one pure virtual function becomes an abstract class, which cannot be instantiated directly.
• Discuss the purpose: to define an interface or contract that derived classes *must* implement.
• Provide use cases: creating an interface, enforcing a common behavior across a hierarchy, designing frameworks.

Where people lose the point

• ×Confusing pure virtual functions with regular virtual functions.
• ×Claiming an abstract class can be instantiated.
• ×Not clearly explaining the 'contract' or 'interface' aspect.

What a strong answer covers

• Define operator overloading as giving special meaning to operators when applied to user-defined types.
• Discuss common operators that can be overloaded (e.g., `+`, `-`, `*`, `[]`, `<<`, `>>`).
• Explain rules: cannot overload operators for built-in types, cannot create new operators, precedence/associativity remain unchanged.
• Outline best practices: maintain natural semantics, return by value for arithmetic, return by reference for assignment, use non-member functions for binary operators where possible.

Where people lose the point

• ×Attempting to overload operators like `.` or `::`.
• ×Not adhering to natural semantics, leading to confusing code.
• ×Incorrectly choosing between member and non-member functions for overloading.

What a strong answer covers

• Explain the Rule of Three (C++98): If you define a custom destructor, copy constructor, or copy assignment operator, you likely need to define all three.
• Extend to Rule of Five (C++11): With move semantics, if you define any of the above, you should also define a move constructor and move assignment operator.
• Discuss the rationale: These special member functions handle resource management (e.g., dynamic memory) and ensure correct behavior during copying, moving, and destruction.
• Introduce the Rule of Zero (modern C++): Prefer to avoid defining any of these by using RAII and smart pointers, letting the compiler generate them or explicitly deleting them.

Where people lose the point

• ×Only mentioning the Rule of Three and not the Rule of Five/Zero.
• ×Failing to connect the rule directly to resource management.
• ×Not explaining *why* these functions are needed together (e.g., deep copy vs. shallow copy issues).

What a strong answer covers

• Explain `static` with local variables: retains value between function calls (static storage duration).
• Discuss `static` with global variables/functions: limits scope to the current translation unit (internal linkage).
• Detail `static` with class members (data members): shared by all objects of the class, belongs to the class itself.
• Explain `static` with class members (member functions): can be called without an object, cannot access non-static members.

Where people lose the point

• ×Confusing the meaning of `static` in different contexts (e.g., local vs. class member).
• ×Incorrectly stating that static member functions can access non-static data.
• ×Failing to mention the 'internal linkage' aspect for global static variables/functions.

What a strong answer covers

• Discuss traditional error handling methods: return codes, `errno`, `assert` (for debug).
• Explain exceptions: a mechanism to signal and handle runtime errors that cannot be handled locally.
• Describe `try`, `catch`, `throw` keywords and their roles in exception handling.
• Outline benefits: separation of error-handling code from normal logic, propagation of errors up the call stack, handling of constructor failures.
• Mention best practices: throw by value, catch by const reference, use RAII to prevent resource leaks, avoid throwing exceptions from destructors.

Where people lose the point

• ×Not mentioning RAII as a critical component for exception safety.
• ×Incorrectly stating that exceptions are always faster than return codes.
• ×Failing to discuss the overhead of exceptions or when not to use them (e.g., expected errors).

What a strong answer covers

• Define `const_cast`: used to add or remove `const` or `volatile` qualifiers from a pointer or reference.
• Explain its primary use case: calling a non-`const` function on a `const` object when you know it won't actually modify the underlying data, or when interacting with legacy APIs.
• Define `reinterpret_cast`: converts any pointer type to any other pointer type, or an integer type to any pointer type and vice-versa.
• Explain its purpose: low-level type punning, converting between unrelated types, often used for hardware interaction or specific memory layouts.
• Discuss dangers: `const_cast` can lead to undefined behavior if used to modify an object originally declared `const`; `reinterpret_cast` offers no type safety and can easily lead to undefined behavior, alignment issues, or security vulnerabilities.

Where people lose the point

• ×Confusing the specific use cases or limitations of each cast.
• ×Understating the severe dangers and potential for undefined behavior.
• ×Not mentioning that `const_cast` can only modify `const` or `volatile` qualifiers, not other types.