I would not categorize FizzBuzz as a puzzle. It is one of the most straight-forward ways to test for an understanding of iteration and selection. Those are fundamental building blocks that all programmers must know.
Your point about anxiety under the unusual pressure is valid. However, I personally find that to be a useful datapoint in the interview process as well. This is especially the case for a startup with time pressures or a role that may interact with customers. Otherwise, the onus is on the interviewer to set the applicant at ease.
I've had successfully interviews where everything flows, and I've had awful interviews where my head inexplicably seizes up. All I'm saying is that the anxiety of interview pressure has very little in common with the anxiety of time-pressure, as far as I can tell. I would take it more as a signal that a person should not be put into negotiations (because that's what an interview really is), rather than that they do not perform under time-pressure.
Last week I was doing a video interview, and at the end they asked me to solve a simple problem and they were going to record it. I felt an incredible pressure to do it right and fast, which lead to basically screwing it up on the first attempt on account of not actually reading the question carefully (or at all really; it was a piece of code where I had to fill in some things, and I misunderstood because I barely skimmed the comments in the perceived pressure). I then a had state of near-panic where I almost just ended the call, from which I just barely managed to recover to stumble towards a solution. It's the closes I've ever come to an anxiety attack by far, which was an entirely novel experience and very much unlike me. I did end up solving it in a reasonable amount of time, but the way I got there was ... roundabout.
The question was to square a value in-place with a pointer: not very hard at all, literally one line of code. In the moment however I was genuinely doubting if I even knew what "squared" means; I really blanked in a way I don't recall ever having done before in my life :-/ I don't know why, but being watched by someone judging you just makes a huge difference for some reason. I've actually never had to write code while someone was watching before in an interview setting (plenty of verbal questions, "take-home tests", and the like, but never any actual code writing).
I had my second interview already with the third planned, so I guess I didn't do as dramatically bad as I felt I did after the interview, but still... If it had been the wrong day I might have outright failed.
It was a very weird experience and I'm not yet sure what exactly to make of it since it was fairly recent, but I gained some new appreciation on how some people might flunk simple interview questions I didn't have before.
The modulo operator is rarely used in practice, unless you're writing your own hash table or some other internal where bucketizing by some ID is relevant.
Using the modulo within a for-loop though, virtually never happens.
So unless you're niche where using modulo every other day, or you're just out of school where you just learned about "+,-,*,/,%" , you have a good chance at failing fizzbuzz if you don't remember it's "that modulo 3 and modulo 5 silly puzzle"
There are better ways of testing for iterating, iterating through a real collection of elements is already much better than FizzBuzz.
Stuff I want
Extra stuff belonging to the above line I want to ignore
More stuff I want
More ignore stuff
[..etc..]
Another example of "% 2" is for centre aligning strings in a grid (e.g. a terminal; if it's odd you need to add one extra space to one side). I've also used it for time calculations (e.g. printing seconds as "hour:minutes:seconds").
That's from the top of my head; I've probably used it in other things as well. Note this is all high-level application work: no muckery with low-level controllers, firmware, or whatnot.
Is the % operator very common? No; but I don't think it's as "virtually never happens"-uncommon as was mentioned a few posts up the thread.
I guess I generally agree with the sentiment of your post, but if you have issues reversing a string (brute force) I’m not sure how you’d ever get to sliding window functions.
My biggest problem is that it doesn't have any correlation to the actual job. Coding on a white board, under stress, with multiple tech and non-tech people watching you, with a sub-30 minute time cap, with no access to the internet or debugging tools other than an interviewer who may or may not just be trying to look smart to the other people in the room, is almost entirely the opposite of what an SDE does day-to-day.
I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. Solving programming "puzzles" is completely different than day-to-day work, especially at small non-startup shops, where you're doing line-of-business stuff and maybe a new project every 5 years. It's maintenance 99% of the time. You don't need to know how to reverse strings to implement a recursive sliding window function.
This is how we've done hiring at my current company so far and it's worked out better than any of the places I've been that used puzzles or language trivia.
1. As always, lean on your network. 1st- and 2nd-level connections will already have a lot of previous vetting completed.
2. Interview primarily for team fit. You can teach people technical details easily if they're otherwise qualified. You can't teach someone not to be an asshole, and having an asshole on the team will drive away good people who don't want to deal with it.
3. Have a very clearly communicated probationary period. We use 30 days but honestly 2-3 weeks is plenty. If things aren't working out, cut them in this period.
4. As part of #3, check in a lot more than you otherwise would during this time. We do a management one-on-one every two weeks, so we'll do daily technical one-on-ones during the first week or two of onboarding. We've let one person go during the probationary period because of performance and without these meetings it would've taken weeks longer than it did.
5. Have onboarding. Docs, calls with a defined itinerary, whatever. But don't just drop people into the thick of it if you're doing this type of interviewing.
6. Actually request references and talk to them. You'd be surprised how candid former managers will be about someone's previous performance, even when they're not supposed to be.