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?
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.
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.
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.
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.