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.
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.<p>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 <i>can</i> 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).<p>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'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).<p>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.<p>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 <i>make a machine</i> 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.)
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.
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.
math scales programming<p>compare j=n*(n+1)/2 to for i in range(n+1): j+=i<p>the former being math and the latter programming for solving summation from 0 to n