Udostępnij za pośrednictwem

Coding Tricks and Interviewing

  • Artykuł

 

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.

 

 

Rick

Comments

  • Anonymous
    March 15, 2004
    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.
  • Anonymous
    March 15, 2004
    Actually, "take the toaster apart and figure out how it works" is especiallyy what we look for in testers too!