If your goal in the interview is to humiliate those who don't work well under pressure, or to insult the intelligence of those that can pass it in their sleep, by all means, go nuts.
I'd walk out of an interview if they went FizzBuzz on me. If you're asking questions as stupid as that you obviously haven't looked at my open-source code or talked to any of my references.
You need to screen for what you want in a candidate in a manner that's appropriate for the type of candidate you're dealing with. Throwing your front-end dev a FizzBuzz is garbage. Asking them questions about their use of CSS in the past, the challenges they've faced, and what they're hoping to see in future versions of CSS can inform a lot more than any "coding test".
One thing I find is the most illuminating is asking someone what they like the least about their favorite language or platform. The thing that's causing them the most pain seems to precisely illuminate the stage of learning they're at.
For example, someone who claims to be a long-time iOS developer but who hates the message passing notation in Objective-C is probably more inexperienced than they're letting on. Someone who says they have "some" experience in JavaScript but is upset about some esoteric aspect of streams might be wildly understating their understanding of the language and environment.
Unless your company's workflow consists of writing code on whiteboards and deploying the whiteboards to production, interview code questions give a lot of bad data.
I'm mainly talking about junior developer interviews here. Although IMHO, administering FizzBuzz to senior applicants isn't a bad idea, either. You'd be surprised just how far a person can get into computer science without being able to code.
It's a terrible idea. Focus on questions which give you meaningful data. For juniors work on ascertaining their motivations and how they think. For seniors dig into their experience and what they're looking for in a role.
Unless solving FizzBuzz on a whiteboard is what your company does on a daily basis it gives you nothing but junk data.
Sometimes people need a moment or two to shift into "coding mode", and others might not be comfortable doing it without a particular editor or reference handy. There's many ways to produce good results, not all of which are whiteboard friendly.
I'd walk out of an interview if they went FizzBuzz on me. If you're asking questions as stupid as that you obviously haven't looked at my open-source code or talked to any of my references.
You need to screen for what you want in a candidate in a manner that's appropriate for the type of candidate you're dealing with. Throwing your front-end dev a FizzBuzz is garbage. Asking them questions about their use of CSS in the past, the challenges they've faced, and what they're hoping to see in future versions of CSS can inform a lot more than any "coding test".
One thing I find is the most illuminating is asking someone what they like the least about their favorite language or platform. The thing that's causing them the most pain seems to precisely illuminate the stage of learning they're at.
For example, someone who claims to be a long-time iOS developer but who hates the message passing notation in Objective-C is probably more inexperienced than they're letting on. Someone who says they have "some" experience in JavaScript but is upset about some esoteric aspect of streams might be wildly understating their understanding of the language and environment.
Unless your company's workflow consists of writing code on whiteboards and deploying the whiteboards to production, interview code questions give a lot of bad data.