
FizzBuzz, minus the modulo operator, plus grit - braythwayt
http://www.globalnerdy.com/2020/06/17/programmer-interview-challenge-2-part-3-fizzbuzz-minus-the-modulo-operator-plus-grit/
======
braythwayt
FWIW, I prefer the "grit" solutions. No modulo, no faking/implementing modulo.
Why?

Because the original child's game isn't about "If a number is divisible by X,"
it's about "Every Xth number." And directly implementing "every Xth" can be
interesting.

------
java-man
This is all good, until someone in Product changes the requirements. Now
instead of 3 and 5 they need 7 and 11.

All these clever tricks will require a complete re-write and re-test. And
since the company decided to pick theit employees based on how they answer
these tricky interview questions, the code base is full of opaque
idiosyncrasies with unexpected dependencies. Four sprints later, the code is
put into production and some other part breaks, causing the company millions.

~~~
braythwayt
The pleasure of solving eccentric problems is, of course, a completely
separate thing from the question of, "What is the efficacy of asking job
candidates to solve well-known programming puzzles?"

When nobody had heard of fizzbuzz, it had a certain value for screening out
complete no-hopers when no other signal was available. There were other
methods for achieving such a goal, but it had _some_ utility.

Today, using it for job screening it acts like a membership test. "Hey! Are
you a member of the programming culture? Have you scoured the internet for
examples of problems posed in job interviews? Prove it! Write fizzbuzz!"

~~~
braythwayt
There's another thing about your comment. I suggest you reflect on this:

If you believe that someone who solves fizzbuzz in an idiosyncratic way would
also do everything at work in an idiosyncratic way, you are essentially
supporting the value of asking programmers to solve programming problems in
job interviews.

I have a different belief. I have written a blog post on the subject, but the
TL;DR is that the purpose of this kind of test is strictly to get rid of
impostors whoc an't do any programming whatsoever.

The moment you are convinced that they are not a complete no-hoper, you can
stop the test and get on with teh real interview.

As such, I believe it is harmful to take anything other than a single bit of
information from it: Can/Can't.

If you actually study how they got it to work, and make extrapolations about
them from it, you are incentivizing people to write millions of units tests,
ask you whether there is a roadmap for future changes, set up a repo on github
and submit their solution as a PR, &c. &c.

If that's what you want to know about a candidate, fizzbuzz is a ridiculously
inadequate test.

