This 100%. There's a big difference between looking for maintainable and extendable code and the "right" solution. To me, that almost no one passes is a red flag - if you are screening resumes right and framing the question right, the pass rate should be at least 25% IMO.
Extensibility/maintainability also exist on a spectrum - a less than ideal answer can still be pretty close.
I’m fine with less than idea answers. The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all. Or they only abstract one small part, or a part that makes no sense to abstract. They gravite to one big function that does everything. Our codebase has a lot of big functions that do everything. The only time people try to break things up is to make it DRY. Any time we need to change things, it breaks something else entirely unrelated.
> The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all.
Have you ever heard of Premature Abstraction[0][0a]?
> Our codebase has a lot of big functions that do everything. The only time people try to break things up is to make it DRY.
That's the whole point of DRY, though[1]. If you abstract with less than three instances of it, you will end up with abstractions that typically misfit the solution, requiring refactoring or outright disposal of the abstraction in the future (Or worse). Also, you waste time developing (what in all likelyhood are bad or leaky) abstractions when you could be devoting time to something more important.
> Any time we need to change things, it breaks something else entirely unrelated.
That's unrelated to abstraction.
There, I said it.
Leaky or badly fitting interfaces are not solved by abstracting more, they're solved by compartmentalizing more (There's a subtle difference here). This can be done with abstraction, but doesn't need to be. Typically refactoring the data structures, shuffling state around, or redesigning the interfaces to better fit the problem, is a better solution.
I feel like this really depends on how the question is asked, how the interviewee is guided through the question, and the interviewer's expectations. If I was the interviewer, this would basically be a fizzbuzz question. The reason is that I'm pretty sure I'd have to basically tell the interviewee that I want a higher order function that takes in a predicate function.
If the question is simply phrased, "Group the values by odds and evens ...; and please create an appropriate abstraction" without any more details, it would explain your results. I wouldn't be able to hold it against the interviewee that they couldn't reach the proper abstraction without more context.
If I wanted to gauge an interviewee's ability with abstraction and code organization, my preference would probably be to engage in a higher level discussion, because it's difficult to construct a code test that tests this well.
Based on the question you posted I'm honestly surprised, that one seems really straightforward. If you write it in a functional language it's basically impossible to mess up the design if you "make it work" only.
I guess that could be said for any question. Have them be easy enough that at least 40% give something close to the desired answer, and then use 10 of those questions.
Extensibility/maintainability also exist on a spectrum - a less than ideal answer can still be pretty close.