Also, I'd give better than even odds that GP's "right" answer is a pet solution of theirs that other people of similar background and skill level would contest.

I don't disagree with the practice of giving simple questions with solution spaces well understood by the interviewer. I use it myself. However, I force myself to accept any answer that correctly identifies tradeoffs as correct and I have to intentionally suppress my inclination towards a specific set of weights on those tradeoffs in order to be fair. This doesn't seem to be nearly as common as it ought to be.

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.

[0]: http://wiki.c2.com/?PrematureAbstraction

[0a]: http://wiki.c2.com/?TooMuchAbstraction

[1]: http://wiki.c2.com/?ThreeStrikesAndYouRefactor

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.

My closing interview question for application programmers is about how to scale database. The answer is completely open, just to see how deep the person went in his career. The hidden part of it, is that I want to get some insight for myself.