C++ Interview: 7 Traps That Trip Up 90% of Candidates

Why Does C++ Still Scare Even Senior Developers?

C++ is a language that gives you full control over memory, but only until you forget a semicolon or accidentally call a virtual function from a constructor. C++ interviews are notorious for their harshness: you can be asked about bit fields, the structure of the virtual table, and the intricacies of std::move. If you're preparing for a technical interview, this article is your checklist. We'll break down the trickiest topics that are almost guaranteed to come up in an interview and show you how to answer them to avoid failing.

On the educational portal PythonLib, we often discuss how to transition from Python to C++ and vice versa. But today, it's pure C++. No compromises.

1. Virtual Functions and VTable: How to Avoid the Trap

Question: "What happens if you call a virtual function from a base class constructor?" — a classic. 70% of candidates answer incorrectly. Let's figure it out.

Why is this dangerous?

When you call a virtual function in a base class constructor, the derived class object hasn't been created yet. The virtual table (VTable) at that moment points to the base class methods, not the derived class's. As a result, polymorphism doesn't work.

#include <iostream>\n\nclass Base {\npublic:\n    Base() { callFoo(); }  // Call in constructor\n    virtual void foo() { std::cout << "Base::foo\\n"; }\n    void callFoo() { foo(); }\n};\n\nclass Derived : public Base {\npublic:\n    Derived() {}\n    virtual void foo() override { std::cout << "Derived::foo\\n"; }\n};\n\nint main() {\n    Derived d;  // Outputs: Base::foo, not Derived::foo\n    return 0;\n}

Conclusion: never call virtual functions in constructors or destructors. If the interviewer asks, confidently explain the VTable mechanism.

2. Smart Pointers: RAII and Memory Management

No serious C++ interview is complete without this topic. Questions about std::unique_ptr, std::shared_ptr, and std::weak_ptr are basic. But they often ask about circular references and std::enable_shared_from_this.

How to avoid a memory leak with shared_ptr?

Imagine you have two objects that reference each other via shared_ptr. The reference count will never reach zero — memory will leak. Solution: one of the pointers should be a weak_ptr.

#include <memory>\n#include <iostream>\n\nstruct Node {\n    std::shared_ptr<Node> next;\n    std::weak_ptr<Node> prev;  // Weak reference to avoid a cycle\n    ~Node() { std::cout << "Node destroyed\\n"; }\n};\n\nint main() {\n    auto a = std::make_shared<Node>();\n    auto b = std::make_shared<Node>();\n    a->next = b;\n    b->prev = a;  // weak_ptr does not increment the counter\n    // When leaving scope, both nodes are correctly destroyed\n    return 0;\n}

In an interview, be sure to mention the RAII (Resource Acquisition Is Initialization) concept — it's the C++ philosophy that ties a resource's lifetime to an object's lifetime.

3. Move Semantics and std::move: Magic or a Trick?

A typical question: "What does std::move do?" The answer "it moves an object" is incorrect. std::move merely casts the type to an rvalue reference. The actual move happens in the move constructor or move assignment operator.

Example for an interview

#include <string>\n#include <vector>\n#include <iostream>\n\nclass MyString {\n    std::string data;\npublic:\n    MyString(const std::string& s) : data(s) {}\n    // Move constructor\n    MyString(MyString&& other) noexcept : data(std::move(other.data)) {\n        std::cout << "Move constructor c