EDIT: not to mention that you're also not testing me for one of the most important abilities of a coder in a software shop: how well I learn new things.
And it's far too easy to start going down a long and winding dead end path when you can't incrementally run an algorithm. I've had a couple whiteboard interviews where I get the sense that I've gotten something wrong early on that's causing me trouble, and while stopping and pondering on it doesn't immediately reveal a problem (and oh shit, I've only got 10 minutes left in the interview, gah, well, guess I'll just keep trucking), running it once to see the output could easily do so.
It's nothing like real-life coding, is my point.
Also:
> A good whiteboard interviewer will be those things for you.
Would that they were all good ones...
It shows absolutely nothing about me other than I am not a good test taker, and without incrementally debugging my programs I am a fairly worthless programmer.
I dont see how putting someone on the spot like that really extracts any knowledge about the type of person they are.
All of my peers describe me as 'the best programmer they know' yet every programming interview I've ever gone to in this style doesn't work out for me. Frustrating.
Sometimes interviewers even let me just define the signatures of helper functions whose behaviors are tedious to write out, but in words we can cleanly go over the expected behavior. I have a habit of writing "pre" and "post" documentation for functions that specify finer grained types than the porous Java type system; chalk this up to my love of OCaml, but it greatly pacifies interviewers who know that I am mentally type checking, and will let those helper functions go unimplemented.
Not being a programmer by day but proficient in bash and Python I was in an interview last year where the person asking the questions did just not get it. In one example he asked me to count the number of files that had a specific string in the name. I excluded the file descriptor based on his ask. So, he said I got it wrong. I explained the way it was presented I was making the problem harder, and more exact, but he wouldn't budge. The point being, I could easily do what he asked, but wasn't actually measured on that.
I once had an interview where the interviewer asked me to write him a partial template specification in C++. Any time I gave him anything that wasn't exactly right syntactically, he would just say "uh uh," with no further feedback. I did eventually get it, at which point he moved on to bit manipulation questions, which I must admit were somewhat outside the box of what one normally expect from an interview, so I'll give him credit for that. Needless to say, I didn't get the job.
Later that day, I Googled the interviewer, and found his home page, which had a collection of clever bit twiddling hacks he'd collected over the years. I guess that's important or something.
When it comes to REPL and the code-run-debug cycle, they usually ask you to explain how to code would run to them step-by-step, which simulates having a computer run it. They do the same and pipe up if you miss something. So it's not the same as running the code, but it's similar enough and it also shows how well you understand the code you're writing.
I do think that the major flaw of whiteboard interviews is that it does not show a programmer's ability to organize large amounts of code. In most programming, you won't be solving logic puzzles as much as organizing several parts and sticking them together. The organization is far more important in the long run than the individual code itself, especially since the code will likely be changed later on (which is made easier if it is well organized).