This page may be out of date. Submit any pending changes before refreshing this page.
Hide this message.
Quora uses cookies to improve your experience. Read more
Robert Walker

Just to say, if you try this test you could add a curve ball that would catch out just about anyone who has looked it up on the internet probably.

They will probably come up with something like:

for i in range(1, 100):
 if i % 3 == 0 and i % 5 == 0:
  print "FizzBuzz"
 elif i % 3 == 0:
  print "Fizz"
 elif i % 5 == 0:
  print "Buzz"
 else: 
  print i

see

Gayle Laakmann McDowell's answer to Are there really programmers with computer science degrees who cannot pass the FizzBuzz test?

Which is a perfectly good solution to the problem.

After they've written their solution, then ask them to edit it to add an extra case to say "Bang" if the number is divisible by 7. And another case add "Click" if divisible by 11.

That will test how good they are at writing code that can be extended easily to cope with new cases.

Here is how I would do it - I'm a c programmer so here it is in c:

int i=0;
char token[100];
for(i=0;i<100;i++)
{
 token[0]='\0';
 if(i%3==0)
  strcat(token,"Fizz"); 
 if(i%5==0)
  strcat(token,"Buzz");
 if(token[0]=='\0')
  sprintf(token,"%d",i); 
 printf(token);
}

It avoids the duplication, and to a c programmer I think a bit easier to read.

Especially, it's easy to add more cases if the specification changes in the future

int i=0;
char token[100];
for(i=0;i<100;i++)
{
 token[0]='\0';
 if(i%3==0)
  strcat(token,"Fizz"); 
 if(i%5==0)
  strcat(token,"Buzz");
 if(i%7==0)
  strcat(token,"Bang");
 if(i%11==0)
  strcat(token,"Click");
 if(token[0]=='\0')
  sprintf(token,"%d",i); 
 printf(token);
}

or whatever. It's easily extendable.

While the version suggested would get much more complicated if you add even just one more case, and the more you add the more tricky it would become to make sure you have covered all bases.

It would have to be

if i % 3 == 0 and i % 5 == 0:
 print "FizzBuzz"
elif i % 3 == 0 and i%5 == 0 and i % 7 == 0:
 print "FizzBuzzBang"
elif i % 3 == 0 and i % 7 == 0:
 print "FizzBang"
elif i % 5 == 0 and i % 7 == 0:
 print "BuzzBang"
elif i % 3 == 0:
 print "Fizz"
elif i % 5 == 0:
 print "Buzz"
elif i % 7 == 0:
 print "Bang"
else
 print i

And that's just got us as far as the i%7 == 0 case. Each new case would approximately double the number of cases to consider, instead of just adding one case. And it would be very easy to miss out a case or two there and so create buggy code.

So - though in this tiny code example it doesn't make a significant difference, for as long as you have only two cases to consider, I think this idea of looking for a neat solution can help you to make easy to edit code, less likely for you or anyone else to introduce bugs while editing it in the future.

So, if you want to be a bit sneaky, you could ask your candidate to do the Fizz Buzz test. They probably know it off by heart. Then say "Now add an extra case, if the number is divisible by 7 print "Bang"

And after they struggle with that, then say "Now add the case if number is divisible by 11 print "Click"

That might teach them something about writing code that is easily extensible in the future :).

So - you wouldn't expect them to sort it out right away, but you could learn something perhaps from watching what they do.

That's my top priority as a programmer actually. Nowadays speed of code is of no relevance at all iln most situations, except when optimizing a very tight loop or if a function is extremely inefficiently coded. But code that is easily extended to more cases is a huge time saver.

How you program it would depend on how you think it is likely to be generalized in the future.

So for instance, suppose instead the new spec is exactly as before but you need to write "foo" instead of "Fizzbuzz", then my version is no good for that.

Instead you need to go back to the else if version and have

if(i%15==0)
 printf("Foo");

So, you are bound to often make wrong guesses about future generalization, unless you already know what the future specs will be which is rare - but thinking about it often means you do save time, although from time to time it means you have to rewrite your code, but you are less likely to need to rewrite your code I think than if you don't think about it at all.

See discussion: https://www.quora.com/Are-there-...

About the Author

Robert Walker

Robert Walker

Writer of articles on Mars and Space issues - Software Developer of Tune Smithy, Bounce Metronome etc.
Studied at Wolfson College, Oxford
Lives in Isle of Mull
4.8m answer views110.3k this month
Top Writer2017, 2016, and 2015
Published WriterHuffPost, Slate, and 4 more