It's not realistic in my opinion for interviewers to throw complex problems at people and expect to draw useful conclusions. For one thing, truly challenging problems are generally solved in teams. And there are plenty of differences between pure math and how computers do it (think of an entire course on numerical analysis).
Interviewers should find out how well candidates might work in teams, how familiar they are with debugging on a computer, and how likely it is their "cleverness" won't result in a steaming pile of unmaintainable code. There are lots of reasons why someone may make it or not make it through a puzzle, and either way they may be an excellent candidate.
What should occur is a reasonable bridge between abstract problem-solving and programming, to see if the candidate's aptitudes are strong where it counts. For example, numerical analysis is great: you could ask someone how they would make a machine perform a certain calculation expressed in "pure" math. (Does everyone know how to factor equations to minimize expensive instructions? Do all candidates realize the inherent quirks in things like the representation of floating-point numbers? This is the kind of stuff that comes up when math meets computers.)