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

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

For example, the first would be about design by contract: See if they know what preconditions, postconditions and invariants are. Do a couple of small mistakes, such as never initializing an integer field but asserting that it is >= 0 in the invariant, and see if they spot them.

The second would be to give them bool contains(char * inString, char c). 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 inString (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 insist on 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 containers: give them a std::vector<int> 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 have seldom been asked to do so, but when I have, I haven’t been hired.