Typically we'll start with an even simpler problem before dropping them into something like this. Over time, we've found that a good 1/3rd of candidates can be eliminated with just fizzbuzz (print the numbers 1-100, for numbers divisible by 3, print fizz. For numbers divisible by 5, print buzz. For both, print fizzbuzz). Even if they do stellar on a phone interview, a large number of candidates still cant get past this simple problem. It's also easy enough that you can give it to people at job fairs on the spot. Any programmer that you'd want to hire can finish this in less than 5 minutes, which is an easy time investment to make.
One of the advantages that proponents of reviewing the candidate's code before the interview have is that you don't have to spend any time doing FizzBuzz kind of problems, which are just time wasters.
If you're interviewing people who can't print the numbers 1-100 then something in your process is just wrong. Why did they get that far?
that's simple: people lie on their resumes and can talk a good game. Until you actually ask them to write code (or they have public code available), it's impossible to tell if they used PHP for a week per employer (making up 5 years of 'experience') or if they work with it day to day.
This! I can't believe how many people are ditching the coding interviews here. You're guaranteed to hire a few lemons if you don't do them.
The inability to write simple routines in a language you claim to be familiar with is a NO HIRE. Be it at a whiteboard (its not like one cares about syntax errors) or at a PC/laptop.
Unless you accidentally have in-depth knowledge of the exact work an interviewee did in his last job, assessing their skill in what they did can be very difficult.
