IMHO this kind of questions is asked not to determine if the candidate is good, but if he's bad. Indeed, only someone who is really bad at programming would fail it - modulo small syntax errors due to writing code on paper or white board. If the person fails, you should try to show him politely the door - or better, FizzBuzz should be used in phone screen. However, if the person succeeds, it's pointless to ask him or her a more sophisticated version of it, instead, you can ask more complicated questions (algorithms or architecture), and I think that is what RayVR is pointing: it's ok to ask FizzBuzz once, but don't waste the interviewee time asking it 50 times.

As you say, in a phone screen might be suitable place for it. And I certainly don't think there's any point in iterating on it, the only real optimization available is to eliminate the third check for 3 and 5 simultaneously. Truly rocket science.

My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).

One weak question in hours of interviews isn't bad, but now I'm mentally preparing for more weak questions. Making a candidate disengage is a sure way to get a bad interview, or a good interview that results in a "no thanks" to your offer.

> My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).

No, your main problem is just how many of your contemporaries with indistinguishable backgrounds and experience totally bombs this question.

Being offended by a simple fizz-buzz style question[1] is roughly as constructive as being offended by "Is this a good time to talk?" even when a good time to talk has been carefully scheduled.

1: I don't think many people use fizz-buzz exactly, it's too well known, but there are tons of other really quite simple questions that exercise two or three basic programming concepts, maybe throw in some basic problem solving for good measure.

> Truly rocket science.

But that's the problem that FizzBuzz highlights. A bunch of people just can't do it. This isn't about the (now retracted) Sheep and Goats stuff. Plenty of the people who fail fizzbuzz are computer science graduates or senior programmers.

I don't know of any research about why people who think they can program can't do FizzBuzz. I'd love to see it though.

If you really bomb the entire interview series because you were asked the fizzbuzz question, it sounds like you wouldn't work well anyway. Sometimes you encounter simple problems. If you can't handle being asked to do a task because it's "beneath you", you are probably a terrible hire anyway.

Thinking that something is beneath me (which is not what I said, by the way) and feeling that the interviewers have undervalued my skillset are two different things entirely.

During an interview, I'm interviewing the interviewers as well as being interviewed. Part of that process (for me) is to see if they have correctly identified my skill level (in my opinion), so that hopefully they have the right kind of position in mind for me.

The name of a position is often meaningless, unless you know the inner workings of that organization. "Senior" is meaningless window dressing. It's how the role fits within the team that determines if it's right for me and if I will be able to have the kind of impact I want.

Try to put yourself in the shoes of the interviewer. You got to interview lots of clueless people who call themselves programmers but are unable to do the simplest task. Once you spoke with enough people like that, the first thing you want to do is weed out the people who can't program, hence the FizzBuzz question.

Now, I am sure that you, skuhn are able to do those simple things, but the guy interviewing you doesn't know it. If he asks you a simple question that you can nail in 5 minutes, and answer "sorry dude, your question is so easy I find it offending", the interviewer will think you're an arrogant douche - that's how I would feel at least. Instead, just solve the problem he's asking you and move on.

If after that he keeps asking stupid questions, well, it's a different story and you probably wouldn't fit well in that company.

I feel like you're assigning feelings to me that don't mesh with what my comment described. I don't want to get into a personal thing, but here's my condensed point again one last time, in the hope of clarifying:

I think this question is suitable for phone screening. You should already know if someone can do the work equivalent of tying their shoes before bringing them on-site. If I was asked a question at this level during an on-site interview, I would be a little disappointed. If the entire interview continued in that vein, I wouldn't accept the position.

Questions like this can work in a phone screen if you have a shared virtual whiteboard. Otherwise it is painful for the interviewer to try to transcribe code as the candidate thinks of it and says it alout.

There is also the common problem where candidates google for answers or at least seem to google for answers during phone screens.

The problem with asking truly challenging coding questions during an interview is that they are often too challenging to finish in the time allotted. Frequently challenging coding questions require an ahah moment or domain knowledge. For example if an interviewer asks a candidate to invent an advanced algorithm on the spot what is being measured? If the candidate gets the answer right they might be really smart, they more likely have been previously exposed to the idea, or they got lucky. If they got the answer wrong the interviewer must judge them on their ability to communicate their thought process during their attempt - but from that the interviewer didn't learn if they can code.

You shouldn't be disappointed that interviewers don't know straight away that you aren't a charlatan. You should instead be disappointed by the fact that there is such a high number of successful charlatans in our industry.

I've never asked fizzbuzz, but I have asked people to count the number of upper-case letters in a c-string. I feel like this is of similar difficulty, for people who claim to know C/C++.

When I asked that question, I was looking for fluency. A candidate shouldn't have to think about it. They should write c >= 'A', instead of floundering because they don't remember the ASCII value of 'A'. If asked, they should be able to iterate over the string without taking strlen first.

This is basic stuff, but you might be surprised how many people with years of software development experience on their resumes can't do it. Moreover, I found that a good performance on this easy question was highly predictive of good performance on harder questions. Not that this didn't stop me from asking hard questions. :)

Unrelated: In Unicode that would be a pretty difficult problem. The uppercase version of 'ß' is actually two characters "SS". There are a lot of messed up casing rules in the unicode standard. http://unicode.org/faq/casemap_charprop.html#11

Sure, casing is complicated; but determining whether a codepoint has the uppercase property is easy - just use u_isUUppercase().

Where it does get complicated is determining whether a codepoint or a digraph of multiple codepoints is a letter, and that's culture-dependent; e.g. IJ in Dutch.

If you can write a FizzBuzz solution in bash in 30 seconds, you are definitely a programmer. You don't have to program as a profession to be a programmer.

I mentioned that I'm not a programmer because that's typically the biggest hurdle for me in technical interviews. I don't write code for a living, nor do I want to. Yet I still get asked programming questions, but nothing remotely this simple.