I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that.

We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of the core parts of our product" with one of our engineers. That's followed by explaining the goals, technology, general approach etc. to another engineer, then a discussion about what would happen next, some of the specific domain problems, that sort of thing. There's no expectation that the project is completed in the time available, and it's more about understanding the process.

This has been pretty effective, and is great for getting a more rounded understanding of the skills of a particular engineer. In my experience, rather softer skills like the ability to clearly articulate the problem, to understand the broader impact on a bigger system, and to be able to identify future issues and challenges are more important than the ability to solve specific technical challenges. Lackluster technical ability is usually pretty immediately obvious when pairing with a developer, in any case.