What I would simply do is :

"Write fizzbuzz test for language ... use the modulo operator, which is ... for that language"

By doing this it's all about the loop.

On top of that I think the author is right, because the pressure of the candidate is sometimes huge.

I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate :

"I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..."

This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.

We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview.

In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview.

The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz.

My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.

How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)

Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?

I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.

The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor.

> But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?

Any kind of test that is given to candidates has the same risk.

But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.

"If I roll this d6, what will the average be over time?"

I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles.

But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emerging economy in Asia".

Maybe it's nerves, maybe it's thinking too much about a simple problem.

With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.

I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.

I don't mean that I can't solve problems. I mean I can't hold a conversation.

I wonder if the reason so many people fail is because we've essentially put them in an artificial situation that shuts their brain down.

(I have also been dumbfounded by the inability of recent CS graduates to do FizzBizz... I feel like it's not certain our candidates are frequently flawed. Maybe it's our environment.)

That sounds really hard. I'm sorry.

But I can't imagine any interview technique which would work reliably if you're brain dead during the interview.

I'll be honest, that's a really dumb question for testing programming skill.

Still not a great question, maybe. But you grab whatever is in your bag.

(1 * 1/6) + (2 * 1/6) + (3 * 1/6) + (4 * 1/6) + (5 * 1/6) + (6 * 1/6) = 3.5

Of course no actual roll of the die will ever come up 3.5, but as you roll the die more and more times, the average of all results seen so far will begin converging on 3.5 (and given infinite rolls, that's where it would end up).

> Wait, what? No, it asks "can you write a for loop without breaking a sweat?".

There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways:

1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic.

Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.

That means you just took more than 10 minutes on fizzbuzz, which means you failed.

2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect.

The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)

    def fizzbuzz_no_modulo():
        counter_three = 1
        counter_five = 1
        for i in range(1, 101):
            output = []
            if counter_three == 3:
                output.append('Fizz')
                counter_three = 0
            if counter_five == 5:
                output.append('Buzz')
                counter_five = 0
            if not output:
                output.append(str(i))
            print(''.join(output))
            counter_three += 1
            counter_five += 1

Similar to your solution, instead of two counters, you can have two iterators that cycle every 3 / 5 elements, and add them. Then fill in any blank elements with their index+1.

    from itertools import cycle, zip_longest, islice
    
    fizz_list = ['', '', 'fizz']
    buzz_list = ['', '', '', '', 'buzz']
    output = [
        fizz + buzz for fizz, buzz
        in islice(zip_longest(cycle(fizz_list), cycle(buzz_list)), 0, 100)
    ]
    for i in range(len(output)):
        print(output[i] or i+1)

"Okay, let's assume I have some function that tells me whether something is divisible by p. [writes it while using that function] Now, how would I implement that function? Well, I'd search for some existing library function to do that, but if I can't, then here's how I would check divisibility ..."

That's because the senior dev knows how to break the problem into solvable pieces, even and especially where they don't already know the solution to each piece.

I've seen numerous people fail on FizzBuzz despite supposedly being senior engineers.

None of them failed because they didn't know the modulo operator. For one thing, it's actually pretty easy to solve even without modulo.

If someone doesn't know modulo, I'll happily explain it.

More commonly, people struggle with even basic things like setting up a loop at all.

If you don't do fizzbuzz or equivalent, how else do you catch that?

It's surprisingly easy actually.

var remainder = x - Math.floor(x/y)*y

(Math.floor because javascript)

The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.

The compiler can optimize away the duplicate tests. That's its job.