[qikInNdOutReply]

In my old job we used to have combined problems for job interviews. First were some easy leetcode, little Big O, all that. But then it got tricky, the problem turned into a "design" part were you could see how the applicant would setup a new system, wether s/he would overdo complexity etc.

Finally we had tests for communication skills. For a unprecise formulated requirement, would the applicant ask us or would s/he over-implement?

Usually there was also something which was noch archievable, for which we substracted points if attempted unsystematically and at all.

It was a good test, because the simple leet code calmed the apllicants, and for the rest you goto see something much more valuable. Their approach to work, their thought process, their output, wethere they would go for Quantity or Quality and could self-manage their workflow.

[xtracto]

The problem with the "easy leetcode" problems is that a lot of them are "gotcha" type of problems: you either know the formula/puzzle-logic/solving-strategy or you'll fail.

I remember asking the typical "traverse an array in spiral" or "traverse this array in diagonals" a long time ago. The problem is that, if the candidate solved it, I just knew they knew how to play with array indexes. And if they didn't do it, I just knew that they got nervous and were not good using indexed arrays... it didn't give me anything.

That's why FizzBuzz is good: it has no false negatives. If a developer candidate can't do it, it means thay cannot code.