If you are taking an interview of an candidate without any prior work experience and want to find out how good he/she is in C++ what are the areas you generally look for ?

23 accepted

I'd probably look into these areas:-

  • Constructors and Destructors (incl. copy constructors!)
  • RAII
  • Exceptions
  • Assignment operator
  • New/Delete/New[]/Delete[] vs malloc/free
  • STL containers
  • Smart Pointers : why, how and when

If the candidate has no prior work experience, you can be sure that there will be a lot of learning in the first year.

Focus less on C++ trivia and more on how hungry he is and how quickly he can apply new concepts.

Find a topic he's not familiar with...vtables or some boost object or design pattern and give him an explanation. Then see if he can make use of that concept in front of you. This will tell you far more about how an effective an employee he will be.


I'm copy-pasting what I've said in the past:

I'm not very fond of too precise and syntax oriented questions.

I'd rather have someone that understands major principles like semantics, LSP, RAII, the most widely used patterns, ... than someone that knows the syntax of custom pre- and post-increment operators, how new/delete operators are overidden, or whatever stuff we never do more than once every 2 years.

I guess I would ask to complete a poorly designed set of classes (of course I'll never say the class are poorly designed) to implement whatever algorithm.

If he immediatelly points out the design flaws and explains what should have been done, I'll be quite happy. Otherwise, any newcomer in C++ world should be able to implement what has been asked without feeling down or disturbed by very complex and jargon-oriented questions he is not able to answer. (C++ has a very precise jargon, and many details are more easily explained when we are fluent in its jargon).

Regarding the design flaws, I'll try to hide things like : - more than two raw ressources in a class, - provide copy-semantics on an entity-semantics oriented class (typically within a hierarchy of polymorphic classes), - use public inheritance for anything but LSP, - ...

=> have something that looks simple, and that permits to test newcomers as well as experimented C++ developpers.

Regarding development, there are many other things to check. As it has been said: a talented developper may have not been initiated to C++ intricacies.

If the person is reconverting from a language to C++, he should at least be able to point out the syntaxic and idiomatic differences between the two languages, and to write down algorithms in a semi-C++/semi-natural dialect.


I wouldn't ask any language specific questions. A language is just a tool a qualified candidate can learn to use pretty fast.

Problem solving skills and how a candidate adapts to new situations/tools/requirements is much more important.


Definitely a question about copy constructors... if they get that, you can be pretty confident they know something about C++


I'd say that, when you generally hire a programmer you should never look for "how much does this person know at the moment". You should rather look for "how much can this person grow".

There are many programmers that are skilled at i.e. c++ but they do lack a lot of ther aspects, such as taking in newer perspectives and it's one of the, imo, most important thing when hireing someone.

If the person likes programming, have easy to learn and able to communicate programming on a professional basis, then it doesnt matter if they know everything.

However, when looking for a Programmer i always assume they know OOP and how to adapt it.


I always ask the diff of new/delete and free/malloc. Also how the templates work.


I'd ask them to solve some simple programming problems using C++, that shows whether or not they can actually program, and if they are actually familiar with C++.

Get them do do something, talk is cheap.


I've found myself dividing C++ interview questions into certain categories. Of these, many interviewers only touch on fundamentals and details. Junior candidates like those this question asks about can only be expected to know some of this, but you definitely want to see that they've attacked it with some enthusiasm.

It's hard to find people who've made a systematic, broad investigation of the how-tos of C++ programming at the low-level library level (where the most ingenuity is generally required), and equally hard to find people who know what to do in terms of large-scale design and architecture trade-offs. Very roughly - just to illustrate these factors - I've compiled some examples:

  • FUNDAMENTALS: basic knowledge you must have to use the language
    • the what, how, why of class, object, pointers, functions, headers, templates, virtual functions, const & mutable, stack/heap, static...
  • DETAILS: the stuff that's normally just below the surface but occasionally gives rise to questions (the kind of stuff needing an answer from the C++ FAQ lite)
    • what're the performance/memory implications of inlining, of virtual dispatch...
    • throwing from destructors
    • Liskov Substitution Principal
    • RAII
  • HOW TO: generic practical programming tasks that even good programmers might not be able to do fully off the top of their heads, but should be able to be helped through with minimal pain - sorts the reusers of canned solutions from those who understand the implementation issues, e.g.
    • variants
    • functors
    • SFINAE tests for member functions
    • hash table or binary tree
    • thread pools
    • simple design patterns: visitor, observer, pub/sub, factories etc.
    • how do you debug certain types of issues: race conditions, deadlocks
    • multiple processes want shared in-place access to objects in shared memory: how can you provide runtime polymorphism (virtual dispatch) for the objects
    • design a non-templated function f(X&) and template <class A, class B> struct T such that f can accept any object of type T and handle them via virtual dispatch
  • WHAT TO: stuff that requires practical insight/experience: for example...
    • contrast the utility of templates and virtual dispatch
    • discuss approaches to serialisation/deserialisation in C++
    • compare Design By Contract with Defensive Programming
    • discuss physical dependencies (changes triggering/needing recompilation)
    • contrast factors in / approaches to testability: e.g. templatised code, abstract interfaces, derivation versus composition, #ifdefs

Also, it goes without saying that, regardless of the language, they should write some actual code for you.


I would ask a simple question involving pointers. Amazingly enough that very quickly separates people who do know C++ from those who only say they do.


I would start with rudimentary questions about pointers and memory. Try to figure out if they know the difference between pointers and a references. Then go on with constructors, destructors, inheritance, exceptions, const, well the basics.

After that I'd ask something on common design patterns, such as RAII, visitor pattern, factory pattern, adapter pattern, and so on.

Probably I'd go for a small programming exercise.



Besides discussing the things Roddy has listed, make sure you see hwo they tackle an actual function to write. The point is not a pass/fail for the one correct solution, but watching the candidate as he develops the code. Thinking ahead, asking for clarification, style, handling error coditions etc.

If you are an inexperienced interviewer, this helps a lot to convince you that "maybe's" are actually "no hire's" - at least when the "surprises" I've seen are standard fare. (see also Joels guide V.3 on maybe ==> no)

Technically: Have two or three simple problems ready, that you understand well, and can be solved in about ten to twenty "normal" lines of code, but has a few conditions to check against. (For C++, some String processing is a good idea). One task is usually enough, have a second one ready in case the candidate totally fails or excels at the first,: in both cases, you didn't have a chance to watch the process.

Put it towards the second half of the interview, encourage the candidate and try to put him at easy (if that's even possible during an interview).


1) Ask them, that when they don't know the answer to a problem, where they would look for the answer.

2) How to design programs that can easily be tested (e.g. unit tests, test-driven development)


