It's a common mis-conception, but we're not talking about the stage where I'm trying to get an accurate picture of what you'll be like in the job. It's still the very first stage of the interview process, and we're not yet at the stage where we need to decide which of several demonstrably competent programmers we want. We're talking about weeding out people who simply can't write programs at all.

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.

Google lost a lot of good people by dragging out their interview process. It's not all or nothing, but if I disliked the first interview I am unlikely to be interested in doing a second one. In the back of my mind I can't help but wonder if I want to work for people desperate enough to jump though these hoops.

You make it sound like it's a big deal to write 10 lines of code before being interviewed. I agree that some candidates, possibly including me, would be put off by being asked to solve a problem requiring 10s of hours before interview, but we're not talking about that. We're talking about getting someone to demonstrate 10 lines of working code.

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).

The issue is showing up for a second, third, or fifth day of interviews. If you want to know something about my technical competence fine, figure that out over the phone or use a webbapp.

You obviously haven't interviewed at google. I had 6 technical interviews, 7 if you count the phone screening. From the day their recruiter called me to the day they called and said they weren't interested spanned about 3-4 months.