It's interesting, because I do my very best work (and am happiest) in an environment of time-pressure, but something about the interview setting causes me to freeze up, lose my tongue, and lose my brain, all at once. If the question is very very easy, the effect is far worse. I've been on the other side of the interview process, and knowing how it might appear just makes this feel all the more traumatic. The brain focuses on the scenario of the interview, instead of the scenario of the question at hand.

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.

I'm never anxious during job interviews, or anything else really: I just take things as they come and I'm fairly stable under most pressures.

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.

FizzBuzz is one of those puzzles where majority of experienced programmers won't find the solution easily as it involves the modulo operator in weird ways.

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.

I'd never considered the modulo operator to be that uncommon, but I've mostly worked in systems software and firmware. Is that really the case?

The only time I've ever used it in programming is FizzBuzz.

To prevent rehashing this, I have discovered the exact same discussion from 5 years ago.

https://news.ycombinator.com/item?id=11884645

Curious: How do you do “every other row” in a loop if you don’t do modulo?

Not advocating for being oblivious about modulo op, but you could use stepping in some languages. Example, in Kotlin: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/s...

Why would you want to do every other row in a database? That just sounds like "a random half" with extra steps if you're doing math on your DBMS's equivalent of RowID.

Things like applying a different colour or styling for visual effect is a common-ish reason, or parsing some input which looks like:

  Stuff I want
  Extra stuff belonging to the above line I want to ignore
  More stuff I want
  More ignore stuff
  [..etc..]

Which can be from a CLI tool, a web scraper tool, something copy pasted from a webpage, or something like that. This data can often be "messy" but in a regular way. I've parsed WikiText tables from Wikipedia like this (very crude, but it only needs to run once).

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.