[webjprgm]

The one time I tried a fizzbuzz in a series of interviews, one candidate was surprised and almost insulted. At the end of the day, I learned almost nothing about any of the candidates from this question. Only one candidate (in fact, the one female candidate) implemented it substantially different than any other. All the candidates could do it. They were all CS students at a university, so what was the chance they were not going to be able to compile a program anyway? So I think you have to take fizzbuzz with a grain of salt and know when to try a more complex programming exercise.

(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)

[mikeash]

When I've seen people advocate Fizzbuzz, it's always in a context of how 90% of their candidates can't even do it. It's intended as a quick screener that immediately eliminates a ton of obviously bad candidates.

You're clearly getting a better caliber of candidate than those people are. That's great! And clearly, if that's the case, you should adjust accordingly. I think the lesson there is to tailor your process to the people you get.

[jerf]

I like gradated questions where if someone knocks my first iteration out of the park, I have several avenues to keep probing. That usually involves bringing in more concepts, not merely making the questions more complicated per se. Fizzbuzz doesn't seem to me to have an obvious avenue for bring in more concepts. It's obvious how to make it "more complicated" but not how to expand it.

I often use CSV parsing, where I specify a function that involves a simple string and I want some natural parsing of that in your favorite language. A bonus point for starting with the observation we should use a library, then do it yourself. From there I can pivot into discussing what the correct output data structure is (especially if the rows do not all have the same size or the same data types), converting text into better types, whether or not you understand unambiguously encoding text ("how can you include a comma in your field?", and I'm not worried about whether it's a "standard" answer), UTF8 and other text encoding issues, computational complexity a bit (and while small, it's a very practical, day-to-day bit) and questions of memory efficiency, the question of streaming if the dataset is too big. I can also easily pivot into outputting this CSV file into an HTML table in your favorite language, getting into HTML template issues, security issues that can arise from that, dumping the CSV into a database, and I'm probably even forgetting some of the pivots I've done. (And the point here is that I can choose, not that I ever cover all of these in one interview.) This question template scales from intern level ("can you get this string into an array of array of strings?") to senior engineer ("alas, the text encoding is varying from field to field, now what?") quite easily.

I've phone screened with this in a shared doc, too, since I can copy & paste in the problem pretty easily.

[Houshalter]

It's supposed to be a minimum filter to filter out people who can't program novel solutions. It doesn't prove they are the best though.