Generally you end up doing a review of relevant literature and a few days/weeks/months of research and development. I'm not sure answering a question under pressure that has just been asked is that relevant to making ground in new areas of research.
The point is that solving problems, either by inventing new computer science, or more likely formulating a hybrid of known algorithms requires some semblance of problem solving.
A genuine interviewer (and I realize several/many may not be genuine) is solely trying to figure out if the candidate has these types of reasoning skills.
Let me phrase it this way: By asking a common CS question, you'll get people who simply memorize answers/algorithms. By asking something obscure that is rarely known, you can try to get a glimpse into someone's thought process, which is infinitely more valuable than rote memorization.
Right but there are lots of ways to test problem solving skills that don't involve asking people to both solve a surprise (and obscure) problem and come up with code at the same time whilst under stress. The latter three things are probably clouding your results in a way it's not really possible to account for. It seems like a lot of people setting interviews lack a bit of empathy.
The grandparent seems like the problem solving equivalent of yelling "think fast" whilst tossing a basketball at someone's face to test reflexes.
Okay, give us a generalized example? everyone who (appears) to care about being empathetic while at the same testing for these skills is continually asking for better options.
If you're hiring a point guard, isn't testing their reflexes by tossing them a basketball a reasonable approach?
Ask a simple, standard question that the candidate could reasonably answer in 10 or so minutes, confirm it works with them, and then change the parameters to invalidate their solution?
This is the closest I can get to actual project work in 45 minutes.
The second the interviewer changed the parameters people would start complaining that they were "Setup to fail." These threads commonly illuminate that interviewers simply cannot win, regardless of how genuine they are.
That's why I recommend confirming that the candidate's first solution was right. Use lots of positive feedback: ok, looks good, that's right, that's how I would do it; I see where you're going with this; etc. Then introduce the change, with a justification e.g. the team providing the input data changed their format/guarantees/technology, and we have to blah blah blah.
Why bother? You still fail to detect candidates who memorized the answer.
My standard coding question is a funny-looking prime sieve. If someone isn't familiar with one, we can work it through together and I'll have a much better idea of their learning potential & what they'll be like to work with than the intern straight out of their Algorithms final.
Personally, I don't bother. I went the route of requesting candidates go through a work sample project that I spent a considerable amount of time trying to standardize across all the languages relevant to the role. In the end though, management wasn't for me, and so I ended changing roles for something non-managerial
