I was in one interview at a local startup where there was a whiteboard in the room, but none of the engineers who interviewed me asked me to touch it; they were satisfied to ask questions of the form “what do you know about Java Foobar Technologies?” After an hour or two, I could feel the whiteboard... looming... blank... silently warning me not to take this job.
There is no silver bullet. I see a sort of taxonomy of techniques, the relative quality of which is very dependent on the person interviewing.
An assumption: it is bad for the prospective employer to see no code at all.
I see two basic options:
1) see code written before the interview, and
2) see code written during the interview.
Option (1) has a few sub-options:
a) look at open source work,
b) ask for private personal work to be made available, and
c) ask for custom work of your choosing.
All of these share the weakness of requiring work outside work hours. There are many qualified candidates who don't have work of the (a) and (b) sort available, and while many see option (c) as a welcome intellectual challenge, many others see it as a tedious (or even offensive) waste of their time.
Option (2) also has a few sub-options:
a) provide a computer and a project or set of coding questions to be solved in your absence,
b) same as (a) but with pen and paper,
c) ask a question and watch on a projector or over the shoulder as it is solved on a computer,
d) same as (c) but with pen and paper, and
e) same as (d) but on a whiteboard.
Option (a) is basically the same as (1c) above, but attempts to mitigate the waste-of-time factor by using already-committed interview time to do it, and option (b) is just a much worse variant of the same. The weakness of these options is that it is impossible to get an idea of a candidate's thought process while solving the problem. Option (c) is really good for interviewers but very high-pressure, which selects against many qualified candidates. Option (d) and (e) are identical, but some people hate pen and paper, others hate whiteboards, and most hate both! It is imperative when not using a computer to avoid requiring or judging by the use of things that computers help support, like specific languages, specific APIs, or syntactic accuracy.
Or is this all wrong - have you found the general solution?
Personally I don't think that using a whiteboard necessarily means "whiteboard BS". There are good and bad ways to do it. Getting nitpicky over syntax and expecting the candidate to have everything memorized makes for whiteboard BS. Concentrating on overall structure and approach and expecting reasonable questions from the candidate makes for a good whiteboard experience.
