The FizzBuzz test is a simple programming challenge used to weed out “weak” computer programmers in a a job interview. The earliest reference I can find for FizzBuzz is here and the task is as follows:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
Sounds simple, right! And it is. I came across this particular challenge a few weeks ago and I immediately coded it up in R. It probably took me about 5-10 minutes. When you actually attempt it you’ll notice it does require a little bit of thought – which is why it is such a good test! I quickly recognized a solution that would include a for loop and a couple of if statements but when you code the if statements in the order the question is asked you hit a snag:
x <- 1:100
for(i in 1:100) {
if (i %% 3 == 0) { x[i] <- “Fizz” } # This is easy!else if (i %% 5 == 0) { x[i] <- “Buzz” } # Looking good, I’m a shoo-in for this job!
else if (i %% 15 == 0) { x[i] <- “FizzBuzz” } } # Uh oh, this last statement won’t be executed 😦
x # Doh! Not a FizzBuzz in sight!
Trial and Error
So attempt one is a dud but I think this is ok. That’s how I code, that’s how the best coders I know code: trial and error. Try something, note the results, figure out what needs fixing and go again. And this approach is perfectly acceptable with real problems and real data – so long as you’re working offline in sandbox type environments and carrying out all necessary testing.
Note: Trial and error is not a substitute for thinking, but rather a means of avoiding paralysis by analysis. Have a little think, and then so long as you’re not breaking anything, just give it a go and see how the results look. Trying to plan everything out to a T before commencing can be paralyzing – not to mention boring!
Note on the note: Sometimes we do want to give more careful thought before acting, it depends on the risks involved as I’ve discussed here.
Take Two
So I looked at the results and figured, ok, how about I check for the “FizzBuzz” condition first, i.e. numbers which are multiples of both three and five. And hey presto, that simple tweak produces the desired result!
x <- 1:100
for(i in 1:100) {
if (i %% 15 == 0) { x[i] <- “FizzBuzz” }else if (i %% 3 == 0) { x[i] <- “Fizz” }
else if (i %% 5 == 0) { x[i] <- “Buzz” } }
x
Is FizzBuzz a good thing?
There have been many blog posts from eminent programmers on the pros and cons of asking these kinds of “whiteboard coding” questions in interviews. Here is a good example and skimming through the comments is worthwhile too as many practitioners weigh in. Personally, I think it is worthwhile to ask something like FizzBuzz. When I am interviewing people who claim to have R and SQL skills (and the role requires these skills) I might ask them to tell me what libraries or functions or commands they commonly use and I think I can gauge from their response whether they actually code or not.
For example, if they mention google/stackoverflow in their answer I’m comfortable that they know what they’re talking about. A less confident person, someone who is trying to pull the wool over my eyes, might not feel comfortable admitting that they have to use google or stackoverflow to find answers.
Interestingly, when I’ve been on the other side of the interview desk, I’ve never been asked a FizzBuzz question. The zingers I have been asked typically pertain to statistics, e.g. what’s a p-value, what’s a logistic regression model, measures of classification error, etc. But I could see why “whiteboarding” is more of a thing in the software development world as they probably spend a greater amount of time coding than a data scientist does.
Datant 