Comment by the_af

I only partially agree with the article. As an introvert myself, I stress a lot during interviews (whether they involve coding or not).

The reality is that some sort of interview must be conducted, and it's impractical (and simply unfeasible for some companies) to just hire and then fire during the probation period. It's also wasteful and unfair for the team where the candidate is supposed to work. Interviewing is an exhausting process for the interviewers as well, not just for the interviewee.

Live coding is a good, if flawed, step in the interview process.

Here's how I do it when I'm the one conducting the interview:

- I approach the interview from the mindset that I want the candidate to succeed. Not only it's more fair to the candidate, we're also not Google or Meta that we get so many candidates that we need to weed them.

- I take into consideration their stress levels, because I'm a shy person myself. I never discount points for a candidate that freezes for a moment, or requires help to get out of momentary panic, as long as they eventually solve the challenge.

- I ease them as much as I can, explain the coding exercise has no tricks or "aha!" moments, and that they are free to ask as many questions as they want, and also google anything they don't remember. I just ask them NOT to use AI assistance, and explain that it's just an artificial requirement because I want to listen to them think, not blindly use AI. I also trust them not to use AI, I don't double-check; I explain I simply trust them to be honorable.

- I help them whenever I see them stuck. If I see them going down what I think is the wrong road, I wait in case I'm mistaken, but when they get stuck I gently prod them in the right direction.

- Live coding is not the moment for "thinking outside the box"; I hate that kind of FAANG challenges. We never ask one of the "Cracking The Coding Interview" style of questions. The exercise itself can be solved with basic Python, similar to the example in TFA. If you know dicts, lists, for-comprehensions, etc, you can solve it.

Aaaand... about 50% of candidates fail it, spectacularly. Like, they cannot get basic syntax right (and remember I'm helping them along the way, e.g. "this is how you access a key in a python dict"). Some are supposed seniors, some are juniors. There are people who struggle but get it right eventually with some help (I consider they passed the challenge), but others struggle and simply cannot make any progress even with a lot of help. The seniority level is no predictor.

Maybe for these candidates that really don't go anywhere, there could be a better interview format that is not live coding. Sure. But the interview process cannot accommodate every person, it simply won't scale. Designing interviews is difficult, too. So unfortunately, these people will fail the interview. It doesn't mean they cannot be good professionals, it simply means given the time and effort we can devote to interviewing, they will fail our process.

Some people do badly with take-home challenges. Some people do badly in other kinds of interviews. No process can accommodate everyone, and it's a balancing act which must also take into consideration that designing good interviews is hard.