Do Programming Puzzles Measure Ability?
One of the key skills that any software developer needs is a keenly developed ability to solve problems. I don’t just mean big problems, but little, well-defined problems like finding a specific item in a collection or sorting a collection. In my case, I find myself frequently trying to optimize my morning search for a matching pair of socks, but that’s another post in the making.
A big part of the software design process is to take big, poorly-defined problems and break them up into small, well-defined chunks that can be solved by individual developers or teams like a homework assignment. If that sounds over-simplified, that’s because it is, but for now, we’ll assume that it’s possible to do such a thing. Developing a systematic approach to solving small, well-defined problems is one of the key educational goals of most computer science curricula.
A college-level computer science education is filled with small, homework assignment-style problems (often given as actual homework assignments). There seems to be a belief out there that an ability to solve these small kinds of problems translates into a general problem-solving skill, but I’m not so sure that it does.
There’s a neat website out there called Project Euler that just has lots of challenging mathematics/programming puzzles to be solved. For example, here’s one problem from the site:
The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.
Find the sum of all the primes below two million.
Even a non-programmer can see the path to the solution: Take each number below 2 million and, if it’s prime, add it to a running total, right? This solution is, of course, semantically correct. However, there are several concerns that immediately present themselves. First, will that sum fit into a 32-bit integer? It might if we’re just talking about numbers below 2 million, but what if we want to do numbers below 2 billion? I’m pretty sure we’d have an overflow issue, then. We want to make our code generic, right? So we should take the upper bound as a parameter, and make no assumptions about the size of the result.
Another question is: how long will such an approach take? A naïve primality test is O(√n) for each number (evaluate each number up to the square root of n to see if it divides n evenly), and we have to do this for every odd number less than 2 million (or whatever we set the upper bound as).
This can go on and on for quite awhile. There are doubtless many optimizations that one could make to this algorithm to make it faster (I’m fairly sure the naïve implementation will fail spectacularly). But, the real questions are: do these puzzles make you a better software developer and are they any way to judge programming skills? I hate to come across as a fence-sitter, but I think the answer is both yes and no.
For beginning developers, one of the most important things to do is to look for low-hanging fruit. Solving hard problems can be very satisfying, but, just as you wouldn’t try to learn how to drive car for the first time in the Indy 500, you shouldn’t start out trying to solve problems that are very challenging, even for experienced developers. There are lots of “easy” problems that will teach you quite a bit about programming. For these problems, see pretty much any book about programming or any computer science curriculum.
If you already know how to develop software (whatever that means), then, yes, doing these kinds of puzzles can help keep you sharp and even help you to question assumptions that you hold about the “best” way of solving certain kinds of problems. You can use these puzzles to learn about little-known and undocumented features of your programming language of choice, or you can use them to get up to speed with a new language quickly.
If you have to interview someone to determine if they know how to actually develop software, these puzzles (or the ability to solve them) don’t really tell you anything about someone’s actual programming skill. I’ve heard anecdotal tales of people using Project Euler questions in interviews, and I’d be curious to hear from anyone who’s used them in this way and whether they were good indicators or not. I think you should really ask easy programming questions in interviews, because a lot of candidates probably won’t even be able to solve the easy questions, let alone the hard ones. I also think you should ask questions that are pertinent to your problem domain whenever possible. So, unless you’re writing mathematical or scientific software, asking interview questions about optimized primality tests is probably a bit too academic.
P.S: I apologize for being away from the blog for so long. Things got busy and, well, something had to go on the back burner for awhile. I hope to be back and posting on a regular basis from now on.
November 11th, 2008 at 6:12 am
Hi,
First of all: nice post. Personally I’ve never considered these puzzles (code golf, project euler, etc.) as tools to make me a better programmer. They are in the same league with sudoku, puzzles, etc. for me. They make me think, do some brain workout. It’s primarily fun, and it never hurts to think a bit more, or a bit outside of the daily routine. I guess it’s not just me to state that these ‘artificial’, primarily mathematcial problems don’t really arise in real-world daily coding tasks.
So you start to think, start to look for possible bottlenecks (both algorithmical and language-specific).
Apart from that, they can make you a better programmer, enforcing some stricter, more methodological thinking. They also can help in discovering tweaks and tips of a certain language while you’re rewriting your code for better performance. Most of the easier problems are only about this. A simple solution almost instantly comes to your mind, but it’s usually the slowest one
I have to agree with the point that rookies should not start with such problems. They should do many little “simple” everyday tasks, and after reaching a certain level, they might consider spending some of their free time with such mind games.
November 11th, 2008 at 11:02 am
I think you hit the nail on the head when you were talking about applying questions to the problem domain. I recently ran into some tests from Brainbench and it got me thinking about this topic. It seems like the type of questions being asked helps the interviewee determine if they fit with how a company approaches problems. If they ask specific technical questions or if they ask abstract mathematical problems, you can somewhat tell how the company/team approaches problems. So it seems that not only would they want to see if you got the answer right, but they also want to see how you respond to the type of questions being asked. I almost think the latter is a little more important ‘fit’ wise than the former.
March 3rd, 2009 at 5:58 am
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru
November 21st, 2009 at 3:12 pm
http://healthandcureforyou.blogspot.com/
nice post ,I got the answer for this question.
how long will such an approach take?
Thak you.