This approach screens out people who have the potential to accomplish but haven't yet - I would never try to interview people like this for a development role, since past experience doesn't necessarily tell me if they can do what is needed well.
The point is to get them to talk about something they have spent hundreds of hours thinking about. Something on which they are the experts. They should be able to go into detail and tell you what they found interesting. Both of those things are very informative.
Someone who tells you how they solved a bunch of problems in a language and context that is different from the one you're interviewing them for -- is exactly the kind of person you want to hire.
The problems are always different.
If you can't make that conceptual leap (from how they solved problem in a different context to how they would in your context), I don't think you should be interviewing people, honestly. I'm not meaning to be rude, but this is the problem that HR people and "recruiters" have.
I had an intern once. No coding experience but very eager to learn. That company went under but he's now working full-time as a developer - even transitioned into devops. That's my example of someone who showed great potential but hadn't done it yet. He realized as graduation was approaching that he wanted to do something else and went for it.
Smart people aren't quick to judge largely on the past - they take the baseline that they are looking for, set out to gather evidence for and against it, and assess on whether the criteria is met based on a wholesome picture - the past should be a couple of data points amongst many.
Even with a class project, if someone was interested enough in the class that they can tell you months later "oh, yeah, this project was interesting, we did it with method x because we'd already studied methods y and z and they weren't as well suited for reasons a, b, and c"—even if those reasons were straight from the lectures—then they're already well ahead of most university candidates I've talked to. Most people mostly forget stuff beyond "oh, yeah, we did it this way cause the textbook said to." Similarly for "what else might you do with that?" type questions.
Now, if you haven't taken any classes, and haven't done any software projects for other stuff, yeah, you wouldn't have anything to talk about. But figuring out if someone who's never touched code before is going to be able to do it well is an extremely hard problem -- that person isn't going to make it past any other interview method I've encountered, either.
How would you approach that candidate?
One approach for me would be to find past success in other areas. Prior interests where they started from nothing, went through the grind of learning, and excelled. Sports, music, art, whatever. What did they gain from that and what is their learning process going forward?
I think that's an important characteristic to have. To have pushed through the process of sucking to being great before and the willingness to do it all over again. It's very easy to avoid this in life.
If they are already mid through their programming career and they haven't accomplished anything yet, you might want dig in and find out why.