The FizzBuzz test asks you to print the numbers from 1 to 100, but print “Fizz” for multiples of 3, “Buzz” for multiples of 5, and “FizzBuzz” for multiples of both. It is trivial on purpose: interviewers use it to filter out candidates who cannot turn a short written spec into working code. If you can solve it calmly and explain your choices, you pass. The interesting part is what a good interviewer does next.<\/p>\n
FizzBuzz is a children’s counting game. It became a programming screen after Imran Ghory wrote about it in January 2007 in a post titled Using FizzBuzz to Find Developers who Grok Coding<\/a>. His point was that some candidates talk well about programming but cannot actually write code, and a tiny exercise exposes that in a couple of minutes. It has been a standard first filter ever since.<\/p>\n The only trap is the third rule. If you check “divisible by 3” first, 15 prints “Fizz” and never reaches the “both” case. Most failed attempts are this exact ordering bug.<\/p>\n The version below returns a list instead of printing, so it can be tested. It builds the word for each number from the rules that match, so “FizzBuzz” appears naturally when both rules match, with no separate case to get wrong.<\/p>\n Output:<\/p>\n If you want the plain version that most interviewers expect first, this Python one checks the combined case first using It prints the same line as above. Both versions run in O(n) time. The first version does one pass per rule for each number, so with Start with the plain one. A working, readable answer in a minute beats an elegant one that you fumble. Then, if the interviewer asks “what if the rules change?”, move to the rule-list version. Three things are worth saying out loud:<\/p>\n Because almost everyone who reaches an interview can produce a working FizzBuzz, interviewers use it as a conversation starter. These are the usual follow-ups.<\/p>\n “Add 7 as ‘Bazz’.” In the plain version this means a new branch for 7, plus 21, 35 and 105 for the combinations, which is where bugs appear. In the rule-list version it is one extra entry:<\/p>\n Output:<\/p>\n Note that 21 becomes “FizzBazz” with no extra code. That is the payoff of building the word from rules rather than listing combinations.<\/p>\n “How would you test this?” Because the function returns a list, you can assert on it. Cover the first value, a multiple of 3 only, a multiple of 5 only, a multiple of both, the length, and an empty input:<\/p>\n This prints Interviewers read your code as a teammate would. Names like Ask what should happen for Some interviewers change the rules to see whether you adapt rather than recite: no modulo operator, no FizzBuzz itself takes minutes to learn, so spend the effort on the habits it tests: reading a spec carefully, writing something that works first, then testing and refactoring it while talking. To practice it with step-by-step hints, AlgoCademy has a Fizz Buzz lesson in JavaScript<\/a> (a Python version<\/a> exists too). After that, the real interview questions get harder quickly, so move on to arrays, strings and hash maps rather than polishing FizzBuzz further.<\/p>\n","protected":false},"excerpt":{"rendered":" What the FizzBuzz interview test is, a correct solution with tests, why interviewers ask it, and what they check beyond it: clean code and extensibility.<\/p>\n","protected":false},"author":1,"featured_media":4382,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,23],"tags":[4],"class_list":["post-4383","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coding-interviews","category-problem-solving","tag-coding-interviews"],"_links":{"self":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/4383"}],"collection":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/comments?post=4383"}],"version-history":[{"count":3,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/4383\/revisions"}],"predecessor-version":[{"id":8935,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/4383\/revisions\/8935"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media\/4382"}],"wp:attachment":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media?parent=4383"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/categories?post=4383"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/tags?post=4383"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The exact problem<\/h2>\n
\n
A correct solution<\/h2>\n
function fizzBuzz(n, rules = [[3, \"Fizz\"], [5, \"Buzz\"]]) {\n const out = [];\n for (let i = 1; i <= n; i++) {\n let word = \"\";\n for (const [divisor, text] of rules) {\n if (i % divisor === 0) word += text;\n }\n out.push(word || String(i));\n }\n return out;\n}\n\nconsole.log(fizzBuzz(15).join(\" \"));\n<\/code><\/pre>\n1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz\n<\/code><\/pre>\ni % 15<\/code> (15 is the least common multiple of 3 and 5):<\/p>\ndef fizzbuzz(n):\n result = []\n for i in range(1, n + 1):\n if i % 15 == 0:\n result.append(\"FizzBuzz\")\n elif i % 3 == 0:\n result.append(\"Fizz\")\n elif i % 5 == 0:\n result.append(\"Buzz\")\n else:\n result.append(str(i))\n return result\n\nprint(\" \".join(fizzbuzz(15)))\n<\/code><\/pre>\nr<\/code> rules it is O(n * r), which is fine for a handful of rules.<\/p>\nWhich version should you write?<\/h2>\n
\n
i % 3 == 0 and i % 5 == 0<\/code>:<\/strong> it is correct, just longer. i % 15<\/code> is fine if you can say where 15 comes from, but it silently breaks if the divisors change to 4 and 6 (their common multiple is 12, not 24).<\/li>\n<\/ul>\nWhat interviewers look at beyond “does it work”<\/h2>\n
Extensibility<\/h3>\n
console.log(fizzBuzz(21, [[3, \"Fizz\"], [5, \"Buzz\"], [7, \"Bazz\"]]).slice(14).join(\" \"));\n<\/code><\/pre>\nFizzBuzz 16 17 Fizz 19 Buzz FizzBazz\n<\/code><\/pre>\nTesting<\/h3>\n
const assert = require(\"assert\");\nassert.deepStrictEqual(fizzBuzz(0), []);\nassert.strictEqual(fizzBuzz(3)[0], \"1\");\nassert.strictEqual(fizzBuzz(15)[14], \"FizzBuzz\");\nassert.strictEqual(fizzBuzz(100).length, 100);\nconsole.log(\"tests ok\");\n<\/code><\/pre>\ntests ok<\/code>. The point is not the assert library; it is that you think of the boundary values (0 numbers, the first number, 15) without being prompted. For more on this habit see the post on dry running code with sample test cases<\/a>.<\/p>\nReadability<\/h3>\n
word<\/code>, divisor<\/code> and fizzBuzz<\/code> are fine; x<\/code>, tmp<\/code> and a2<\/code> are not. Avoid clever one-liners that you could not explain line by line.<\/p>\nEdge cases and inputs<\/h3>\n
n = 0<\/code>, negative n<\/code>, or a non-integer. Often the answer is “assume a positive integer”, but asking shows you notice the question exists. Also ask whether you should print or return, since the original statement says print.<\/p>\nVariants<\/h3>\n
if<\/code> statements, print in reverse order, or make the rules come from configuration. Without modulo you can keep counters that reset at 3 and 5. Be ready to explain the trade-off, because these versions are usually less readable than the simple one.<\/p>\nCommon mistakes<\/h2>\n
\n
else<\/code>.<\/li>\nHow to practice<\/h2>\n