Fizzbuzz – Why It’s Used In Interviews And How To Solve It

In 2015, a team of 3 Bard Prison inmates beat the Harvard University debate team. (Don’t believe us? Look it up.)

This demonstrates two things. One, that a shiny degree and book smarts don’t guarantee someone knows what they’re doing, and two, that you just can’t beat real world experience!

So, what does street smarts have to do with FizzBuzz; a children’s number game and the cutthroat interview process in software engineering?


If you’re applying for a role in software engineering, odds are you’ll get a variation of the FizzBuzz test.

Never heard of it? Well, in 2007 a self-proclaimed professional geek named ‘Imran Ghory’ developed the FizzBuzz test as a way for interviewers to more accurately quantify a developer’s competence in coding.

It’s based on a game that school children play in the UK, (FizzBuzz), where they sit in a group and each say a number in sequence. If the number is a multiple of 3, then that child has to say “Fizz” instead of the number. Likewise, if it’s a multiple of 5, they have to yell out “Buzz”. However, if it’s a multiple of both 3 and 5 – “FizzBuzz”.

The theory is that most attentive programmers should be able to write out a program that automates this process in just a couple of minutes – after all, it’s a game so easy that even a child can play.


Putting someone on the spot and making them answer a series of intense questions requiring lateral thinking isn’t the greatest tactic for hiring the right person for the job. Nor is picking out a candidate based on how much you like them and whether they’re a good fit for the team.

Yes, both qualities are preferable in an employee, but at the end of the day, all an employer wants to know is if they can code, solve problems, and actually do what they say they can do.

We’ve all met someone who seems like they’re solid at their job, they know their theory and can have a discussion about the work, but when it boils down to it – they just can’t deliver results!

Imran studied these kinds of people in the programming and coding space, and really dialled in on what made them tick. He found that outwardly competent programmers who talk the talk, but don’t walk the walk, didn’t just struggle to code and make their way through complex problems – they got hung up on tiny problems (like FizzBuzz) and couldn’t see their way past them.


Imran’s research highlighted some alarming results. The majority of computer science graduates couldn’t formulate a solution in code to this simple children’s game of FizzBuzz. In fact, he witnessed programmers who had worked in senior software engineering roles take between 10 and 15 minutes to write up a solution on paper – and sometimes even longer!

It’s not that these people can’t write good code, it’s that they take a hell of a lot longer to get it done. In a business environment, where time is money and there are milestone dates and deadlines to adhere to in the development process – you want the sharpest minds on the job, right?

“The sad truth is that 99% of software engineering candidates can’t code their way out of a wet paper bag.”


The FizzBuzz series of questions isn’t designed to pick out and identify the really great programmers. It’s more of a general screening test, a way to separate the exceptional from the mediocre. To weed out the weak performers in both a quick and efficient way before continuing the interview process.

To give you a scope of just how ingrained this test has become in the industry, FizzBuzz is now the most frequently asked developer interview question in the world. Facebook and Microsoft use a version of it as a standard interview protocol, and it’s being taught at Stanford, Berkley, Caltech, and a long list of other Universities.

It pays to be worded up so you’re not caught out in your next interview! It could cost you your dream job.


There is a super simple, straight forward solution to be used but although it gives the correct results, it’s rather naïve and there is nothing particularly clever about it. So, we add a few common software development practices to it in order to make it more elegant and impressive right?

DRY or “Don’t Repeat Yourself” is a principle of software design that eliminates duplication, removes redundancy, and overall streamlines code. Where terms like Fizz and Buzz appear more than once, look to make a case or rule to govern it.

We’ve effectively insulated ourselves from bugs caused by code change in the future, as the more times a term exists within the code, the more chance of forgetting to change a term in a line of code.

Parameterization can also be used to remove the hard-coded constants by turning them into parameters. In the FizzBuzz, this means how the range of integer numbers are covered, the output text, and the multiples that trigger the outputs.

What if the Fizz and Buzz numbers were changed to something like 1 and 7? Or another term like Fazz added in? By using parameters to create triggers, the word term can be used as a divisor and the value attributed to it as an output string for the answer.

We’re not done yet. What if a completely new item were added, like “when divisible by 7, say Tizz”. By ordering your parameters and having them act in order and as functions of functions, you can add in as many multiple triggers and conditions as you want to as a simple, ordered string that produces a final output based on the parameters.

Functional Programming arguably produces better software, and something you want to show you’re capable of doing. We can build on the functional style of parameters by mutating the string just a little bit.

The FizzBuzz function has side effects and prints out text every time it’s called out. By getting rid of the side effects, we now have a pure function, and the range is now changed into an array of outputs that are then returned instead of printed.

The mutation itself can be removed and made more elegant by the addition of a trigger loop, where the map, filter, and reduce implementations combine to produce a purer function.

But is there a better, albeit lazier, way? For argument’s sake, what if you needed to calculate FizzBuzz to the billionth output – you’d run out of memory returning an array containing all outputs. The key is to generate an output value, print it, throw it away, and then start generating again.

By using an infinite enumerator, generating subsequent outputs can theoretically go on forever in a loop without running out of memory – giving you however many outputs of FizzBuzz as you like. It’s not lazy, but more the case of the function doing the least work using the least resources possible in order to give you what you ask of it.


Still confused? Check out these sites that go in depth and show how to tackle FizzBuzz using Ruby, Python and JavaScript.

We hope this blog helped you better understand Fizzbuzz! If you enjoyed this blog you may also enjoy our other blogs like, Data Science: How to Get In And What Hiring Managers Want or Software Engineers: Here’s How to Make Your Resume Irresistible.

Kofi Group is proud to be a source of knowledge and insight into the startup software engineering world and offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more about what we do and how we can help you then get in touch or watch our Youtube videos for additional information.