C++ interview - testing potential candidates.

Question

I have to interview some C++ candidates over the next few weeks and as the most senior programmer in the company I'm expected to try and figure out whether these people know what they are doing.

So has anybody got any suggestions?

Personally I hate being left in a room to fill out some C++ questions so I'd rather do a more complex test that I can chat with the interviewee about their approaches and so forth as we go along. ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me. I don't care whether they understand obscure features of the language but I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references. I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.

So any suggestions along these lines would be greatly appreciated!

Answer 1

This article offers some general ideas that are relevant regardless of what language you're working with.

Answer 2

Checkout Joel's Guerrilla guide to interviewing. Seems a lot like what you are looking for.

Answer 3

This one is a great complex task, even though it is looking quite harmless.

Answer 4

You can choose potentially problematic task and see how they approach it. Ask them to write a smart pointer for example, you'll see if they understand pointers, references and templates in one step :) Usually they are stressed so they will do mistakes, those mistakes might help you find out how good they problem solving skills are, what paths would they use to fix a mistake and so on. The only problem with this approach is that sometimes interviewee just don't know anything about the task and you would have to quickly figure out something easier. If they do perfect code you can discuss their choices but when there's nothing to look at it is depressing for both of you.

Answer 5

I wouldn't make them write code. Instead, I'd give them a couple of code snippets to review.

For example, the first would revolve about design by contract: see if they know what preconditions, postconditions and invariants are. Do a couple of small mistakes (never initialize an integer field, but assert that it is >0 in the invariant) and see if they spot them.

The second would be to give them bool ContainedIn(char * inString). Implement it with a trivial loop. Then ask whether there are any mistakes. Of course, your code here does not check for null in the input parameter in_string (even if the very previous question talked about preconditions!). Also, the loop finishes at character 0. Of course, the candidate should spot the possible problems and then insist in using std::string instead of this char * crap. It's important because if they do complain, you'll know that they won't add their own char *'s to new code.

