Coding Tricks and Interviewing


My post on stupid coding tricks elicited some interesting responses, both in the comments to the post and in a discussion held in the forums over in Joel’s web site. Some of the responses, like Eric Albert’s, focused on the interview question. Others, like this one from Dennis Atkins, took issue with my assessment of the validity of the xor trick as C/C++ code.


As I’d said, I’m no compiler writer, so I’m not necessarily qualified to discuss which clauses in the official C and C++ language definitions apply. However, here’s my take. The expression is:


        a ^= b ^= a ^= b;


Within that expression, there are two assignments to a. The question is, which value of b is used in the evaluation of the second assignment to a? The answer to that question, to my thinking anyway, involves deciding which of the xor subexpressions gets evaluated first before the second assignment to a takes place. Since the order of evaluation of these subexpressions is undefined, the result of the second assignment to a is undefined.


As for whether or not this was a stupid interview question, I’ll stand by my initial assessment. For this particular line of code, the question can only have two reasonable purposes: 1) the apparent purpose, to test the candidate’s ability to figure out what xor does in this context, or 2) to test the candidate’s understanding of the formal definitions of the C and C++ languages. If the interviewer’s purpose was 1, then there are other, less ambiguous, ways to achieve the same result. If the purpose was 2, then this particular question is too esoteric to be of legitimate value to anyone but compiler writers, and I would contend that there are more important issues of interest, even to people writing compilers, than this particular issue.


That said, while I’m on the subject of technical interviews, an experience I had as an interviewer may well be helpful to people seeking employment. I gave a particular programming problem to an interview candidate who then went straight to the white-board and wrote a solution to the problem. While the solution was correct, it wasn’t the optimal solution.


I asked the candidate why he wrote that solution, and he said that he didn’t know, but at his former employer they’d decided that this was the way it had to be done. That left me with the unpleasant task of trying to find a way to consume the remaining 30 minutes of time we’d allocated for the interview.


If your approach to problem solving is the bang-on-the-toaster variety, then don’t bother trying to interview for a programming position. You’d probably be far happier as a tester. For programmers, we want people whose approach is to take the toaster apart and figure out how it works.