9 comments

[ 0.24 ms ] story [ 36.7 ms ] thread
TL;DR: Because most programmers are still so bad that FizzBuzz is still a good indicator.
You're reading way too much into fizzbuzz. Whenever I get a problem like this on a white board I know that it's just a screening question, so I solve it. Solving this toy problem is nothing like solving actual problems in the real world. If you use fizzbuzz for its intended purpose, great. If you're doing it like this, you're going to reward the people who are incompetent enough to need to draw out every implication of a 3 line function.
The most problem I see in this fizzbuzz, is uncertainty. What are you want to see? Maybe something about slowness of division/modulo, and using counters instead? Or maybe there are some non obvious problem in the task? Wtf is going here?

Several years ago I passed russian version of SAT to become a student once more. I had not prepared for math SAT because it is school math, it cannot be difficult. At the exam I spent maybe half an hour more on the most simple tasks, because they looked a way too simple to be the tasks. I strongly suspected that I missed something, maybe misread. This fizzbuzz makes me feel the same: I have missed something, it can't be so easy! So the real task is to find some complexity and fight that complexity, not the task I got.

It is always surprises me how HR tends to spend a lot of time to find creative ways to confuse candidates, to create completely unecological conditions for candidate (ie environment that nowhere near to working environment), and then to make some implications from the result of their tests. HR seems to have their undestanding of environment and do not bother to think about how candidate understands it. If you think about it, you will see, that the former doesn't matter at all, it is the latter which does.

That's one of the things we were looking for, when I was the tech interviewer for our team (primarily a developer, we weren't huge enough to need a dedicated assessment centre, so there was always someone from the target team at the interview): "yes, we see that you understand this and it is a toy problem, please humour us." 0. You are capable of solving this 1. You can take an educated guess at the complexity 2. You are capable of speaking out if the task seems odd. 3. The topic would naturally gravitate to other, more interesting experiences - e.g. 'yes, this was indeed trivial; tell me about a nontrivial technical issue you encountered and how you solved it'"

Only completely failing #0 (i.e. having no clue at all) would disqualify a candidate, IIRC.

> Only completely failing #0 (i.e. having no clue at all) would disqualify a candidate, IIRC.

It is good, but the other points of interest have their influence on the later decision, isn't it?

> "yes, we see that you understand this and it is a toy problem, please humour us."

This way you are showing that you have some hidden goals, it means that situation is really uncertain. In such a conditions anyone would feel stress and anxiety. Maybe except those who are not interested in outcomes of interview or those who have psychological disabilities and is unable to feel anxiety at all.

Lets assume a young candidate, who all his previous life spent on different exams and tests, and therefore percieve this interview as something like exam.

> 0. You are capable of solving this 1.

Ok. I believe that this is a non zero amount of information.

> 1. You can take an educated guess at the complexity

If he start to talk about this, than you would be able to measure his ability to do this, but probably he wouldn't start to talk, due to fear to make a mistake. Like on exam, where it is good to show what you know, but not good to show what you do not know.

> 2. You are capable of speaking out if the task seems odd.

No. He probably would not do that. One of the strategy on exam is to present your best guess with as much confidence as you can express.

It is just one of the possible discourses through which candidate could see this situation. I'm not sure which are other possible discourses -- to figure them out one would need to watch a lot of interviews and to ask odd questions to candidates, to explore deeper than one can judge about person discourse based on behaviour only. But the point is: if you confuse a human by situation, the human would experience a stress, and would start to behave in strage ways, which are led not by his/her personality, but by stress itself. And the more unfamiliar overall setup for the person, the more strange ways to behave you would see, because person would find something in his/her past which resembles this sutiation most closely (exam, test, initiation procedure in the informal group of teenagers in the college, or anything like) and would behave accordingly (without conscious decision of course). If interviewer does not take into account the actual discourse candidate is using, if interviewer is using his own discourse to make meaning of behaviour of candidate, that he fools himself, seeing not the real personality of candidate, but something else. It is highly probable that he would see something completely wrong.

