Then a good nano question would be if they know what a debugger is or how they use it. Or any of those very generic questions that any half decent programmer will know, but others won’t.

These questions are made to filter out the pure frauds. People who claim to have 10 years experience but have none. Those who claim to have a CS degree but it’s a fake diploma, etc. They aren’t meant to tell the good developers from the bad.

As said in the article, these questions are risky because they annoy experienced developers. But it’s also a waste of time having a person who never programmed in their life go through a deep interview about api design or architecture.

Sure, though I'd ask more open ended questions about a problem to see where they go with it.

Maybe they land on using something like a debugger or wireshark or strace or whatever makes sense to dig into whatever horrible voodoo is plaguing them. The important thing is that they are creative and experienced at questioning or confirming their priors and eliminating thousands of paper cuts and yak barber shops for themselves, their team, and their organization, so that collectively everyone is enabled to operate at a high-level instead of everyone constantly bushwhacking their way toward eventual failure.

That’s the recruiter’s job, not the interviewing engineer’s. Once a candidate gets time with an engineer, the assumption should be that they are at least kind of good, and not an outright fraud. A good enough fraud might get through this, but a genuinely good engineer might not get through the nano questions.