I encounter people who can make pleasant conversation about programming all day... but literally can’t seem to actually program in practice. Do you see that? How does your interview check for that?

My experience has been that devs who struggle, will struggle with a simple for loop. This seems consistent with what I've heard from an Amazon bar raiser and the existence of fizz buzz. I'd be reluctant to give up this one sanity check of asking in real time a for loop question for whiteboard, or paper, psuedo code prefferably.

At one point for phone screens, I just asked people to code up strcmp. I got some amazingly bad answers.

Some of this code-screen mistrust seems to come from the flood of poorly-qualified candidates; maybe there's a more diverse pool than before, but it comes at the cost of lots of wannabes.

I have not yet run into anyone who could deep-dive into the details of what they're working on and talk about the good, bad, and ugly, who turned out to be incapable of coding. Maybe I've been lucky, but I think it's pretty hard to fake that level of knowledge.

For remote developers I do deviate slightly and I actually ask them to do a little coding, but that's because it's always someone in Hyderabad and the cultural differences make a deep-dive conversation with body language a lot harder to pull off. So I ask them to whip up a demo program that scores a game of Bowling, take as long as necessary, and bring the results to the interview and show me what they did. Not much but it works (and scoring a bowling game is actually not a bad test -- not as trivial as it sounds, but doesn't take a whole evening of work just for an interview).

Great approach! What you describe is pretty close to my understanding of what a good hiring process should be like.

I interview in the same way and have never had a problem with false positives. I think you overestimate the ability of people to bullshit their way through without triggering any red flags for the interviewers.

Honest? Smart? Positive attitude? Fun to work with? Willing to learn new stuff? Learn new stuff on your own because you like coding?

Ok. We're done. Now check references.

We'll follow that up with an audition, show up on a Saturday and pair up with team members for some random hacking, see how you handle working closely with people on a problem.

I actually love the idea of teaming up with some people to do some random hacking. That sounds like a super fun interview! But it also sounds really time-consuming for the team members as well as the candidate, especially if the time goes flat

Skipping over why do you think "likes to code" is important metric when evaluating candidate for a _job_, is it common in your company to interview people on weekends?

A job as a developer is making technology do things people want. It is important to both like people and technology -- and be able to work in both seamlessly.

Whenever people are available we can see how they'd work out. Sometimes it's a Saturday, sometimes a Tuesday. I think you're reading far too much into my comment than was intended.