[ufmace]

Yup, I've developed a workflow that starts with writing a brain-dead easy fizzbuzz and gradually adds features and complexity. The way I've done it, it gives you a way to judge levels as well as basic competency.

If you can't, or can just barely, complete fizzbuzz in the allowed interview time with a lot of coaching in your language of choice, then you definitely aren't ready to work as a SWE. If you breeze through all my extra sections in half the time, then you're great. Partway through, and you're probably a decent junior to senior engineer.

[lucb1e]

> fizzbuzz in the allowed interview time

Which would be how long? I haven't practiced it specifically so it would be a good test I guess

[ufmace]

We have a hour total per interviewer. The basic FizzBuzz is intentionally incredibly simple, no reason anyone qualified to be a full time software engineer should take more than 10 minutes to build it in a pre-set-up environment in their language of choice.

[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.