I've interviewed loads of people over the years in different ways. I'd say the real dud hires were not that different from other hires. The duds were people who for one reason or other did not want to do what was assigned, yet took some time to say so. Personal issues for sure.

When hiring what works for me is looking at past experience. If someone says they are a cpp performance guy, that creates an expectation of what they should be able to chat about. If you're making it up, you will run out of stuff to say, and I'm patient enough to let people keep talking. Hopefully I'll learn something too, it happens often with top pros. But basically if you're experienced in a field it should be hard to come up with anything where you draw a total blank. If that's the case you're pretty good in my book, the main differentiator after that is whether you've done exactly what the firm needs or just something similar.

With entry level people it's hard. That's why they typically make less money, it's an Akerlof lemon cut due to the being a lot of people who just aren't going to be good at it. This isn't even necessarily a coding thing, but general life maturity. We had a guy who couldn't wake up on time to get to work, and he couldn't phone in when he was late either. I reckon there's no way to know about this kind of attitude problem until you hire them. This is also why you can expect a relatively high jump in pay after your first few years, it's proven that you aren't one of the lemons. The distribution is a large mass of hard to differentiate professionals, plus some duds of near zero value.

So for entry level, your best bet is simply finding someone you think is smart. You'll end up falling back to the same thing as everyone else who is hiring: the prestige of the uni they went to, and some pot luck questions to make sure they picked up something. However that's really not enough to know what you want to know, which is whether they are able and willing to learn what you need.