PS: Try composing your response by saying one letter out loud at a time without typing it before you type it.
I agree completely that writing code on a whiteboard is utterly alien to some people, and is so completely divorced from their usual way of working that it's unlikely to give a true picture of how they will code in the real job.
But we're not asking for an insight into how they will code in the real job. We're asking if they can write something like, say, FizzBuzz. More, we're not even asking them to be syntactically flawless and optimally efficient. We're asking if there's any chance that they'll produce working code at all.
I agree that there is to some extent just a disagreement about where to draw the line, and how detailed/accurate the solution has to be, but my experience is broadly in line with the worst claims - 95% of people who approach me for a job in programming can't write code at all.
For the remainder I'll ask how they usually write code, and then collorate with them on something more complex to see how they work.
In practice, few people are asking questions that are as easy as FizzBuzz. I've been through a lot of programming interviews, and I have yet to encounter a problem of that simplicity as an interview exercise. Instead, most companies seem far more interested in laying down the gauntlet, so that they can convince everyone (including themselves) that they only hire "the best".
It sounds like you're trying to keep your programming interviews sane, and that's great. But the problems happen when the other 98% of programmers convince themselves that whiteboarding exercises can be used to successfully discriminate the best of the best from the merely good. One needs only look at the other comments on this page to see that there's a huge and disjoint set of skills that define "competency" to different people.
But your code doesn't have to be correct. Not as you first write it down, anyway.
The advantage of writing the stupid and broken version of FizzBuzz first is that it gives you ample scope to demonstrate your ability to critique your own bad ideas out loud, write tests and conduct them out loud, eschew premature optimization, analyze the performance of something that's way too slow, and invent alternative approaches only after you've produced the stupidest thing that can possibly work. Not to mention your ability to stand in front of a whiteboard and talk while staying on task and not wasting time, which is a core skill in engineering, even if what you're doing on that whiteboard in real life is rarely actually writing code.
You don't ask an author to to write a perfect essay off the cuff. But certainly any author worth having could generate a brief outline for a story (or whatever type of writing you want them to do)
writing a program by hand is not cruel and unusual, it's quite realistic. it's like a musician site reading, not an author writing an essay by spelling letters. (site reading is a skill that comes with being a musician. i can site read music that i would have had to learn to play in the past. i always prefer to read challenging music, but i can play comparatively easy music with little problem.)
I presume you meant sight reading. Threw me for a couple of seconds.
I've tried to do thing mostly verbally, testing their underlying understanding of CS concepts, and hoping this is a decent proxy for development ability.
If you design the questions carefully, the way the applicant answers tells as much as the fact that it's right or wrong.
For example, in a C tech interview I'd ask what you need to if you want to pass variables into a function, and have the function change those values for you. There are a range of correct answers from "put an ampersand in front of the variable" to "call by reference rather than call by value", and these shows different levels of understanding.
I also liked to ask about what the difference between single quotes and double quotes were. A simple correct answer is "one's a character, the other is a string", but somebody who really gets C would tell me that one will lead to the generation of an integer value, while the other results in a pointer.
So it's not just right/wrong, it's shades in between. With some careful design, you can ask questions that tell a lot about how well somebody understand programming.
But occasionally I'd bump into somebody who just couldn't get any of my questions at all, and I'd feel really bad as I tried to think of something simple enough that they wouldn't feel completely awful.
I would think an interviewer should accept someone saying "I'm having trouble on the board, but what I want to do is loop through the numbers, and for each number, mod it with 15, 3 and 5 and then print FizzBizz, Fizz or Bizz." Or, have them draw a diagram, whatever.
Of course, this would need to be supplemented with a coding sample or anything that shows that the person can code when they are in a comfortable environment.