Hacker News Reader

I agree with the author that Fizzbuzz is about the modulo operator if you present it to the candidate like that.

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.

I can second the value of the take-home assignment. My last company, Appstem, gave them out, and it never once failed. It additionally succeeded in weeding out people who were not motivated enough to want the job.

I had a pretty interesting experience with this.

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.

I can confirm. I went to pieces once when asked to do FizzBuzz when I wasn't expecting to code in a phone interview. I'm not a "rock star" programmer but in the absence of pressure I can knock out a FizzBuzz in < 2 minutes. And I have written real software used by real users that made money for my employers.

Agree on technical questions + what he says on "team fit" really doesn't make sense: "You are NOT hiring for "team fit" I have never heard a definition of "team fit" that didn't end up sounding like "let our bias run free". Phrases like "looks like they belong here" are terrifying. More insidious are complaints like "doesn't like the same social activities we do". Grow up. Your office is not your frat house, and socializing with your co-workers outside of work is not some crucial test. There is no requirement that you like someone socially as long as you want to work with them." You don't ask people to be exactly like but you expect them to be able to work in a cool mood with you and to share things. Who would hire somebody that doesn't get along with the team??!!

Team fit is actually pretty important as far as how long the Dev will stick around.

* It's a great predictor for "can this person actually program, well, at all?".*

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)

Everyone I know doing recruiting says that FizzBuzz reliably disqualifies surprisingly large fraction of candidates. Even half of them, even after prefiltering by education or relevant experience.

That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so).

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.

> That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so).

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.

I'm sorry, but I just cannot accept that anyone who has any decent skill at programming would fail fizzbuzz.

It's genuinely surprising what people don't know.

"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.

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

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

We were looking for statisticians.

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

1/6?

The question is a weird way of asking "do you know the definition of expected value?" Expected value is calculated by taking each possible outcome, multiplying that outcome's value by its probability of occurring, and summing the results. So to calculate for a six-sided die, where each outcome has probability 1/6, you simply multiple each possible outcome by 1/6 and sum those results:

(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).

Yeah, if you're looking for statisticians, they should be able to figure that one out I'd guess lol

I suffer, on occasion, from depression and anxiety. When I'm having an episode, my brain doesn't function.

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.)

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

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.

>> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"

> 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.)

#2 happened to me: I wrote the straightforward implementation in a few seconds, and then struggled and tied myself up trying to eliminate the duplication, making it worse and worse, until I started panicking. Luckily the interviewer understood what was happening and changed subject.

>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.

It's surprisingly easy actually.

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

(Math.floor because javascript)

If you don't know about modulus, you don't have to re-implement it. For Fizzbuzz you're looping anyway, so you can just maintain two counters, one that counts to 3 and resets, and one that counts to 5 and resets. When one of the counters resets, you know the main loop counter is a multiple of 3 or 5. Like so:

    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

There's a lot of ways you can do it. I think it's fun to see how people solve it when they're not allowed to use the obvious answers (note: I don't interview people and probably would not choose no-modulo-fizzbuzz as an interview question).

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)

> Much more likely is that the candidate has lied/exaggerated on their resume.

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

On 1), I disagree -- if a genuinely senior engineer doesn't know of modulus (totally possible btw), then what they'll do is:

"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.

> 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.

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.

I think what he is pointing out is that if you don't know the modulus operator, you will fail FizzBuzz. The modulus operator is rarely used and somewhat obscure.

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.

You can implement it yourself if you forget it. Or use a counter (urgh). Or ask whether there's a library function that does that.

If you're so crafty at sifting through candidates to resort to FizzBuzz to help you do it, why do you have to copy and paste FizzBuzz, why not come up with something original?

Actually I usually ask a comparably difficult question for fear that people might have actually remembered the solution to fizzbuzz by heart. But I didn't think it added to the discussion to mention that.

The trick part of FizzBuzz is that the easiest solution relies on the magic "15".

Even that's an unnecessary complication. The code solution should read like the spec, so that if someone comes along later to make FizzBuzz depend on some other set of constraints, they know what to do.

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