For all you technicians out there that ever had to assess a new collegue (e.g. a job interview or intake of contractors), what questions do you ask during such sessions in order to measure the candidates technical knowledge? For example, a common question I use is to explain the difference between an open or closed diamond in UML diagrams. Or the true conceptual characteristics of the Object Oriented paradigm.
Any interesting additions you would like to share?
The first thing to do is to make sure the person can write "Hello, world" (or something slightly different but equally trivial, like reading a line of input and reversing it) in the language of their choice. You'd be surprised at the number of people this filters out.
Then, ask them to do something slightly more difficult, like traversing a tree data structure or reversing a linked list. Again, you'd be surprised at how many cannot manage this.
If they don't automatically write a unit test when writing the code to solve these problems (which is OK, since I don't expect everyone to think of that while in an interview setting), then I would ask them to write some unit tests for these. If they don't know what a unit test is or don't know how to use any unit test framework in the given language, I presume they have not done much in the way of serious software engineering in that language.
Conceptual questions are some of the worst kind. Someone can have some vague concept of object orientation or UML and be able to answer your conceptual questions, and not know anything about actual programming.
I usually ask candidates to talk me through their role in a recent project. Tell me exactly what you did and what your responsibilities were. That gives me a frame for asking technical questions without insulting anybody.
I expect the answer comes down to what you are trying to learn about the potential colleague, and what role you expect them to fill.
I'd say make sure you talk enough about a topic to get some insight into a candidate's thought process, and actual knowledge, rather than questions that reveal how well the candidate crammed for the interview. List 5 differences between C++ and Java, for example, isn't always the most useful question...
I prefer questions that facilitate a discussion, and get a sense of how passionate/interested the person is. From there, try to get a sense of a candidate's depth of knowledge, their thought processes and attitudes. Previous work tends to be a good starting point.
For some interesting examples/samples in .net, see Scott Hanselman's post.
For an interesting perspective on how to assess a candidate, see Joel Spolsky's post
You can ask a person claiming to be an experienced C++ developer how reinterpret_cast works - they often can't explain. Or something not regarding STL. Not being able to explain such simple things is a very bad sign in my opinion - they will likely write code they will not understand but will just believe in.