With an answer like that I would have assumed you were a jerk. You could have easily answered the question in a positive manner that explained your need to have the candidate complete the task. "Because I said so" is often a valid answer to a child, but not to an adult.
What I'm curious about is why so many seem so beholden to FizzBuzz in the first place to the point they assume everyone already knows what it is. The fact that none of your candidates had heard of FizzBuzz was to your advantage. What's the point of administering a test if everyone had already heard of it and knew the answer?
So, did you hire the one candidate that completed FizzBuzz and did you hire this person because they could?
If a candidate comes in with previous knowledge of FizzBuzz, that would indicate to me they are probably pretty in touch with the industry. That is, they probably read blogs or forums about development and/or interviewing. That would be a good thing, and they would likely get the problem right.
That would be fine with me. If it does get to the point that _everyone_ knows it, then we have to find a new question.
Previous knowledge of FizzBuzz doesn't necessarily indicate competency. They could have easily just read a blog about "The 10 Most Common Programming Interview Tests" and memorized a popular, simple way of creating the code.
To be honest, I seriously doubt the knowledge of FizzBuzz will be a common thing. I was seriously coding for a year or so before I had ever heard of it. When I first saw the question I had what I felt was a responsible block of code that worked. Since then I've tweaked it to be more efficient as my skill level increased. But I've never been asked in an interview to code FizzBuzz or anything like it.
I'm sure someone will drag out the extreme counter-example after I say this, but I am pretty sure nobody ever has ever advocated hiring a person simply because they can do fizz-buzz. Fizz-buzz is just one step in many of a noise filtering process.
I'm not saying they should, I'm just curious about the outcome of this round of interviews.
I've interviewed many a "web designer" that were obviously not qualified on the level they claim. Just asking how to make text flow around an image is a simple gotcha that someone who claims to hand code HTML should know. If you're just a designer then that's fine, but don't say you can hand code HTML and not know what a float is or even have creative solution that doesn't involve a float. I've met many who couldn't come up with a reasonable answer. But it's not an immediate "sorry, you should go now" moment for me when they cannot do so. I also look into how they answer and how they handle being told they were wrong.
Something like FizzBuzz is a useful tool but I see too many give it too much weight without considering other variables involved in giving the test. Each interviewer has their own style but having a heavy hand on one or two aspects of the interview means you may be passing up a good hire.
If I had followed the "rules" that I've seen many advocate then one of the best hires I had ever seen wouldn't have walked through the door and even then he would have been told to walk right back out. Turned out he was an excellent hire that learned quickly and was excited about his work. That young man just recently started his own development company, granted its just him for now but he's got the work and chops to support it. Makes me wonder if I were a FizzBuzz or nothing kind of interviewer how things might have been different. To be honest I have no idea if he could have coded FizzBuzz, I didn't ask.
But I also understand if you are going through dozens or hundreds of resumes then you have to do something. Just don't be the "I don't hire unlucky people" guy that throws away half the resumes when starting. Too many FizzBuzz advocates get dangerously close to that kind of attitude.
Gee, it sure is easy to assume I'm a jerk. From my pithy story, you sure didn't guess the following true elements I omitted:
1. There was a great deal of primping and preening prior to the coding phase of the interview, and it was made clear that the phase of the interview was designed to demonstrate basic coding skills, that it's a fairly standard industry practice, and that these exercises are fairly meaningless and all the rest. There was plenty of warm up.
2. I wasn't running the interview; I lack the authority to do that. I am simply a member of the group the interviewee was interviewing for. I blurted it out because I was shocked by his response, which I felt demonstrated that he felt he was above menial coding exercises. I've never met a good engineer who would scoff at a problem because it was too simple, especially in a context where demonstrating prowess was desired.
3. The candidate, who is a "senior engineer" in his current position, also showed us some of his code after failing this part of the interview, which was a truly disgusting, thousands of lines of copy-paste crap pile. Imagine writing a large interactive site with jQuery, then remove the ability to use selectors and do all that by hand. Then imagine what you're doing also happens to be done for you by your backend if you enable a bit of configuration. That's the level of shockingly incompetent we're talking about.
4. We still offered the candidate the job, because we're fairly desperate, we were worried about losing the position if we didn't hire someone, and he seemed personable--and like he probably wouldn't screw things up worse than they already were on this particular project, which came back from being outsourced in really sorry shape.
5. The candidate refused to take the job, not because of the group, the low pay, the interview process, but because we couldn't get HR to change the job title from "Software Engineer" to "Senior Software Engineer." He actually made this clear to my bosses on the phone, that if they could just add "Senior" to the job title he would take the job, even with no other changes, and refused--angrily--when they couldn't do that.
I can understand why, with one remark taken out of context, you might relate more to the interviewee than the interviewer. But you really should cut people a little slack around here. Most applicants to programming jobs--especially outside technology hubs--are just not very good. This guy wasn't very good and seemed to know it, even though he hadn't seen Fizz Buzz before, and it hasn't stopped him from having a career in programming for decades.
I think you are missing the point of the GP's answer. Instead of nailing in 1 minute the easy question (would it be fizzbuzz or "write me a program that prints 'hello world'" or something of that kind), the candidate is supposed to write the answer quickly and move on.
Being snob about the interview question is not going to help things.
Maybe sometimes we forget, the interview is for BOTH parties. I think it's fair to ask if puzzle like questions are an expectation. It would be simple to answer: "Yes, we know this is a silly puzzle, but it's a fast way for you to show us your real world skill".
> Being snob about the interview question is not going to help things.
Isn't "because you need the job" snob? The interviewer could have very well said "We start with simple problems, and then we expand on it. So let's start with this fizzbuzz problem."
I obviously took the "because you need the job" as a statement of a snob, or in my words a jerk. Despite the reasons for the statement, it would have given me a negative impression of the person. If that person was management then it would give me a negative impression of the workplace. As someone else points out in this thread, an interview goes both ways.
What I'm curious about is why so many seem so beholden to FizzBuzz in the first place to the point they assume everyone already knows what it is. The fact that none of your candidates had heard of FizzBuzz was to your advantage. What's the point of administering a test if everyone had already heard of it and knew the answer?
So, did you hire the one candidate that completed FizzBuzz and did you hire this person because they could?