Ask HN: Does solving math problems make you a good programmer?

It makes you a better programmer. It does not, in itself, make you a great programmer, and probably does not make you as good a programmer as if you'd written lots of code in problems that stretch yourself.

Similarly, if you test for math ability in interviews, you will get better candidates, on average, than if you don't. But you aren't guaranteed a great candidate, and you'll like miss a few people that are qualified but just don't do well with those sort of problems. And it's not as reliable an indicator as having written lots of code in interesting problem domains, but the number of people who are hacker-famous is less than the size of most large companies.

No, it shows that you're good at a particular type of problem-solving, which can be indicative of you being a good "programmer" all-around, as designing and implementing anything "larger" tends to involve the same type of mental processes used when you solve math problems like the ones you mention (at least from what I've seen).

The problems that companies like Facebook put on their websites tend to be at least somewhat difficult - probably because they're dealing with rather non-trivial system design problems, and want to make sure you think in a way that will help them solve them, and don't want to limit themselves to the "I have x and y degrees" crowd.

It doesn't prove you're a good programmer. But there is a correlation: if you take 100 programmers and give them a (non-programming) problem that 50 can solve, the ones who can solve it will on average be better than ther ones who can't.

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.)

math scales programming

compare j=n*(n+1)/2 to for i in range(n+1): j+=i

the former being math and the latter programming for solving summation from 0 to n

I think that most people miss the point of these sorts of questions. I don't ask them just to figure out if the person can answer it or not. a scantron with all the answers filled in would be useless to me. I ask them to watch how the person approaches problems, how they think, how well they communicate and how they interact with people while trying to solve a problem. a person who spits out the answer in 5 seconds, but acts like this question is beneath them is a strong no hire, but someone who struggles a bit, but finds some interesting insights along the way has a good chance.