FizzBuzz and bored programmers
January 26th, 2007 by Samuel TardieuOn his blog, tickletux advocates the use of FizzBuzz to find developers who grok coding. However, this kind of test may also cause difficulties. What do you do if a candidate answers with the following (correct) C code?
#include <stdio.h>
static const char *t[] = {"%d\n", "Fizz\n", "Buzz\n", "FizzBuzz\n"};
int main()
{
unsigned int i;
for(i = 1; i <= 100; i++) printf(t[3&19142723>>2*i%30], i);
return 0;
}
What explanation (and action) would you choose?
- the candidate is smart and managed to avoid any explicit test (”branches are evil” philosophy): hired;
- the candidate tried to impress you and won’t explain the 19142723 in her code: she is likely to cause problems in the team: not hired;
- the candidate mind is so convoluted that she could not think of another solution: not hired
- the problem you gave the candidate was so boring that she solved it while having some fun; may be a real problem solver: hired;
- the candidate is perfectly suited for an embedded systems programmer position: hired or not, depending on the kind of software you want her to write.
If I were to interview people for a programmer position, I honestly don’t know what I would do with someone writing such a code in response to the original problem. I would probably assume that the programmer was bored and that she wanted to have some fun while doing her job, and I kinda like this idea.
January 26th, 2007 at 4:18
Another option: the candidate considers his-/herself clever and isn’t going to go out of his/her way to write clear code. Not hired. I never consider complex, non-parenthesized expressions (esp containing long constant values) to be the kind of thing I want. Nice that they’ve memorized their operator precedent table, better if they wrote it more clearly.
It’s an interesting idea: you could have them refactor that code to make it more obvious.
January 26th, 2007 at 10:39
my action: The candidate writes obscure code and is even proud of it. Don’t hire in any circumstances - code clarity is what matters most in any real world situations.
January 26th, 2007 at 19:12
I think you are just missing one thing: have the candidate explain their code (or walk you through it). That way you can choose between the different explanations you make, which helps you make the hiring decision. This article also shows how you would answer the recruiter, so now you get to give us an explanation!
January 26th, 2007 at 22:35
Olive: I would only give the recruiter this kind of answer if I knew that she would appreciate it (being an ügergeek for example). The trick is to represent characteristics of every number (modulo 15) by an integer between 0 and 3 (plain, fizz, buzz, fizzbuzz). You need two bits for each number between 0 and 15, and can generate a decimal number with those 30 bits with: (thanks to J)
(no, I don’t feel like explaining J today)
Then it’s simply a matter of choosing between the four alternatives after right shifting this large number by twice i (modulo 15) and using the two rightmost bits only.
January 26th, 2007 at 22:55
Ok, we’ve had a good laugh, now let’s get serious about hiring:
Tickletux did NOT say make a hire or no hire decision based on this question. Tickletux did not say “NO HIRE” if you don’t like the answer to the question. Tickletux did not say the question or the answer had any particular significance. He said just one thing, and on the basis of that one thing I know exactly how to evaluate the solution in this post.
What Tickletux said was, “The question serves to weed out people who cannot program AT ALL.” His pass or fail for the question was whether you can make the code work in under fifteen minutes over the phone. The purpose was to NO INTERVIEW a candidate if they are unable to answer the question. But if they do answer teh question correctly, they win an interview, not a job, so you use the interview to discover whether they are bored, smart, prone to showing off, like to have fun, or enjoys writing the obscure.
It doesn’t matter to me why the candidate would write the above code, or how it works. It just matters whether it works and whether the candidate was able to whip it up in fifteen minutes or less.
If you want to draw a lot of conclusions about what kind of production code the candidate would write, you need to modify the question, such as “write the code EXACTLY AS YOU WOULD IN PRODUCTION.” Then you can spend all day talking about the unit tests, comments, brace placement, and so forth.
Why have this incredibly complex hidden agenda behind a phone screen question?
November 9th, 2007 at 1:04
The question I ask is, if an interviewee is not supposed to give that sort of answer, should an employer set that type of question?
I invariably get asked in interviews to decipher some badly written/unnecessarily cryptic piece of code. In one interview I tried pushing back:
Me: I would never write that kind of code.
Interviewer: well, assume someone else wrote it and you needed to debug it.
Me: Don’t you have coding standards? Code inspections? I doubt that code would pass.
Interviewer: Look, let’s say we didn’t have time to do an inspection. What does the code do?
Me: Well, in that case I probably haven’t got time to decipher someone else’s bad code, I would rewrite it from scratch.
I was not offered the job.