I’ve been reflecting quite a bit on hiring this past year. My employer, Qualia, has gone through a really large growth spurt, and it’s been a lot fun helping craft the interview process for both ICs and frontline EMs. After nearly 100 interview panels, I feel pretty strongly that you want a question which surfaces disqualifying signals as quickly as possible, so you can fail fast when something’s off. For me, that signal isn’t algorithms or system design. It’s whether someone can handle the extremely simple blocking and tackling of writing code.

Back in 2007, a developer named Imran Ghory wrote a blog post proposing FizzBuzz as a way to screen out candidates who simply couldn’t code (the original post is no longer up, but you can find it on the Internet Archive). The idea took off in a big way. It became arguably the most widely used screening question in software engineering, adopted by companies like Facebook and Microsoft, and taught at Stanford and Berkeley. A children’s game, repurposed as a minimum-bar coding test. Kind of wild when you think about it.

If you haven’t heard of the exercise, it’s based on a children’s counting game: print the numbers 1 to 100, but for multiples of 3 print “Fizz”, for multiples of 5 print “Buzz”, and for multiples of both print “FizzBuzz”. That’s it. A for loop, a couple of conditionals, and a modulo operator. Any working programmer should be able to knock it out in a few minutes.

I don’t use FizzBuzz itself anymore (it’s too googleable at this point), but I use questions in that spirit. Simple problems that test whether someone can actually write a working loop, handle a conditional, and think through basic logic. The kind of problem where, if you told a non-engineer what it was, they’d say “wait, that’s the test?”

The surprising failure rate

The often quoted stat about FizzBuzz is that roughly half of candidates can’t solve it. There isn’t a scientific study behind that number, and others have taken issue with it. Fair enough. Even if the real number is say 20% instead of 50%, that’s still one in five candidates who can’t write a basic program. That’s been my lived experience giving questions like this.

I recently interviewed a frontline EM candidate who had nearly 20 years of experience, most of it at the “principal level” doing architecture work. When I gave him my FizzBuzz-style question, he couldn’t complete it. After 50 minutes, we were still there. To his credit, he told me afterward that it was a wake-up call for him. No hard feelings, but that’s 50 minutes on a problem that should take 10-20min, from someone with two decades of experience on paper.

The interesting signals

The failure cases are obvious. What’s less obvious is how much you can learn from the people who do solve it.

These questions are meant to be brain-dead simple. The answer is almost always 10 to 15 lines of clean, straightforward code. But I can’t tell you how many times I’ve watched a candidate pull out some golden hammer to crack a walnut. One guy reached for convoluted recursion on a problem that was begging for a simple loop. Another decided that Java Streams were the right tool, chaining together collectors and lambdas for something that needed an if-statement. I once watched someone scaffold an entire class hierarchy, complete with inheritance, for a problem that could’ve been a single function.

None of these candidates failed, technically. They got to the right output. But when someone overbuilds a 10-line problem into a 60-line architecture exercise, that tells me something just as valuable as a “did not complete.” It tells me they’re going to do the same thing to our codebase. They’re going to reach for abstractions before they understand the problem. They’re going to add layers of indirection where a simple function would do. Every team has dealt with that engineer who turns a straightforward feature into a framework, and it’s painful.

The candidates I get most excited about are the ones who solve it plainly. A loop, a few conditionals, done. Maybe they clean up a variable name without being asked. Maybe they talk through why they’re not doing something more complicated. That restraint, the instinct to write the simplest thing that works, is genuinely hard to screen for in most interview formats. But a dead-simple FizzBuzz question surfaces it in five minutes.

A question to steal

If you’re looking for a starting point for your own FizzBuzz-style question, here’s one I like. Write a function that takes a size and prints a hollow box, where the border cells are numbered sequentially left-to-right, top-to-bottom, starting from zero and cycling back around after 9 (mod 10). Interior cells are left blank.

For a 3x3:

012
3 4
567

For a 4x4:

0123
4  5
6  7
8901

Here’s a reference solve in Python:

def print_box(n):
    counter = 0
    for row in range(n):
        for col in range(n):
            if row == 0 or row == n-1 or col == 0 or col == n-1:
                print(counter % 10, end='')
                counter += 1
            else:
                print(' ', end='')
        print()

It’s a nested loop, a boundary check, and a mod operator. Maybe 10 lines of code if you keep it clean. But it gives you all the same signal: can they break down a simple problem, do they reach for the right tools, and do they write code that a human being would want to read? Make it your own, tweak the shape, change the rules. The specific problem doesn’t matter nearly as much as keeping it simple enough that the how becomes more interesting than the whether.