I stumbled on the FizzBuzz discussion by accident and enjoyed reading all the way to the bottom. I'm at the other end of the employment train (leaving rather than joining). Programming is just a hobby interest for me and I was delighted to see I had got the FizzBuzz sort-of right quite quickly after failing miserably with a series of non-programming trick questions yesterday.
My experience is that the problem identified by Jeff applies in all fields. Most people can do, by rote, what they have been trained to do but have no idea how to do stuff when a broader perspective is required. At an interviewing course years ago the teacher was adamant about asking interviewees "what do you think of that [experience], looking back?". In other words, trying to see if they learned anything, or if they could stand outside their experience and look at the big picture. He also said "hire a learner". [Of course most interviewers haven't a clue :)]
On thing that was not mentioned was the issue of debugging. Maybe the various posters take that skill as a given. In my experience the ability to diagnose problems efficiently is the most elusive of human skills. It is a skill that is required in many walks of life - auto-mechanic, physician as well as programmer. However the ability to debug seems to have a much higher importance in computer programming.
There are lots of clever ways to solve problems in programming. But the choice of solution depends on the context and the specification - neither of which can be adequately explained in a short question. The solutions that simply printed out the answers line by line work, provided there will never be a change in the requirement. The need to swap to things seems to me to be an undesirable level of cleverness that would lead to problems - and some people identified that.
If I was hiring someone to jump in and write code tomorrow it might be more effective to give them a page of code (ideally on laptop) and ask them to fix it - together with explaining their thought process as they were going about the task.
If I was hiring someone who could grow into the task I would be content with a generic answer to the fizzbuzz problem - for example "loop through the numbers and check whether each number is divisible by 3 or 5. Then print the answer depending on that test" That could lead to another question "how would you know if it was divisible by 3?". What I would like to know is whether the person was capable of conceiving a solution to a problem - it is easy to look up the details once you have a suitable plan. Indeed, with Google, programming is probably the "science" in which it is easiest to look up the details.
Another characteristic that is sadly lacking among computer geeks is the ability (or willingness ???) to understand the non-computer client's needs, or to express back to the client his/her need in ways that enable the non-computer person to express the requirement better. I had a sharp experience of this recently where I was never once asked "what are you trying to achieve - maybe there is another solution?". Personally I regularly find myself saying to someone "I don't think I understand your question" - and I find it is better to let them struggle to explain themselves rather than to prompt them in what may be the wrong direction. If I was hiring someone who would interface with clients I would be looking for this skill as well as the ability to program. Getting the specification right solves 80% of the problem.
Finally, an interesting aspect of all the responses was the various languages that people use. I think it is 100% safe to say that they are all less comprehensible to the reader than the initial VBscript example. By comprehensible I mean how quickly could you figure out what the program snippet does after you have forgotten how you did it, or could you figure out what someone else wrote.
