I hire people based on their ability to learn, not what they know.

If you're asking interview questions that can be googled in 20-30 seconds, you're wasting your time and theirs.

> I don't want my employees to have to learn everything just-in-time

What about just some things. And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.

Except that in my experience, software development is mostly about learning things just-in-time. Most projects pose new challenges, or you want to use new technologies, and so on.

Imagine you hired some Cobol developers some decades ago, and therefore you would still be stuck using Cobol on your projects.

>I don't want my employees to have to learn everything just-in-time.

You can require knowledge without using dealbreakers like "you must know b-trees". A better alternative would be to say "you need to know 30% of the following group of things: b-trees, tcp/ip vs udp, ..." and so on.

This is a popular opinion which still makes hiring an art. The best people I have ever worked with are the people who are fast to learn, have amazing problem solving skills and are socially intelligent. That's it. No knowledge of btree required.

What if they could explain what a b-tree is, and why they are useful, but that they'd have trouble implementing one on the spot. If they told you the name of a good book they know that has an explanation of b-trees. That they read the chapter a while ago, which is why they can generally explain what a b-tree is, and that that's where they'd go if b-trees came up and they needed to write/implement one?

I don't mean to imply that this wouldn't be acceptable to you. I do "know" that I've been screened out after giving an answer like this (to the extent that I can really know the reason, legally they aren't allowed to say).