Ask HN: Why do so many software developers fail the FizzBuzz test?
I've been in the interview loop for my company for just over a year now, and one of the most surprising experiences so far has been the high proportion of developers who fail the most basic programming questions.
We use FizzBuzz as one of our easy challenges and I would say that around 80% to 85% of interviewees simply cannot solve this. It's bizarre. Some even refuse to answer and try to turn their lack of ability around onto us for asking the question, as if we're the ones doing something wrong.
What could be causing this? Is this a generation of AI-reliant copy-and-paste code-jockeys who've never developed the ability to think? Is our hiring process perhaps not screening sufficiently for incompetent bullshitters?
These are candidates who come to us with a solid employment history, often having worked for big name tech giants. But they can't figure out this most basic coding puzzle. What's going on? Has anyone else noticed this phenomenon?
I've definitely seen my share of coders who can sling decent code to maintain and extend an app, but not write anything from scratch. It is quite possible to have a solid career without ever having started with a blank slate. Even starting a new project these days, people often grab a framework that starts them with boilerplate.
So it is not really that they cannot code. It is that they cannot go from zero. If you handed them a bad implementation of FizzBuzz and asked them to improve it, they could. But they cannot write the very first line of code because while the code is trivial, the utter lack of context is a new experience.
Whether or not you want that to be a deal-killer for a hiring process is a much deeper question.
agree mostly, although i'd quibble at saying: "So it is not really that they cannot code". i'd certainly say that being able to open an editor and pound out a functioning 20 line program from scratch is a requisite skill for saying you can code.
"Whether or not you want that to be a deal-killer" - exactly. as annoying as these stupid tests are, at least they tell you something. it's surprising how much so.
Fizzbuzz is a stupid test not representative of anything useful. And I say that as a high school dropout, self-taught programmer who easily passed it, but only because I happened to learn about the modulus operator in some online tutorial years and years ago, purely by chance.
After that, in twenty years of professional dev work, I don't think I used the modulus operator or anything like Fizzbuzz again.
Why test candidates on something completely irrelevant to their work? There are much better questions to ask, or potential take-homes to assign.
As a web dev, for example, I'd much rather get a sense of someone's UX sense or their approach to optimizing async calls or how they deal with framework rot etc. There are a ton of interesting everyday problems candidates actually encounter and struggle with, but that have basically nothing to do with math or contrived loops like that.
Fizzbuzz was never meant to represent anything useful; it's an intentionally trivial problem used to quickly filter out unqualified candidates. In the words of its inventor, "this sort of question won’t identify great programmers, but it will identify the weak ones":
https://archive.is/Ybnm
It filters out a specific kind of programmer, but not necessarily the right kind. Somebody might be great at their job but have no domain knowledge of this sort of problem. It's kinda like how Advent of Code is totally irrelevant to a lot of day to day work.
Like maybe back in the 80s and 90s programming was primarily about logic and math, but that hasn't been the case for a long time now. A lot of business apps are just declarative markup plus client-server networking, not necessarily condition cascades like this (beyond super simple switch statements).
I'd much rather have teammates who, say, pay attention to UX details or write good documentation or are just easy to work with, rather than someone who's good at abstract logic puzzles that don't reflect most day to day work.
The problem with Fizzbuzz is not that it's too hard, but that it's not really representative. If you wanted to test conditionals, for example, basic HTTP success / error handling in a try/catch would be more useful and common.
Fizzbuzz is easy if you have an intuitive sense that some numbers are evenly divisible by 5 and/or 3, and either know modulus or can test it manually, but if you don't have that sort of math background, it tests the completely wrong things (mathematical reasoning rather than business app ability). In the US, especially, math education gets worse every year, but that's not necessarily a good reason to filter out coders who would otherwise be perfectly fine writing standard consumer apps.
I used a variation of rot13, discovering much the same thing.
I try to put myself in the other’s perspective. Firstly, many (myself included) do not respond predictably on “on the spot”. Going cold into a problem is like doing some responsive physical activity, it often takes some mental warm up. The obstruction of “mental tooling” makes a unit of effort in the span of two hours, two weeks, or two month frames.
Solving the problem in “pseudo code”, in which you don’t actually intend to run it for instance reduces the anxiety of the dev environment not working in exactly the way you require for your iterative dev round trip. Even if it isn’t actually a problem, our mindsets are actually slower switching intellectual frames, where those frames may be compartmentalized competence.
Is that compartmentalized competence in there, and can I get it out? Is it wrapped in a tolerable character? So many dimensions set us apart.
I'm sorry, but I never ask developers about things like FizzBuzz.
When you get a developer, they are joining a project that they know little about, and the value they bring is how quickly they can adapt to the problem space and solution space that your project sits in.
I'm going to call them 'trick questions' when you start asking about things like FizzBuzz, as if the smartest of them all will get the role.
In reality, their ability to learn and thrive in the space your project works is the really valuable thing.
Explain the problem space your product sits in, ask them what they think some challenges could be in that niche, see how insightful they are, or how far off the mark they are. Walk them through developing some of their ideas, leaning on your experience in that space. See what evolves, see if they have some insights you haven't thought of.
There are much better ways to evaluate candidates.