Give his a simple agile story to implement in C++. This is what I do at my company. The guy gets a simple (fake)interface to the db he/she has to implement, few unit tests that document the (initial)requirements and that's it. Tell the applicant that for this interview we are all one team, this will encourage him to ask question. Asking questions is important so you need to check this out. After he/she completes the task, change some requirement to see if the code scales or it's a legacy code already...

During this kind of story you can check:

  • basic and advanced C++
  • use of STL
  • use of Boost
  • use of design patterns
  • familiarity with interfaces
  • familiarity with design principles
  • unit testing and writing testable code

I give a guy a laptop with prepared project in VS 2008 Express and I have an extra monitor set to close to actually see what the guy is doing and give tips, ask question etc. I did this style of interview over 10x and it's great.



It really depends on what you are looking for. The skill set for application programmers are much less demanding than that for library and framework writer.

For application programmers: RAII (vs new/new[]/delete/delete[] vs malloc/free), standard library (STL/boost) usage, exception handling etc., besides generic algorithm/problem solving.

For library/framework creator/maintainers: in addition to above areas, virtual inheritance in multiple inheritance (most other popular languages do not have MI) and construction order; copy constructor and assignment (gotchas), destructor (why it should be virtual for any polymorphic classes), the concept of iterator and how it enables generic algorithms, template (concept of partial specialization, metaprogramming, let's face it, template is what gives performance and expressiveness to modern C++ libraries.)

It's much harder to find a competent library/framework programmer than a application programmer.


To understand their knowledge of memory allocation and layout, ask them how to dynamically allocate memory for 2 dimensional array.

int **data = null ;
// write code to dynamically allocate and initialize memory for 2 dimension array of size 10X15
// Now use the 2 dimension array
int a = data[3][2] ;

Personally, I believe that the most important questions involve dynamic binding and typing. Questions such as "what will be invoked in situation X" can really help identify potential employees who will potentially use inheritance well, and those that passed their CS courses with enhanced C skills without truly understanding OOP. I think that the focus on operator overloading and minor differences from C doesn't identify good developers.

Also, While I haven't interviewed anyone, a common pattern that I have seen in good organizations is a trick question where you are given code that passes parameters by value where they should obviously be passed by reference, to see if you catch it.


Ask something about exceptions in constructors, nobody knows this well.


If they are new grads, you might want to see if they learned what they were supposed to in school - as this is probably a good indicator of what kind of employee they will be - i.e. hungry/passionate, etc.

You might break out some fundamental computer science questions and see how they handle those before moving into language specific questions (which I think are very necessary with C++).