An alternative which addresses STL containers: give them a std::vector and code which searches for prime numbers or counts the odd numbers or something. Make some small mistake. See if they find any issues and they understand the code. Ask in which situation a std::set would be better (when you are going to search elements quite systematically and original order of entrance doesn't matter.).

Discuss everything live, letting them think a couple minutes. Capture the essence of what they say. Don't focus on "coverage" (how many things they spot) because some people may be stressed. Listen to what they actually say, and see if it makes any sense.

I disagree with writing code in interviews. I'd never ask anyone to write code. I know my handwritten code would probably suck in a situation like that. (Actually, I've seldom been asked to do so, but when I have, I haven't been hired.)

Answer 6

I believe that a C++ programmer needs more than just generic programming skills, because...

In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.

Writing bug-free, maintainable C++ code places a much higher demand on a few areas than most languages.

One thing I'll call "pedanticness". You know how some people can spot spelling errors in something at a glance? A C++ programmer needs to be able to spot simple bugs while they read or write code (whether the code is their own or not). A programmer who relies on the "compile and test" technique just to get rid of simple bugs is incompatible with the C++ language, because those bugs don't always lead to immediate failure in C++.

C++ programmers also need a good knowledge of low-level stuff. Pointers, memory allocators, blocking, deadlocks. And "nitty gritty" C++ issues, like multiple inheritance and method hiding and such, particularly if they need to maintain other people's code.

Finally, C++ programmers need to be able to write code that's easy for other people to use. Can they design stuff well?

A good test for the first two areas is "Here's some C++ code I got off the internet. Find the bugs, and identify the unneccessary bits." (There's lots of really bad C++ code available on the internet, and often the programmer does unnecessary things due to a faulty understanding of how to be "safe" in C++.)

The last area you can test with more generic interview questions.

Answer 7

Depending on what your organisation's pre-screening is like, assume that the person knows nothing at all about C++ and has just put in on their CV because it makes them look supertechnical. Seriously. Start with something simple, like reversing a string. I have had candidates who couldn't even write a function prototype for this !!

Answer 8

Whatever you do, pairing would be a good idea. Come up with a good program and pair with the guy and work towards solving the problem. IMHO, that a very good idea

Answer 9

Do not forget to also test for code bigotry. I know I don't want anyone working for or with me that isn't a flexible and consequently practical programmer both in their attitude to the programming language, but also in their approach to problem solving.

• Denying any type of preconceptions
• Understanding the value of the exceptions in any Best Practices
• Being capable of refusing long term habits in favor of something else if the need arises

These are characteristics dear to me. The manner of testing for these is not ideal if the interviews aren't lengthy or don't involve presenting code. But showing code snippets with purposely debatable techniques while offering a use case scenario and asking the candidate how they feel about the solution is one way.

Answer 10

Here is my answer to a similar question geared towards C#, but notice that my answer is language agnostic. My interview question is, in fact, in C. I rarely interview a person with the goal of finding out if they can program. I want to find out if they can think, problem solve, collaborate, communicate, understand something new, and so on. In the meantime, I circle around trying to see if they "get it" in terms of the big picture of software engineering. I use programming questions because that's a common basis and an easy ruse.

Answer 11

So has anybody got any suggestions?

I'd recommend getting a copy of this:

http://www.amazon.co.uk/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=sr%5F1%5F1?ie=UTF8&s=books&qid=1252499175&sr=8-1

ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me

You could ask the candidate to come up with a UML design to a common problem. If they show you a design pattern, then you can talk through the pros/cons of the pattern. You could then ask them to produce some code for one of the classes.

This would help you determine their technical knowledge level and their communication abilities.

I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references

Linked list problems are good for determining whether a candidate has a solid grasp of pointers.

As for references, you could show them some code that does not use references correctly, and ask them to describe the problem.

e.g show them a class definition that contains a reference member variable, and the implementation of the constructor with the reference initialization missing.

I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.

I'd start off simple...

Show them a code example that passes strings to a function by value. (the strings should not be modified in the function). You should check they correct the code to pass the strings by const reference.

After this, you could show a constructor that uses assignment instead of initialization (for objects). Ask them to improve it.

Lastly, ask them simple questions about data structure selection.

e.g. When they should use a list rather than a vector.

If you feel they have a grasp of the fundamentals you could either ask how they approach optimization problems (discuss profilers etc), or ask them to optimize something less obvious.

Answer 12

Don't test only the C++ and overall technical skills! Those are of course important, but they are nothing if people don't listen, don't answer properly or don't follow the commitments they made.

Check at most for the ability to clearly communicate. If people cant tell you what roughly they did in their former jobs within a few minutes, they will also be unable to report about their work at your place etc.

In a recent company we invited people for interviews in groups of about 3 people together. They were surprised, but nobody was angry about that. It was very interesting, because people had to communicate not only with us, but also with others in the same position. In case we were interested further, we arranged a second interview.

Answer 13

A few questions can allow you to know a lot about a candidate:

• Differences between a pointer and a reference, when would you use each?
• Why would you make a destructor virtual?
• Where is the construction order of a class attributes defined?
• Copy constructor and operator=. When would you implement them? When would you make them private?
• When would you use smart pointers? what things would you take into account to decide which?
• Where else have you seen RAII idiom?
• When would you make a parameter const? when a method?
• When would you make an attribute mutable?
• What is virtual inheritance?
• What is template specialization?
• What are traits?
• What are policies?
• What is SFINAE?
• What do you know about C++Ox standard?
• What boost libraries have you used?
• What C++ books have you read? (Sutter? Alexandrescu?)

Some short exercises (no more than 10 minutes) about STL containers, memory management, slicing, etc. would also be useful. I would allow him to do it in a computer with a ready environment. It's important to observe the agility.

Answer 14

"Write a program that receives 3 integers in the range of 0..2^32-1, and validates if they represent valid edges of a triangle".

It seems to be a simple question. The input is considered valid if the sum of any two edges is greater than the third edge. However, there are some pitfalls, that a good programmer will handle:

• The correct type to use should be unsigned long. Many "programmers" will fail here.
• Zero values should be considered as non-valid.
• Overflow should be avoided: "if (a+b <= c) return false" is problematic since a+b may cause an overflow.
• if (a <= c-b) is also bad solution since c-b may be negative. Not a good thing for unsigned types.
• if (c > b) { if (a <= c-b) return false; } else { if (a <= b-c) return false; } This is much better.

A good programmer must be detail oriented. This simple exercise will help checking if he is.