Coding Tricks and Interviewing

Coding Tricks and Interviewing


My post on href="">stupid
coding tricks elicited some interesting responses, both in the comments to
the post and in a href="">discussion
held in the forums over in Joel’s
web site. Some of the responses, like href="">Eric
Albert’s, focused on the interview question. Others, like href="">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 class=Code>a. The
question is, which value of b
is used in the evaluation of the second assignment to style='font-family:"Courier New"'>a? The answer to that
question, to my thinking anyway, involves deciding which of the class=Code>xor
subexpressions gets evaluated first before the second assignment to class=Code>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 style='font-family:"Courier New"'>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.




Comments (2)

  1. Larry Osterman says:

    Usually, when someone does that to me (and I’ve also had it happen, I suspect everyone has), they go back to the lobby and I get on the horn with the HR person :).

    Sometimes I’ll try to see if they have the ability to realize that their solution is sub-optimal but…

    Oh, and I’d immediately retire that interview question, my personal take is that it isn’t his "former employer" that found it, but instead that the interviewee had found a solution to the question on the internet and was parroting it back.

  2. Joshua Allen says:

    Actually, "take the toaster apart and figure out how it works" is *especiallyy* what we look for in testers too!

Skip to main content