I think the usual solution to that is to follow it up with "what if you wanted to {introduce new/harder requirement}?" and ask them to explain & make as much of the changes as time allows. To give an example, if you were to initially ask someone to implement depth-first traversal recursively, you might follow that up with asking them why you might end up needing to do that iteratively, then you might have them do that iteratively for pre-order depth-first traversal (easier), then follow that up with post-order iterative traversal (harder), then you might ask whether/why it might perform poorly (e.g., re-visited nodes blowing up exponentially), then ask them how they might mitigate it (keeping track of visited nodes), then ask them how they might mitigate the space requirement (lots of possibilities), then ask them how they might handle parallelizing it for some particular problem... I can keep going, but the point is you can keep something like this going until they start to struggle, and that at least tells you the upper limits of their abilities on at least that axis. And you can pace it by e.g. skipping stages as you get a better sense of their skills.
I wish I could downvote this a million times. Do you literally have to do that at work and do you actually talk this kind of wine tasting algorithm bullshit in interviews? This has nothing to do with software engineering as far as building software for a business or any kind of meaningful work. Do you even hire people? This has to be a troll account. I enjoy code golf on a casual slack channel, but you can send me every engineer who fails that question in your interviews and I bet I'd find a few good ones.
That's a strange reaction.. Are you always able to answer any quesion that comes up at work? I know I don't. And so seeing people's reaction to qestion that is too hard for them is a valuable signal.
As long as one tells candidate in advance: "I am going to be asking a mix of questions, some easy some hard. I don't expect you to be able to answer every question", this sounds like a good question.
