> Richardson also encourages hiring and engineering managers to test candidates on collaborative problems during live-coding tests, instead of simply observing how an engineer is working alone.
This can be just as terrible as a twelvw-hour take home. Having a stranger state at you while you're trying to code under pressure can make some fantastic programmers into deer in the headlights. Unless your company only works that way you should have this kind of test only as an option.
I think one of the most trying things that ever happened to me was when I was working on a time critical task and my manager suggested I switch to the desk besides his for the time.
It was really distracting to have someone checking my screen all of the time, which is why I remember this episode right now. Even worse, no 15 minutes went by without him breaking my concentration by asking a question or making some vague suggestion until I politely but firmly told him that I really need to be able to concentrate if he wants the job to get done on time, and that he isn't helping.
Collaboration doesn't have to mean staring at someone while they're trying to code.
Collaboration in actual programming work tends to be up front in figuring out together how a problem will be solved, as needed while working through the problem, and then review at the end. A coding interview can be structured in a similar way.
This can be just as terrible as a twelvw-hour take home. Having a stranger state at you while you're trying to code under pressure can make some fantastic programmers into deer in the headlights. Unless your company only works that way you should have this kind of test only as an option.