Today, this article was posted to hacker news and made the front page. I would like to address the assertion made in the article that if one knows the answers to these types of questions, they will be more prepared for an interview. This kind of thinking about interviews is wrong.
The primary purpose of a programming interview is to assess the candidate's ability to solve problems. If there is any question asked about syntax or language features, a candidate should be wary of accepting any offer.
About six months ago I interviewed with four companies. Having had time to ponder the differences between their interview techniques, I now understand better what I am looking for, as a candidate. One company I interviewed with quizzed me on syntax and language features, and asked me how to do specific things in a specific language. This was not at all what I had prepared for. Now, I know that if I encounter such an interview, I will not work for that company. This is because I assume all of the current developers have gone through that same interview. I do not want to work with people who have passed that low bar. I want to work with those who have proven themselves to be highly compotent.
Programming is problem solving with computers. The order here is important. We have a problem, a solution is constructed in our thoughts, and then implemented using a computer. Programming is using logical and rational thoughts to reason about systems, and create solutions for problems within those systems. This is the hardest thing we do. Knowing details about the system (or language) is what makes us productive at implementating the solution. But the first and hardest part is still to understand the problem and conceive a solution within a given system.
Thus, why would I want to work for a company that is testing me on the second hardest thing I'll have to do? I have no evidence that anyone else at the company is any good at the first hardest thing they have to do. I would become worried that not everyone was an A programmer (A as in: As hire As, and Bs hire Cs). I only want to work with people who can teach me a lot. Those are people who were proven to be good at the hardest thing we do.
The article I linked to at the top assumes that this sort of language finnackery is part of a good interview. It is not. Things that are part of a good interview are about problem solving. Suppose someone was able to answer, perfectly, all of the questions (or, say, harder versions of them) in that post. Would you hire them solely because they have such a complete understanding of the C language? Or another language? I wouldn't. That is not sufficient information. The task of a programmer is to solve difficult problems, not know things. Even with all the correct answers, I still don't know if I can give them a spec and they will be able to implement it and overcome all the obstacles of that implementation.
If you are being asked language questions in an interview, tell them you're not interested in working there. If your interview pushes your mind to the limit because you're creating something, do your best and go work for them.