Questions not to hinge a C++ interview on

People love to chat about how to conduct a C++ interview on newsgroups.  Eventually these topics will shift into a discussion about what questions a candidate must know in order for them to get a hire from a particular interview.  Unfortunately these questions tend to be items like the following.

  1. What happens when you delete NULL?
  2. Explain how exceptions affect constructor initialization.
  3. Which constructors are called for the following: SomeType a = SomeType(b);

Sure these questions are valid parts of the language and knowing them is a plus and demonstrates a deal of mastery over the language.  But not knowing them should by no means by a deal breaker.  The goal of an interview is to spot good developers who will become a contributing member of the team.  Good developers are motivated and passionate problem solvers.  These questions are testing little more than memorization.  It’s easy to memorize rules after the fact.  It’s much more difficult to teach problem solving skills. 

The problem with questions like the above is that a developer could be both passionate and competent in C++ and never have come across these rules.  C++ is an unbelievably huge language and can operate in many different ways where these type of situations simply don’t come up.  For instance, I’ve known several very good C++ developers that spent the majority of their time working with COM.  COM prefers HRESULTs to Exceptions and hence they never used exceptions in C++.  Once we introduced exceptions into the code base, it took about 30 minutes to explain the rules and we were done. 

C++ interviews should focus on the qualities that make a good developer: problem solving and passion.  Of course a language based interview should certainly focus on the foundations of C/C+.  Items like pointers, stack vs. heap and the basics of memory management.  But don’t hinge the deal on little items that can be quickly taught.  Otherwise you’ll end up turning away good developers. 

Comments (7)

  1. Tom says:

    I have to disagree with you on this one.  In my opinion, I expect a professional to have mastery of his/her tools.  C++ is a complex language, and it is very counterproductive to hire someone with only shallow knowledge of it.  That person is doomed to run into lots of problems in C++ that could be avoided by taking the initiative to read a few C++ books.  Taking that initiative is another sign of a proactive developer (good) versus a passive one (not so good).

  2. jaredpar says:


    The problem is that not knowing a few particular rules is not a good indicator of the depth to which the person knows the langauge.  C++ is an unbelievably huge language.  It’s quite possible for passionaite and curious developer to spend a good deal of time in the language but not hit the particular points asked in an interview.  

    I already mentioned the exception example.  Another one I tend to run into is template specialization.  One of the best C++ programmers I’ve worked with was baffled the first time I sent out a template specialization embedded in a feature.  But once again it took ~10 minutes to explain the feature and we were off again.  His lack of knowledge in that area was not a sign of lack of passion.  Quite the contrary, he can still whip out name resolution and STL rules that most people aren’t aware of.  Instead it was just an area of the language he was not introduced to.  

  3. Nemanja Trifunovic says:

    Depends on a position. If a senior programmer with 10+ years of C++ experience does not know that delete NULL is a no-op, that is a problem.

  4. Dmitry says:

    [16.7] Do I need to check for NULL before delete p?


    There is nothing wrong with deleting NULL.

  5. fb says:

    I have been programming in C++ since I was 10 years old, and I am 24 now, doing my Ph.D. in computer science. I would have gotten most of these questions wrong, despite having written hundreds of thousands of lines of C++ on every platform imaginable, ranging from compilers, to 3d engines, to fluid dynamics simulators, to signal classification systems.

    For example, my guess would have been that deleting NULL was undefined and would crash. In the last few years of writing C++ I have barely used pointers at all, but instead just rely on STL vectors to manage everything automatically. This is a great way to avoid memory leaks. As such, I would never write code where it was even possible to delete a NULL pointer.  

  6. EricLippert says:

    Of course, it depends on the job being interviewed for. Our team is in a bit of an odd spot as we do both lots of developement in C++, and are designing a language which in many ways attempts to address the shortcomings of C++, and are implementing a compiler for that language.

    When I interview a C++ dev, I don’t expect them to have an encyclopaedic knowledge of the ANSI specification, but I do like to see that they can tell me what happens when you call a virtual method in a constructor, _why_ those semantics were designed that way, and _how_ the compiler generates code that implements them. That’s a higher bar than merely being able to write programs in C++.