This is not a test
There is a difference between a test and an interview. I consider tests to be offline - i.e. it can be done by the candidate alone in a room, the results are compiled later by a corrector. Tests are of course very useful, but I think they are even harder to design, especially if you don't want them to last 8 hours.
I always ask the candidate to speak to me while he's writing code. Especially when he's changing his mind and uses the eraser. The whole point is know how he thinks. When he's heading down a wrong path, stop him. Ask questions. Can he understand what's wrong?
Don't do this at home
I mean ; if you are trying to raise the bar at your company, don't design the interview questions alone. Ask your fellow programmers to help. The implicit question is : what's necessary to know to work here? What's the strict minimum one person can master and be helpful? I expect that you will be able to reach a consensus that includes many pieces of knowledge not mastered by all the programmers you work with. If used smartly (no humiliation!), the list can be transformed into a wonderful tool of education.
The procedure reverse_words takes a string of characters as input and reverses the order of the words. For example, the result of reverse_words( "one two three" ) is "three two one". On the board, code two versions of this procedure. The first in your favourite programming language, the second in C++.All the good programmers I know can give a pretty good answer very fast. Yet, many candidates fail miserably.
Runtime performance is important, but you should first consider code clarity and maintainability.
Deux, c'est mieux
There is no such thing as a good C++ programmer that only knows C++. And, of course, if the candidate prefers C++ to anything else, he should have a very good excuse :-) Also, some programmers will have the knee-jerk reflex of using low level constructs when they code in C++ but they are able to come up with quite decent interfaces when they work with a cleaner language. The differences in the implementations they provide can lead to revealing discussions.
The candidate should be able to talk about the big-O runtime complexity of his algorithms. He should also be able to tell you how much memory is necessary. If he comes up with a O( n2 ) algorithm, now is a good time to ask if he can imagine a cheapest implementation.
The devil is on your side
Because it's easy enough to think of algorithms that work, it's ok to focus on the implementation details. If memory is allocated, how is it released? What happens if exceptions are thrown? Should there be an error code returned? If the interface takes a const char*, what happens if it's null?
So, what would be your ideal answer?
goto part 2