2.8 — Checkpoint: FizzBuzz, visualized
Checkpoint — and not just any exercise: FizzBuzz is the most famous interview question in software. The rules: count from 1 to 15; for multiples of 3 say “Fizz”, multiples of 5 say “Buzz”, multiples of BOTH say “FizzBuzz”, otherwise the number. Sounds trivial. Contains a trap that catches real candidates every single day. You already own every tool it needs.
for (let i = 1; i <= 15; i++) {
if (i % 15 === 0) {
console.log("FizzBuzz");
} else if (i % 3 === 0) {
console.log("Fizz");
} else if (i % 5 === 0) {
console.log("Buzz");
} else {
console.log(i);
}
}The solution: a for-machine (lesson 2.6) around a gate corridor (lesson 2.3), with the remainder operator % (lesson 1.5) asking “divisible?” — i % 3 === 0 means “dividing by 3 leaves nothing over.” Familiar parts, new song.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
Why do interviewers adore something this small? Because FizzBuzz quietly tests four things at once. Loop mechanics. The % operator. Condition ordering (the trap). And whether you check your own edges: does 15 actually print FizzBuzz? Does 1 print 1? That last habit — picking the inputs that would expose the bug — is literally the tester’s craft.
The values worth checking here: 1 (plain), 3 (Fizz), 5 (Buzz), 15 (the collision), and 0 or negative if the range ever changes. Choosing revealing inputs like that has a name you’ll meet formally in Phase 10: boundary testing.
The dead-code failure mode deserves respect: a mis-ordered FizzBuzz never crashes, never warns — it just silently never says FizzBuzz. Software is full of exactly this: branches that can’t be reached, conditions that can’t be false, tests that can’t fail (the most dangerous kind!). None of them announce themselves. The instinct you practiced today — “walk a specific value through the gates and see which one grabs it” — has a big future. It is the manual version of what code-coverage tools automate. It will serve you in every code review of your career.
Fun fact: FizzBuzz began as a British children’s counting game (kids in a circle, replacing numbers with words, giggling at whoever slips). It entered programming lore in 2007, when a developer suggested it for screening job candidates. A famous blog post amplified it, reporting that a surprising share of applicants with impressive CVs could not write it. Two decades later it is still asked daily around the world — and still filtering — mostly on the exact gate-order trap you just sidestepped.
🎛️ Run the machine yourself
Pick how far to count (1–100) and watch the rhythm emerge — Fizz every 3rd, Buzz every 5th, FizzBuzz where the rhythms collide.
🎓 The real graduation:
On a computer, open your browser console (F12) and write FizzBuzz from scratch — no peeking at the code above. (On iPad there’s no console — talk each number through the gates out loud, checking yourself with the explorer above.) Then the twist interviewers love: change it to print “Jazz” for multiples of 7. Where does the new gate go, and why? (Think 21. Think 35. Think 105.)
✏️ Quick check 1
Type what 12 % 5 gives:
✏️ Quick check 2
A broken FizzBuzz puts the %3 gate BEFORE the %15 gate. Type exactly what it prints for the number 15:
✏️ Quick check 3
You may test a FizzBuzz implementation with ONE single input. Type the number most likely to expose the classic bug.
🗣️ Now teach it back
The interview simulation: explain your FizzBuzz solution out loud — the loop, the % trick, and WHY the %15 gate must come first (prove it with the number 15).
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.