Become a better programmer with programming challenges

First, in all programming helps you become a better programmer, just in the same way as playing the piano makes you a better piano player. Even if you already know how to play the piano, you still need to put in the hours to improve (or even to maintain your skills). The more you program, the more parts of the act become total routine that you don't have to pay any attention to.

Of course programming contests or challenges might not be the optimal thing to do to increase your programming skills. But the comparison isn't to programming something else, it's most likely to somebody wasting time by playing a video game, reading blog posts, watching TV, etc. If a contest acts as a extrinsic motivator for somebody to program something, how can that be a bad thing?

In my experience it's incredibly common for someone learning a new language to lose steam quickly due to not having anything to write. We'll always give the advice of just writing some program they need. But amazingly enough many people just don't think of the world like that. To them a well structured problem set is just what's needed. It'll allow them to learn the new language, and learn something else on the side.

But you're also making the assumption that a coding challenge can't teach you anything useful which is blatantly untrue. I learned a lot about writing efficient data structures for a certain class of problems during the Netflix Prize. Likewise for solving some of the harder ITA software puzzles. I'd known the theory of stack smashing attacks on a very vague level, but having to properly figure out how to do (microcorruption) it was a completely different thing, incredibly fun and helpful. Likewise the Matasano crypto challenges -- learning to crack badly applied crypto made me acutely aware of ways in which I've badly applied crypto in the past.

I'll admit that there's probably nothing of practical value to learn from e.g. doing high level Perl Golf.

For example, maybe you get someone who can find the right data structure or algorithm to solve puzzles, but will that same person understand physical limitations of computer hardware and networks? Will they know how operating systems and CPUs work? Stuff like CPU interrupts, processes, memory management are important. The crafting of software is important, being able to design maintainable architecture, understand important design patterns, cache invalidation, testing, different programming paradigms.

At the other end of the spectrum of what I think programming interviews do wrong is test reference knowledge. Stuff you can look up online by Googling. Maybe you can gauge some amount of experience by familiarity of having been exposed to enough of some type of thing to have ended up memorizing a lot of documentation, but I would say not knowing documentation that is easily searchable online is not a good indicator of a bad candidate.

In my experience bad hires have tended to turn out to be bad for reasons orthogonal to programming challenges and reference knowledge:

#1 people with a bad attitude.

This can take several forms: mean to others is the first one. But bad attitude can also mean someone who isn't mean, but someone with a bad work ethic, calls in sick all the time, asks too much of others. Someone who is lazy or unwilling to learn from past mistakes and repeatedly breaks production code. Someone who doesn't actually like to program but does it for the paycheck. Someone who goes off and codes things by themselves without input from others and creates a lot of work for others. Someone who is politically motivated in the workplace and strives to make themselves look better at the expense of others. Someone who is insensitive to women. Someone who is insensitive to diversity. Problems with integrity.

Only twice have I come across an individual who was a good person with a good attitude, worked hard, but wrote shit code. Both of these people had a masters degree in computer science and were excellent at interview challenges. They didn't understand the code base, they wrote things that just didn't work. They wrote just really sloppy, bad logic that you didn't have to look through much to realize it wouldn't work. One guy ended up on a performance improvement plan and then quit under pressure, and the other sort of just fell in as a probably permanent junior programmer who needed supervision, but with help ended up adding value. His life though is one of very basic implementation of other people's designs. I don't know if he ever got better.

My point is, the modern programming interview fails in many ways. Still even I use it. There just isn't enough time in an interview to figure out if a person will be good and enough. I also think 3 or 4 rounds of phone interviews and in person is too stressful and time consuming and anxiety causing for a candidate, and not worth it.

The best hires have always been in network hires. Hiring someone based on someone else you knew. Those kinds of hires didn't even have formal interviews sometimes, you just knew they were good based on reputation. This also has problems, because maybe you just aren't in a network so you can't get hired this way, or maybe you've exhausted the network available to you and your employees when trying to hire.

Anyway, these programming sites are pretty fun. So I like it.

Are they the best way to make use of your spare time, or the best way to improve as a programmer? That's a completely different question, I guess.

Depends on the definition of "better". If fluency and coding speed in a (new) programming language, and knowledge/experience with algorithms and their efficiency are part of that metric, then programming challenges do help becoming a better programmer... or at least: a better coder. No, the challenges do not address the whole required skill set of a good programmer.

BTW, the most important reason that Project Euler is independent of programming languages is that the answer to a PE-problem is a number. It doesn't care or evaluate how you came up with that number. Some problems might be solved with some mathematical formulas, and possibly a piece of paper and a pencil. (Or a smart query towards Wolfram Alpha, for wider definitions on "how to solve a problem".)

Does it support JavaScript?

That's usually the difficult part of any programming effort. Well, the hard part is usually getting a clear and correct set of requirements specifying the problem and constraints, but once that is done...

Refactoring is one of the best way to improve your coding (even on your own code)

There should be a pretty decent range of difficulties for you to test yourself on.