> I’m looking for them to find the right abstraction
Nothing worse than an interviewer asking a design/coding question and who already "knows" which answer he/she wants.
Nothing worse than an interviewer asking a design/coding question and who already "knows" which answer he/she wants.
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.
Extensibility/maintainability also exist on a spectrum - a less than ideal answer can still be pretty close.
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
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.