Lately there's been quite a lot of interest on programmers.se about interview questions, and specifically the "coding at the whiteboard" part of the interview. It came up in a discussion of FizzBuzz, in one about "testing" your whiteboard code, and in one about question 11 of the Joel test.

I ask candidates to code at the whiteboard. I ask an intensely simple question, because I am mostly testing for things other than the actual code the person writes. I know, however, that there are places that actually want you to tackle reasonably challenging problems. I came across this blog entry by Diego Dagum (who edits The Architecture Journal, writes architecture columns, and is committed to native C++big time) that walks you through a C++ whiteboard problem that is decidedly non-trivial. What I found interesting is that he starts his "thinking aloud" the same way I would, but then when I would start writing something that worked for valid input, he first started to set out examples of invalid input. And when he wrote the code, it starts by rejecting various categories of invalid input before processing anything. It's cool to see someone thinking differently from me.

One thing really struck me. He spends over a page on the signature of his method - why he called it rtoi, why it returns an unsigned int, why its argument is const, whether it should take a  unicode string or not, why an STL string and not a char*. See how much these problems reveal about a person? That kind of care and precision is not something you can discover by asking a person "how important is it to you that a method signature is chosen with care? Can you give me some examples of naming methods you have done?" Coding in a job interview is about so much more than syntax. Are you prepared for the whiteboard?

Kate