[jamesgill]

The problem with live coding interviews is that they shouldn't exist.

Another problem is that we're prone to thinking that being able to do well on tests equates to doing well in life and work--despite a stunning lack of evidence in support it.

[emodendroket]

So what do you propose? Picking names out of a hat?

[jamesgill]

We expect too much of 'interviews', so we've built an entire structure around them: 'behavioral' questions, whiteboard exercises, resume keyword scanners, long, tortuous lists of 'qualifications', elaborate processes of multiple interviews, etc.

After many years of sitting on both sides of the table, I've have come down to this: "hire lightly and fire lightly". In practice, this means beyond the (very) basics, hiring is not algorithmic; it's a crapshoot.

[emodendroket]

Well if I have two openings and five people what way do you think is more fair to choose among them?

[anongraddebt]

On average, any random company will be filled with solidly average engineers. Which means, because of how numbers work, most of the engineers are neither good nor bad at engineering. They’re just mediocre.

Companies need to realize this and come to grips with it. Additionally, this holds as well for the following: beyond a certain skill threshold, a company will not really be any less competitive by failing to hire the best or even second best candidate. If you are a regional telecommunications firm, and hire the 3rd best candidate, the 1st and 2nd candidates will likely get hired in unrelated firms or unrelated regions (especially in the remote work era). And even if this isn’t so, because most everyone is mediocre, the competitiveness of your firm won’t drop appreciably.

[emodendroket]

OK. How does this answer my question, since presumably I would still want to identify at least the mediocrities rather than the complete jokers who have nothing to contribute?

[8note]

Get them all to roll three 6-sided dice, and pick the one with the largest sum