[lucb1e]

I haven't done it in a while and never practiced it specifically, 10 minutes sounded quite short for writing working code. Looking up the description again and timing myself now (starting the timer after reading the description, since I didn't know how long it'd take to find a good description whereas that's a given at the interview): yeah okay, that took 63 seconds for printing the results for the range 0-100. Good interview question, quick and easy enough (though I don't use n%x==0 a lot in real coding, it has come up and it's a basic enough task).

Thanks for the answer!

[selcuka]

> I don't use n%x==0 a lot in real coding

I use it all the time, especially when logging the progress of a long running process at every x records.

[lucb1e]

True, I use it there as well -- and then often wish afterwards that I had done a more expensive call to get the current time to print every X seconds instead of after an arbitrary number of records. Combining the two (with a fairly low %x) is probably the right answer

[ufmace]

Yup, that sounds about right.

I'd also note that one of the reasons I prefer doing such things in person is (in addition to not taking up too much of the candidate's free time) that if they misinterpreted something or are going off in the wrong direction or something, I can correct them right away instead of letting them waste a bunch of time. This also lets you see how they tend to interpret instructions and take criticism and corrections.

It's also IMO a failure mode for a candidate to get a simple task that should be done in 5-20 lines of simple code and try to build some over-complex super-modular and extensible thing for it, and resisting correction on it not needing to be that over-engineered.

[jimberlage]

The one piece of help I will offer in FizzBuzz is a reminder of how you can use the modulo operator, for exactly that reason.