C++ Interview Questions for AI Training Work

A pointer can be reassigned to point at a different object, can be null, and requires explicit dereferencing with `*`. A reference must be bound to a valid object at creation, can never be reseated to refer to something else afterward, and is used with normal variable syntax, no dereferencing needed. References are generally preferred when you know the referent will always exist, since they eliminate the null-check and rebinding cases pointers require.

RAII, Resource Acquisition Is Initialization, ties a resource's lifetime to an object's scope: the resource is acquired in the constructor and released in the destructor, which runs automatically when the object goes out of scope, even if an exception is thrown. This is how C++ avoids leaks without garbage collection, `std::unique_ptr` and `std::lock_guard` are both RAII wrappers around a raw resource, a heap allocation and a mutex, that would otherwise need manual cleanup at every exit path.

`unique_ptr` represents sole ownership: only one `unique_ptr` can own a given object at a time, and ownership can be transferred but not copied. `shared_ptr` uses reference counting to allow multiple owners, the underlying object is destroyed only once the last `shared_ptr` referencing it goes out of scope. `unique_ptr` should be the default choice unless shared ownership is genuinely needed, since reference counting adds runtime overhead `unique_ptr` doesn't have.

Stack allocation is essentially just moving a stack pointer, extremely fast, and memory is automatically reclaimed when the enclosing scope ends. Heap allocation via `new` involves the allocator finding a suitable free block, which is slower and requires explicit or smart-pointer-managed deallocation. Stack allocation is preferred whenever an object's lifetime naturally matches its scope; heap allocation is needed when an object must outlive the scope it was created in or its size isn't known at compile time.

Undefined behavior means the language standard places no requirements on what happens, the compiler is free to do anything, including something that looks like it works until it doesn't. A common accidental example is reading from an uninitialized variable, or accessing a `std::vector` past its bounds with `operator[]`, which doesn't do bounds checking, unlike `.at()`, which throws an exception instead of silently reading invalid memory.

I'd reach for a tool like Valgrind's memcheck or AddressSanitizer to catch allocations that are never freed, rather than manually auditing every `new`/`delete` pair in a large codebase. If the codebase already uses smart pointers consistently, the more likely culprit is a reference cycle between two `shared_ptr`s keeping each other alive, which I'd look for specifically, since that's a leak pattern smart pointers alone don't prevent.

I wouldn't try to convert the whole codebase at once. I'd start with the highest-risk areas, code with early returns or exceptions between a `new` and its matching `delete`, since those are the spots most likely to actually leak, and replace those specific allocations with `unique_ptr` or `shared_ptr` first. Converting incrementally, starting from actual risk rather than doing a mechanical find-and-replace everywhere, keeps each change reviewable and testable on its own.

I'd check whether objects are being passed by value where a reference or `const` reference would do, since pass-by-value triggers a copy constructor call on every invocation. I'd also check whether the code is using `push_back` in a way that causes repeated vector reallocation and copying, in which case reserving capacity upfront with `.reserve()` or using `emplace_back` to construct in place can cut a meaningful amount of that overhead.

A crash happened intermittently, always in unrelated-looking code, which is a classic symptom of heap corruption from writing past the end of an allocated buffer somewhere else entirely. Running the program under AddressSanitizer caught the actual out-of-bounds write immediately, at the real source, instead of where the corrupted memory eventually crashed. It reinforced that intermittent, seemingly-unrelated crashes are worth reaching for a memory sanitizer on early, rather than debugging by inspection first.

I avoided a virtual function on a hot path called millions of times per second in favor of a template-based static dispatch, since the virtual call's indirection was measurably showing up in profiling at that call volume. A reviewer flagged it as unusual style, so I shared the profiling data showing the actual cost difference, since the choice needed to be justified by a measured number, not just an assumption that virtual calls are inherently too slow to use.