Why the FizzBuzz Interview Question Still Filters Senior Devs

Eleven years of experience. Staff-level resume. Clean GitHub. I opened the screen share the way I always do: "Let's warm up with something small. FizzBuzz, five minutes, any language you like." He spent twenty-two minutes on it and never got it fully working. That was the day I stopped treating the FizzBuzz interview question as a joke question.

He was not a fraud. I looked at his code later, in his own repos, and it was good. Better than mine in places. What happened in that call had nothing to do with the modulo operator.

TL;DR

• FizzBuzz is not a difficulty test. It is a bandwidth test: can you produce correct code while narrating it with a stranger watching?
• Almost nobody fails on %. They fail on conditional ordering (checking 15 last, where it can never run), on freezing silently, or on over-engineering twelve lines into a rules engine.
• Interviewers use the warm-up to calibrate the real problem. Burn twenty minutes here and they quietly shrink the hard question, which caps your score before you even see it.
• A good answer takes four to six minutes: say the 15 case out loud, write it, hand-trace one example, stop talking.
• Practice the narration, not the algorithm. You already know the algorithm.

What does the FizzBuzz interview question actually test?

It tests whether you can convert a two-sentence spec into control flow without a search box, while your working memory is being taxed by an audience. That is the whole thing.

The spec is famously trivial: print 1 to 100, but multiples of 3 become "Fizz", multiples of 5 become "Buzz", multiples of both become "FizzBuzz". Every part of that is first-week material. The interviewer knows it. That's the point. When the problem is this small, the code stops being the signal and everything around the code becomes the signal.

What I am actually watching:

• Do you handle the overlap case before you write anything? The word "both" is right there in the spec. Half of candidates never say it out loud.
• Do you name a range boundary? Is it 1 to 100 or 0 to 99? Inclusive? Asking takes two seconds and tells me you read specs.
• Do you check your own work? Running n=15 through your code by hand, unprompted, is worth more than the code being right on the first try.
• What do you do when you're stuck? Not if. When. The recovery is the data.

Why do senior engineers fail FizzBuzz?

Because senior engineers spend their days in a completely different mode than the one FizzBuzz demands. Their real work is asynchronous, tool-assisted, and unobserved. FizzBuzz is synchronous, bare, and observed. Those are different skills, and only one of them gets practiced.

Here are the three ways I've watched it go wrong, in order of frequency.

1. The unreachable branch. This is the classic, and it is still the most common failure I see:

for n in range(1, 101):
    if n % 3 == 0:
        print("Fizz")
    elif n % 5 == 0:
        print("Buzz")
    elif n % 15 == 0:
        print("FizzBuzz")   # never runs. 15 already matched n % 3.
    else:
        print(n)

That code runs. It prints. It looks fine at a glance. And it is wrong for every multiple of 15, which is exactly 6 of the 100 lines of output. If you never test n=15, you will ship it and say "done" with confidence, and I will write down that you declare victory without verifying.

The variant is three separate ifs with no elif, printing "Fizz" and "Buzz" on two lines instead of one. Same root cause: the overlap case was never modeled, only patched.

2. The freeze. Somebody says "FizzBuzz" and the candidate's brain hands back an error page. They know this is supposed to be easy, so being slow at it feels like public humiliation, so the anxiety spikes, so they get slower. I have watched people who lead teams type for i in and then stop moving for forty seconds.

The freeze is not fatal on its own. Silence is what makes it fatal. If you say "give me a second, I want to get the both-case right before I write the loop," you've turned dead air into deliberate thinking, and I score it as deliberate thinking. If you just go quiet, I have nothing to score except the empty editor.

3. The over-engineer. The reverse failure, and it's mostly senior people. They hear "trivial problem" and assume the real test is elegance, so they open with:

RULES = [(3, "Fizz"), (5, "Buzz")]

def fizzbuzz(n: int) -> str:
    return "".join(w for d, w in RULES if n % d == 0) or str(n)

I love this function. It is the better design, it scales to (7, "Bazz") for free, and it is the right answer to the follow-up. As an opening move it reads as showing off, takes longer, and any bug in it is harder to talk through. Write the boring version, get it correct, then say: "if we expect the rules to change, I'd restructure it as a rules list." Now you get credit for both.

Is FizzBuzz still a fair question when AI writes it instantly?

Yes, and the reason is that the typing was never the expensive part. Any model produces correct FizzBuzz faster than you can read the prompt. That doesn't retire the question, it just relocates the signal: the interviewer is no longer buying the code, they're buying the running commentary that comes with it.

Which is why it got harder to fake, not easier. In a live round, the gap between code appearing and the candidate explaining the ordering of their own conditionals is a loud gap. I don't need to catch anyone. I ask "why is the 15 check first?" and listen.

So the muscle worth training is speaking fluently while writing simple code. That is an oddly specific skill, and reading solutions doesn't build it.

That's the gap I built Preterview to close for myself, full disclosure: I built it. It runs a voice interview with an AI interviewer, so you're forced to answer out loud in real time instead of nodding along to a solution you already understand, and it scores your resume and portfolio into a written report afterward. Talking through the easy warm-up under mild pressure is the part nobody rehearses, and it's the part that decides the first ten minutes.

How do interviewers score the warm-up round?

Mostly as a calibration reading that sets the size of the next problem. There is rarely a line on the scorecard called "FizzBuzz." There is very much a decision, made around minute eight, about what I ask you next.

Five-minute warm-up: you get the real problem with room to breathe and forty minutes to look strong on something that actually differentiates candidates. Twenty-minute warm-up: I either submit a writeup based on a toy exercise, or hand you a shrunken problem with no time to finish. Both produce a weak packet. The hard round is where "hire" gets earned, and you spent it on Fizz.

This is the part candidates underrate. You cannot pass an interview in the warm-up, but you can absolutely cap it there.

What does a good FizzBuzz answer look like?

Roughly this, in this order, in about five minutes.

1. Restate and pin the edges. "1 through 100 inclusive, printing one line each. Multiples of 15 print FizzBuzz, so I'll check that first." Twelve seconds, and you've pre-empted the single most common bug.
2. Write the boring version. if n % 15, then 3, then 5, then else. No cleverness.
3. Trace one value out loud. "n=15: first branch hits, prints FizzBuzz. n=9: skips 15, hits 3." That's your test suite, and it's free.
4. Offer one improvement, don't build it. Mention the rules-list version, or the string-concatenation version, in one sentence. Let the interviewer pull if they want it.
5. Stop. Say "that's my answer, want me to extend it or move on?" Ending cleanly is a signal too.

If you want the extension in your pocket: the follow-up is usually "now add 7 → Bazz" or "return a list instead of printing." Both are trivial from the rules-list version and annoying from the nested-if version, which is exactly why mentioning it in step 4 pays off.

So why does FizzBuzz still filter senior developers?

Because it removes every advantage seniority gives you. No architecture to reason about, no ambiguity to negotiate, no codebase context to leverage, no time to think alone. What's left is a small mechanical task performed out loud under observation, and that is a skill you stop practicing the moment you stop being junior. The candidates who breeze through it aren't better engineers than the ones who stall. They're the ones who have recently practiced saying "multiples of both go first" before typing. Say the overlap case out loud, write the boring version, trace one example, and stop. Five minutes, and the rest of the hour is yours.