If I didn't know ahead of time that Fizzbuzz is to weed out people who pretty much don't know how to program at all I could actually fail it on an interview. It would go something like this.
They would ask me to write Fizzbuzz. I'd see how simple the problem is and immediately think of something like this (assuming they want it in Python):
def fb(n):
for i in range(1,n+1):
if i%15 == 0: print("fizzbuzz")
elif i%3 == 0: print("fizz")
elif i%5 == 0: print("buzz")
else: print(i)
fb(100)
But then I'd think that this is too simple. That's something you could write just after glancing through a Python book at a bookstore. Surely I should use more language features to try to stand out among the candidates, right?
So I'd probably end up trying something like this:
def fizzbuzz(n, *args):
cur = ['' for x in range(1,n+1)]
for m, postfix in args:
cur = [y+postfix if x%m==0 else y for x, y in zip(range(1,n+1), cur)]
cur = [str(x) if y == '' else y for x, y in zip(range(1,n+1), cur)]
return cur
print("\n".join(fizzbuzz(100, (3, 'fizz'), (5, 'buzz'))))
But Python isn't my main language and if this was a whiteboard problem I'd probably make some mistakes and they would be very unimpressed.
There are problems between fizzbuzz and the leet-code algorithms that are small enough to be solvable in 5 to 20 minutes. I like using one of them to complement other non-code questions.
Fizzbuzz was the leetcode of yesteryear. It's exactly the same concept, just a different unrealistic question.
The leetcode issue is to a large extent caused by, literally, leetcode.com the website. When I first started doing technical interviewing this website didn't exist, so if you developed a question that wasn't too easy or too hard, covered the bases, fitted well into 45 minutes, that you could calibrate the difficulty of on the fly etc - basically a good question - then you could make it last quite a long time.
At some point people started sharing questions and pre-canned solutions online, and many candidates will cheat by looking up answers and copying them from another screen if they can. Also some shady recruiters started leaking questions to candidates ahead of time. That forced interviewers to start constantly inventing new questions.
One of the points I used to make in interview training is that questions are like programs, you have to design them. Some are better than others, they can vary in efficiency etc. Often you can't really know how a new question will work out until you try it a few times. Making a good interview experience for the candidate is hard work and it's easy to screw up, lots of interviewers do and it leads to a lot of bitterness (e.g. questions that are far too hard or specific or don't fit in the available time).
Unfortunately if you're constantly having to invent new questions to keep ahead of the people sharing them and grinding the process, then the quality will inherently get way more variable. By the time you've calibrated the question it's been leaked already. And there are a finite number of programs that it's reasonable to ask someone to write in a short amount of time, so by now these giant databases of interview questions and candidates memorizing the answers at scale makes it harder to get accurate information, which was the only goal in the end. Because indeed the specific tasks themselves don't matter much.
Right, but points 1-5 aren't about these issues you're bringing up.
Sure, people can rote memorize "public static void main(String[] args)", but there's way you can test them their understanding on each of these magic keywords. This would achieve the goal of understanding programming language constructs without unrealistic algorithmic questions.
That's covered in the article, my bullet points were just an attempt at a summary.
Briefly, it doesn't work like that. Interviewing developers is very unintuitive. Many reasonable expectations are violated. There are lots of people who can talk very well and will appear to have a good understanding of programming, up until the point that you ask them to write a program (any program) at which point they can't even start. If you don't force candidates to write an actual working program you will pretty quickly hire people who just can't do it, and then have to fire them later. Yes this sounds totally wrong, everyone struggles with this fact at first. It's sort of like the Matrix. Nobody can be told what interviewing is like from the employer's perspective. You have to see it for yourself.
They would ask me to write Fizzbuzz. I'd see how simple the problem is and immediately think of something like this (assuming they want it in Python):
But then I'd think that this is too simple. That's something you could write just after glancing through a Python book at a bookstore. Surely I should use more language features to try to stand out among the candidates, right?So I'd probably end up trying something like this:
But Python isn't my main language and if this was a whiteboard problem I'd probably make some mistakes and they would be very unimpressed.