I hired a data engineer who was unable write a for loop in their primary language (python).
The task was to write a simple sum of a list, but they had to convert the list to a pandas dataframe and then call some series of arcane functions. I originally thought this was just a preference but when I asked them for the simpler version while standing over their shoulder they were unable to do it.
They had ~8 years of claimed experience at the time and were from a country notorious for faked credentials. Turned out to be an ok hire overall (friendly, hardworking) but definitely lacking 80%+ of their supposed competencies.
Data engineering started off as just another discipline in software engineering, but then the BI people got jealous and anyone who used sql started calling themselves DE. The term is fatally cheapened.
I think he was being a little hyperbolic, but the core concern (that programmers look competent right up until you have them write a FizzBuzz) is very real.
Fizzbuzz is interesting because it relies on either the candidate remembering the modulo operator, or the interviewer allowing them to write a modulo function. I can understand why a candidate could forget how to find the remainder from an integer division.
The bigger issue is not having seen fizzbuzz before, really.
I've always wondered how people who write code could possibly be unaware of the modulo operator. In the 8-bit and 16-bit CPU era, or even just when working with data types of that width, one has to be aware of wraparound / overflow if the value gets too large and that's what modulo is. Is it just developers who came of age in the 64-bit CPU era that have this gap?
When one's primary handling of numbers comes down to either linear (single-dimensional) lists or money, then you won't use modulo very much.
But any time you're walking over a discrete multidimensional list packed into a linear list, or walking over any discrete periodic signal (one very common example would be walking a linear array of screen pixels, walking over pcm samples in an audio waveform, literally 100% of GPU programming and 90+% of SIMD programming) you will want to be able to translate between "how far from the start am I" and "how far into the current cycle am I", and modulo handles that.
Similarly for almost anything involving time calculations (and for the same reason: because they are periodic). Modulo is literally described as "clock arithmetic" after all.
So you are absolutely correct that there do exist avenues in programming which can dodge this particular raindrop, I hope you aren't opposed to the idea that they are at least few and far between? ;)
>I hope you aren't opposed to the idea that they are at least few and far between? ;)
Absolutely not. Part of the reason why I mentioned the areas that I work in, are for that reason. I suspect that the vast majority of software jobs are of the kind I mentioned.
As the HN user 'strken' correctly pointed out, fizzbuzz can stump an experienced job candidate if he has never used the modulo operator.
Fizzbuzz is not the least bit interesting on a technical level. It's interesting because even though it's trivial to "cheat" (you can just learn/memorize Fizzbuzz specifically), it still works because people so incompetent they can't even write something as trivial as Fizzbuzz are unlikely to have heard of it.
Fizzbuzz is used to confirm an already present suspicion of complete incompetence, not to assess skill (ability to pass is not a meaningful signal).
I said "interesting" but I really meant "bad". You might as well test someone on whether they remember bitwise operators.
I feel that you did not address the specifics of what I wrote. It's a silly test because it's meant to cover the bare basics but it still relies on knowing/remembering the modulo operator, which junior hires might reasonably not have seen. If everyone didn't already know about fizzbuzz it would be even more stupid.
I’ve personally experienced devs who could not sum a collection of ints, “in any language of your choice”.
I’m not talking about devs who got hung up on integer overflow issues (or even off-by-one errors), but rather “just couldn’t get started at all”. I have no idea what they did before or what they expected to do if they got the job, but I doubt it would turn out well.
Yep, I've seen that too. I start with "sum an array of ints" due to the known problems using fizzbuzz, and there are software engineer candidates who can't or won't do it. Nobody believes you until they see a candidate like this themselves.
My pet theory: A lot of companies are very, VERY big, and a clever person who doesn't know how to do their job but can identify a weak manager, can simply get lost in them. Hiding away getting the paycheck, but doing nothing except convincing their manager they're doing things. I've definitely met a few people in my career that I believe were doing exactly that.
I don't have a good explanation for how candidates with zero ability to write code can make it through a hiring funnel to sit in front of you. Maybe they don't know what they don't know.
No, fizzbuzz trips people who already have a job because they make two for loops, make too few IFs, or generally don’t have a logic mindset and get out of the interview saying “This is not something that’s asked for in the job!”
I'm probably the person ya'll are hating on.
Writing code and writing code under pressure while you have a full blown anxiety attack are not the same thing. I'm lucky if I can accurately tell you what I had for breakfast once that triggers..
If you program daily, but were nervous during an interview, I would have been able to tell and always tried to get candidates comfortable before getting into any programming - talking about something they liked or were passionate about, reframing my questions in terms of something we talked about or was on their resume.
I found most of the people who couldn’t program were not the nervous ones, but were smooth talkers who probably didn’t write much code. Maybe they did at one point, maybe they never did, it was hard to know, but I couldn’t get even logical steps to solve straight forward problems out of them. Those were the worst interviews, not because the candidate wasn’t a fit for the role, but because then I had to panic to try to keep the experience positive, constructive, and collaborative. When I expected to fill 20-40 minutes talking through a problem with someone who can’t solve problems, let alone produce anything remotely looking like code, I always found that painful.
The questions I asked could be solved by non-programmers (my wife, who was an elementary teacher and even my kindergarten son could come up with reasonable solutions, but of course not code). That was probably the biggest issue I ran into with nervous people - they didn’t think about the problem first, they’d try writing code before really thinking through. That was usually easy to correct and I didn’t fault anyone who could handle correction and guidance.
The task was to write a simple sum of a list, but they had to convert the list to a pandas dataframe and then call some series of arcane functions. I originally thought this was just a preference but when I asked them for the simpler version while standing over their shoulder they were unable to do it.
They had ~8 years of claimed experience at the time and were from a country notorious for faked credentials. Turned out to be an ok hire overall (friendly, hardworking) but definitely lacking 80%+ of their supposed competencies.