I think mini projects + code review is the way to go for smaller places. Make the projects large enough that an AI couldn't generate correct code right off the bat and then in a follow up conversation dig into the code and ask for their reasoning to make sure they understand the code they wrote so you know that they either wrote it or fully understand it to the point where it doesn't matter if an AI write it and they tweaked it.

To be honest, as a CTO (not currently hiring though) I want people that can use AI to speed up their coding but who know how to use it well. If anything I suspect those devs are better than devs who don't use AI as they are practicing using their code reading abilities more often and filtering away any bad code written for them.

I use AI to generate code sometimes but it often doesn’t work as expected. Other times I get just awfully inefficient answer. Someone who has programmed without AI for a few years will spot those things. Someone who doesn’t have any “gut feeling” formed about code and just relies strictly on AI will do awful.

I think your approach is good, I would introduce things that work but are terrible design decisions and have the person interviewing figure out what could be improved.

Would you allow employees to subcontract and outsource their work?

Just to add to my previous comment. We use AI heavily today, and we're seeing a 25%+ productivity improvement. And our Devs are happier, as they get to focus on high order problems.

> Would you allow employees to subcontract and outsource their work?

No, but I do encourage them to use the best tools possible. :-)

"Sir, there is this approach where I feed in requirements and get back results, can I use it?"

You can't fix the stupid ones no matter what hiring strategy you use.