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.