

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

My question revolves around the problems that companies like Facebook put on their websites that require programmers to solve puzzles - which are essentially wordy math problems - when submitting an application.<p>Does this prove you are a great programmer if you can solve the problem?  What is the real point?<p>Note: I am a UI designer with a passive interest in real development and I am simply curious what good coders think.
======
nostrademons
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.

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

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

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

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

------
hs
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

