Alex is making a good point about interviews questions and traps. Interviews questions are not real code, at least not at the first stages. Most of the stuff that I intend for interviews is not going to get somebody called on the carpet if I get to it on production code.

In an interview, I need to be able to judge someone's technical skills very quickly, and hopefully accurately. I can spend a day pairing with a guy and then give a highly accurate view of his/her abilities, mindset and match for our team. I can't do that in half an hour to an hour (the span of most first-stage inteviews).

The point of questions like that is not neccecarily to get the correct answer, it is to discover areas of knowledge. If you can't answer this question, you don't have a lot of experiance in C based languages, period.

If you need to think before you answer this question, great! I want people who take a step back when they encounter this code. But if you programmed in any C based language for any significant length of time, you would know what the meaning of postfix ++ operator, and what it should do.

If you can't figure out the answer, but can decompose the steps taken by this answer, than is fine as well. But this question points fairly accurately to the amount of knowledge that you have in the language per-se.

Other questions that I ask include "What is the difference between value/ref type?" and no one told me yet that ref types are on the heap, and value types are on the stack. I was told that value types are not changes, are copied, etc. That question is another good indication for the amount of knowledge that a person has.

"Is string a ref or value type?" - this one almost everyone gets wrong.

Part of the problem is that I refuse to be limited to what Microsoft supplies, which means that I need to be able to judge what they will be able to learn if/when we hire them. If they can't think and they program by rote, I don't want that. And asking questions that require thinking is a good way to discover that.