If you need a good full-throated argument against this practice, read Garrett Dimon’s Live Coding Interviews.

They exist because companies need to know if you can actually code, but as Garrett says:

At best, they serve as a tolerable de-risking filter for a company that needs an assembly-line hiring process.

It’s clearly fine that a company wants to know if you can code or not, plus all the ancillary things like being able to understand instructions, reason your way through problems, find help, and communicate about all of that.

But doing all that live with a random observer with whom you have zero rapport is just weird.

The underlying problem with live coding interviews stems from trying to create an objective evaluation of skills that aren’t easily quantifiable—and they attempt to do this in a wholly unnatural context with a set of loaded assumptions.

The good news is that companies can get all this information in a better way: the take-home coding exercise. Give people a setup repo with a starter dev environment and problem setup. Then ask them to spend one hour on it and commit their code. The actual interview can then be them talking through how they approached the problem and their code. This is a much closer proxy to day-to-day work, and you’ll learn more about them.

The approach for entry-level roles, senior-level roles, management-oriented, or independent contributor roles will all need slightly different approaches, and complex questions rarely have simple solutions.

Perhaps “just do take-homes” is too simple of a solution, but feels like a step in the right direction to me.

Related

ncG1vNJzZmibmKe2tK%2FOsqCeql6jsrV7kWlpbGdgbnxygo6loK%2BdXZi8pbXNoGSipqSav7e1xLCqaA%3D%3D