I've done several interviews where I was asked to code and I really don't think it's easy, because you're under intense pressure of doing your task right the first time and under a very tight time frame. Sometimes even with your interviewer sitting next to you.
My programmers wrote FizzBuzz in under 60 seconds. If you can't write FizzBuzz in 15 minutes in an interview then you are either unable to program, or any level of stress will prevent you from doing your job. Either way, you couldn't work for me. I don't routinely stress my programmers, but stress is a matter of observable fact.
It's hard to make analogies to other fields, but it feels sort of like a writing job not asking you to write an insightful philosophy essay on the spot (legitimately difficult), but just asking you to write a paragraph of grammatical English (anyone even remotely fit for the job should be able to do it).
PS: Try composing your response by saying one letter out loud at a time without typing it before you type it.
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.
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)
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.
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.
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.
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 asked about the data structure several times as I thought they were looking for a generalizable solution that could be used with arbitrary objects and wanted to know if I had to define a separate class to implement a linked list or if I could just use a vector. This made the interviewer increasingly flustered because from his perspective the data storage architecture didn't matter and the answer was simple. I later found out he simply wanted to track the largest item on insert with a separate int and return that on max() - this was their concept of a good programmer, despite the fact it would be unnecessary and inefficient in any ordered list).
After a few minutes he concluded I couldn't program and moved to end the interview. I decided that if communication problems were this bad (probably my fault as well), this wouldn't be a good place to work. And I was also sort of shocked he hadn't bothered to vet any of the public coding work I'd done. Who brings people into interviews totally blind?
So while I might have been sympathetic to this article before, I wouldn't be so quick to blame the programmers. I was irritated this company had wasted my time, and probably vice versa. I don't know what the solution is for employers, but the solution for job-seekers is to require people to look at code you've produced before you meet them in person, and bring a laptop so you don't need to stare dumbly at paper while you try to remember the exact way to initialize a vector of pointers in C++. Either that or do a phone interview first to get this stuff out of the way.
They're the ones who get the most realistic view of me as a programmer (for better or worse).
The realistic view of your ability comes later in a second, or even third interview. At that stage we will also talk about system/program/algorithm design skills, ability to work with others, willingness to travel, preferred working hours, and a whole bunch of other stuff to get an idea of how you add value to the company, and how well you will fit with the existing staff and ethos.
But if you can't write something as simple as FizzBuzz in under 15 minutes in a slightly strange environment, you probably won't be able to program well enough here in this company to bother with the other questions. Working here requires more than just producing code in your ideal environment without working with others. I suspect we're not alone in that.
EDIT: I've corrected a few typos. To the person that down-voted me - thanks - you made me read it again and realise that it wasn't as clear as it might've been. I was on my way to a meeting and wrote it in a hurry. Although still not perfect, I think it's better now.
To others who might choose to down-vote it, I'd appreciate any insights as to why. Sometimes I hold unusual, eccentric, or unpopular opinions, and I'm willing to bear the consequences of that, but I'd really appreciate the opportunity to learn what you disagree with. Please, share your thoughts, don't just down-vote without giving people a chance to consider what you think.
And if a potential candidate can't be bothered to do that, how bothered will they be to make small, uninteresting changes to working code? How interested will they be to fix a corner case they don't care about? How careful will they be about details when releasing code?
Not being willing to "jump through hoops" is an indication of fit, as much as many other things. My job is to make the hoops as big as possible, and as easy to jump through as I can make them. If people can't be bothered, then I guess I won't employ them.
Yes, it biases the selection process, but it's a huge save not interviewing people who can't, or won't, produce FizzBuzz (or similar).