> So you want to parse a PDF?

Absolutely not. For the reasons in the article.

You are making two assumptions that are generally not true

* In the US * Interviewee is currently unemployed

Even then, the general candidate we interview for Tech positions can usually survive quite well on a couple months.

Like I said, this is literally a thing I do all the time. I have standing 1 hour blocks for each of my team members every week and it's not uncommon for us to build out the skeleton of a problem solution together. I literally did what you said on Wednesday for someone for a gitlab change because I don't expect they know how secret injection works, but I want them to know. And absolutely I've encouraged them to ask questions, and I ask them questions to check their understanding.

Being below average is not disability.

You want to hire someone good. You try to find many ways to weed all others out so that what is left is good.

> we have to replace them with something that works

We don't. The simple solution is to stop maintaining the illusion that 100% perfect hire is possible.

Design your post-hire process around imperfect hiring rate / quick feedback loop, and accept the losses (they will happen anyway despite any perfectionistic illusions you choose to maintain).

These are few questions that really matter:

   - Is there a track record of delivering meaningful results?
   - Does their past experience seem credible?
   - Are their soft skills and communication skills up to your expectations?
   - Do they demonstrate adequate hard skills for the role?
   - What interests and motivates them on professional and personal level?

Your interview process will always be just an attempt at answering these somewhat accurately, with diminishing returns after a certain point. Getting actual accurate answer to these is only possible through collaborative work in real environment.

It's not artificial: the company has a day of my time. I have a day of their time. We both want me to meet several people on the team to see if it's a good fit. Because of the constraint, we keep it to relatively simple discussions around toy problems that can be solved in an hour.

A good employer takes care of their worker even if they have problems, but they also want to weed out as much of them before hiring.

Mentally strong and healthy people who do well when challenged are good hires.

I've started to treat live coding screening sessions as a "conversation about code." I make sure that the candidate knows that I'm trying to make sure we can discuss code.

Why?

Purely being a "good programmer" isn't just enough for the job. It's important that we can develop a good working rapport, and communicate.

For example: Someone who's an expert programmer might misinterpret a discussion and build the wrong thing; or someone might be a great programmer but otherwise be impossible to actually conduct a technical discussion.

IE, this is why "Fizzbuz"-style questions work so well: It's not really screening that you're a great programmer, it's screening your ability to have a technical discussion.

I sit down with juniors and sketch out designs or code for them while talking through the thought process at least once a week, and even when solo coding, I expect everyone produces work that explains itself. For particularly complex/nuanced changes, people do hop on a call to talk through it.

Like I said the deadlines work for both sides. If a company wants to give homework instead of having their own senior engineers spend time talking to me, that tells me what I need to know about how they value my time.

The short deadlines are because neither the company nor the candidate wants to spend a month on an extended interview. Solving a problem and walking through the thought process are because that's what "coding" is.