I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem.
If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question?
Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching?
How would you try and separate out the best of your co-workers from the rest in a day or two?
I would submit that humans cannot easily be ranked from “best” to “worst”; and even the most genuine attempts at doing so will only capture it for a moment in time as both the individuals’ skills and the business’ needs are constantly in flux.
And yeah, I feel you can adequately gauge someone’s skill level across a technical subject area in 4 or 5 simple “how would you” questions. The way they explain it will tell you a lot about their understanding of the subject matter. In the old days (when we were in-person and I was still a technical SME) I would have them use a whiteboard to explain a technical concept to me.
This job is not that hard. I think a lot of companies have an overly fond view of themselves and most of these complex interview processes are for their own ego.
I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem.
If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question?
Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching?
How would you try and separate out the best of your co-workers from the rest in a day or two?