[ordinaryperson]

This would be a good method if your goal is to hire a carbon copy of yourself.

First, your definition of "interesting problem" probably includes a lot of personal biases. What you find interesting probably touches stuff you've had experience with, but just because you've done work on say, customized implementations of binary search, doesn't mean it's a good baseline for all developers everywhere. Maybe they've worked on different domains or solved different problems and can't relate to questions you personally find "interesting".

It'd be much fairer to select a boring question that involves standard stuff that everyone has to face at some point in their careers, like string manipulation. And even then, it just involve normal transformations ('look for and remove special characters') and not wacky, HackerRank-style rules ('no two bs after cs but before as').

[munchbunny]

I mostly agree with this approach. I think that you absolutely should be measuring the "boring stuff" because that's 90% of the work by number of hours spent.

On the other hand, I think there needs to be some proxy for "how well does the interviewee navigate complexity?" Because a programmer who does it well is far more valuable than a programmer who doesn't, and there's high variance on this between programmers and between fields of expertise.

The systems design interview sort of gets at it, and whiteboard interviewing often tries to get at it. I feel like I've yet to settle on an approach I'm happy with.