If you wish to use fizzbuzz for #0 and #1, than do not ask candidate to solve task. Ask him what the first thought he had when sow this task. Ask ten more questions. Break all his discourses and make a new one. Create a discourse of discussing and collaborating, something that resembles real work atmosphere. It would be difficult if person is already in the stress and therefore tighly bound to some other discourse, but if you fail to do this, than all your behavioural tests are not valid. At best such an interview would show technical skills of candidate (if he is capable to use them under the high stress), but does not show his/her psychological/social traits.

You are overthinking this. All that matters is that the candidate does have a basic competency in algorithms (#0, we were looking for programmers, not just typists); anything beyond that was completely optional (and I believe I have written as much) and a way to get the interview flowing to expectations of both sides.

However, if your position is "I believe you want one specific textbook answer to the problem from me, and I refuse to do anything at all instead of risking what I think the interviewer would see as incorrect, even partially," you'd be at a wrong interview: the hidden goal is "let's find some technical problem to talk about, we wish to see an approximation of your problem-solving skills; if that approximation is 'freeze indecisively,' that would hardly solve any problems." If you see making any mistake as a threat (instead of going back-and-forth to an optimal solution), you would burn out on the actual technical challenges of the job within a month - literally none of them had a single, perfect, by-the-book solution, each needed to be iteratively developed; cramming the Right Exam Answers wouldn't have helped you on that job, as there weren't any.

Edit: perhaps such person would feel better in a tester/QA position, but does not really strike me as fit for developing (development's usual cycle of trying many things, finding that many of them are not applicable and trying something else, seems like outright torture for someone who needs to have the perfect answer right from the start). Therefore, both sides would find out early, at the interview; in this respect the question would serve its purpose well.

> All that matters is that the candidate does have a basic competency in algorithms; anything beyond that is completely optional (and I believe I have written as much).

What it means "optional"? Either this options have their influence on your decision, or have no. If they have, than they are not optional. If they does not influence, than they are not options. You are speaking about them, it means for me that they are not completely unimportant.

> If you already see making any mistake as a threat (instead of going back-and-forth to an optimal solution), you would burn out on the actual technical challenges within a month...

A mistake in competing environment and a mistake in collaborative environment are different kinds of mistakes and leads to different feeling. If your working environment is a collaborative one, but candidates see your tests as competing environment, than you are measuring something that does not matter.

> cramming the Right Exam Answers wouldn't have helped you on that job, as there weren't any.

Yes! I do talk about the same. Exam strategies learnt by candidate is not interesting to you, but by making from tests a stressful competing experience for candidate you probably measuring this strategies, not the other strategies which are more relevant to you.

Optional, as in "does not have a significant impact on the interview, i.e. not a binary hire/no hire issue." Interviews are, from my experience, stressful for both sides, at least at the beginning: we have used this simple task as a way to get a conversation going. If, on the other hand, we had met a candidate who would insist that we're doing this just to stress them and that everything is a trap, we would probably be worried that meeting an actual problem on the job might be too much strain on their nerves.
It's an ice-breaker. "What, FizzBuzz, do you actually use it for something?" "Yeah, well, it's still useful for article list styling." "Wouldn't CSS be a better tool for this?" "Whatever works - how would you do it using that?" And voila, you're both engaged in conversation and talking about relevant candidate experience. Being able to do modulo is not quite the point. (Or, you could start with FizzBuzz, bring up own code, and discuss various ways of implementing: iteration, recursion, and the issues of each. Or perhaps something domain-specific: "we have 20 parallel producers, but we still want to tag every 3rd and every 5th item in the aggregate output, now what?")

We had a candidate who actually failed this test, but he tried to completely fake any knowledge with self-confidence. (It was an entry-level position, but while people can learn most things for the job, the inability to algorithmize seems to be extremely hard to overcome - had another cow-orker who never tried to understand iteration, always went around asking if someone else could write it instead; gets rather weird twentieth time around)