That's okay. The important thing is their knowledge of common problem patterns and solution patterns.

Ask them how they identified a complex problem, what process they used to get to its root, what they thought was causing it but actually wasn't, which solutions they discarded and why, etc.

You don't need to have a better understanding of their project than they have. You just need to determine whether they have the ability to solve complex technicals problems in competent ways, and at what level.

For example a more junior person might talk more about solving the problem for today and less about solving the problem for tomorrow. Let them talk it out and see where their attention goes.

A more senior person might talk about similar problems they've seen on other projects and how they leaned on past experience to discard non-optimal solutions faster.

You don't need an algorithms test to determine if someone is likely to be able to "get stuff done" in their role. Talking through past problems and solutions might be a better predictor.

You don't need to know anything about a project to spot that the candidate is being very vague when quizzed about the details of something that they claimed but didn't actually work on.

And it is surprisingly common.