At a previous job I was given the mission of constructing a development task that we could let prospective team members complete. Having been on the receiving end of several of these tasks, I had a rough idea of what to include and what to avoid. Basically, I was looking for the smallest possible task that would still give a good glimpse into the developer’s way of constructing code and solving problems.
So I went with FizzBuzz. Or rather, a variation on FizzBuzz. But first, the basic idea of FizzBuzz is to write a program that prints out numbers from 1 to 100. For multiples of three, the number should be replaced by “Fizz”, for multiples of five, the number should be replaced by “Buzz” and for multiples of both three and five, write “FizzBuzz”.
1 2 Fizz 4 Buzz (etc)
Usually whenever someone writes a blog post about FizzBuzz, the comments fill up with examples of how to do it. This is all very well, but my favorite implementation has to be the quite fantastic FizzBuzz Enterprise project on GitHub.
public static boolean numberIsMultipleOfAnotherNumber(int nFirstNumber, int nSecondNumber) {
try{
final int nDivideFirstIntegerBySecondIntegerResult =
(IntegerDivider.divide(nFirstNumber, nSecondNumber));
final int nMultiplyDivisionResultBySecondIntegerResult =
nDivideFirstIntegerBySecondIntegerResult * nSecondNumber;
if (IntegerForEqualityComparator.areTwoIntegersEqual(nMultiplyDivisionResultBySecondIntegerResult, nFirstNumber)) {
return true;
} else {
return false;
}
} catch( ArithmeticException ae ){
return false;
}
}
Pure enterprise at its best!
Anyway, the core of our task was doing FizzBuzz as a C# console application. The added twist was that there should be unit tests that fully covered the logic of which text to print. As an aside we mentioned that it was not necessary to test the console client portion of the code. This was basically inserted to see whether the applicant would leave the 1 to 100 loop untested. Most did, and in my evaluation I did not hold it against them – but it was interesting to see who went the extra mile to make the loop-logic testable as well.
During my time of evaluting solutions I don’t think that we ever actually got one that failed the basic “1, 2, Fizz, 4, Buzz” part of the task. We did, however, get some less-than-satisfactory ways of unit testing parts of the logic. For instance, one candidate only included a single unit test that checked that the modulo operator returned the expected result. Sorry, you fail the test!
It was also possible to fail by writing too many tests, but this was generally preferable to writing too few. A worse way to fail was to write convoluted code with weird flow control statements, etc. The basic FizzBuzz logic isn’t that complicated, so it should be possible to express it in a succint way.
Now, this test was just a small part of the recruitment process, and other criteria weighed far heavier, but sometimes terrible performance on the FizzBuzz test made us skip a candidate. This may very well mean that we missed out on good people, since the test is far from a perfect indicator of future performance. And unfortunately I never had the chance to discuss the solutions with the developers, talking about how they had approached the problem, how they reasoned when writing the code, and so forth. But overall I think it worked out pretty well, and since no two solutions looked the same, it was always interesting to investigate, evaluate and learn.
Finally, our task did not use the words “fizz” and “buzz”, thereby decreasing the potential for finding a solution using Google. No cheating!
Codemeyer.net 