I agree with several already-existing comments that programming challenges do not help you become a better programmer (assuming that you're hireable in the first place).
I will note, however, that they DO HELP with interviewing. The skillset is quite overlapping... artificial time-pressure, artificially contrived problems, cleverness is rewarded, etc. (But it's not entirely the same, because programming contests don't give points for half-working answers).
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.
"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."
I think it's a good comparison. Programming contest would be a very specific part of piano playing, like playing scales super fast. It's useful, but still a very small part of what it takes to making music.
I agree that doing these challenges helps you play the scales super fast. But I think the important segue to acknowledge is that the fastest pianists don't necessarily make the "best" pianists in terms of the quality of the compositions they're able to churn out. I'm saying that being a super fast pianist is not a necessary and not a sufficient condition to become a great pianist. Does it help? Sure it does! It helps to move up and down the scales and play rachmaninov for the evening's entertainment effortlessly, but at the end, it becomes one of many ingredients required to actually "make" good music.
The question is, is there a really good balance that we could engage in? What part of lives are best spent practicing heavily (and perhaps "composing" lesser music) and what's the best indicator to transition into a part where you're not practicing as heavily, but you're composing more music.
Or for those more fond of sport analogies, practicing 3-pointers over and over again. It's a very small part of the whole game and you need to excel at all the other skills required to be a great player. But I disagree with the blanket statement of OP that it doesn't make you a better player.
What I generally don't like in these kind of puzzles is that the task itself is given with some specific method or algorithm in mind (but you're not being told). i.e. to efficiently solve some particular task you have to use K-D tree; Some specific graph algorithm for another task; Another specific DP method and so on...
Well, I'd make the statement that almost any kind of programming (unless incredibly repetitive or filled with bad practices) will make you a better programmer. At the very least, it should make that person a little bit more practiced in their language of choice. These types of challenges may also take you out of your comfort zone, introduce you to new languages / paradigms, and so on; these are all good things in general.
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.
> programming challenges do not help you become a better programmer
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".)
Rosalind also supports every programming language (for much the same reason that Euler does -- you run the code on the provided sample data and give back the result.)
Interestingly enough I did about 50 problems of PE in Javascript (no libraries except my own custom written helper functions) to see how far I could get. Output was simply writing to the browser.
I agree, these coding challenges only ever really come up in interviews and interviewers will grade you accordingly on whether you can solve them. The truth of the matter is, these challenges are your resume, not the experience you have.
It's actually kind of an interesting thought to consider. If programming challenges aren't good at helping you become a better programmer are they good for determining if you're a good programmer? These kinds of sites pop up because of how the engineering interview is conducted. I presume that the more engineers study to become better at these challenges the less effective these challenges will be at finding good engineers.
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.
Those programming challenges are certainly interesting and they make a great learning tool but they use a very specific set of skills. Usually, the difficult part is to find an algorithm that solves the problem within the given constraints. Implementation is comparatively straightforward.
To me, they are more "problem solving contests" than programming contests. The code is just there to validate the solution.
I've found that in many environments, particularly on the web, it's much harder to make sure you've accounted for all the quirks and interactions with related systems than it is to find the right basic algorithm. There have been few times I've really thought something like "If only I'd known about A*!", but comparatively many times I've thought something like, "If only I'd thought to test two-finger swiping on a touch device with both fingers inside the element created by that javascript."
EDIT: Also, maybe more importantly, I never feel more tempted to give up than when I know I've solved the basic problem but some environmental factor prevents the solution from being usable. The fun part is over, and if I want to make progress I have to dive into docs and other people's source code, and write good tests. I think there's more difference between someone who gives up at that stage and someone who doesn't than there is between someone who knows a particular algorithm and someone who doesn't.
Depends on task. I found out that when dealing with large systems, it is not an algorithm that is the biggest problem. The gist is usually to find out and keep in head how various parts interact and what exactly they do. The hardest and most important is to figure out how to make each change in such a way that above will be as simple as possible (eg. keep the system clean and maintainable without hacks and dirty tricks).
Both parts (figuring and writing) are figuring out, but both are entirely different from programming challenges. First requires you to be able to decipher someone elses code reliably and fast. Second requires you to figure out how to do things as little fragile as possible.
Algorithms are more about solving isolated more math-like problems. Once you got solution, you do not need to consider anything then making it work, so it is different kind of code. Even if you would plug in it into some large system, it is would be isolated so you can actually afford to be more dirty.
> Usually, the difficult part is to find an algorithm that solves the problem within the given constraints. Implementation is comparatively straightforward.
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...
I actually run through the first few Project Euler https://projecteuler.net/ problems whenever I am looking to play with a new language. It was really eye opening comparing my answers in Haskell to my answers in the procedural languages.
And that's the winner in my book - this is not about doing a test or challenge once, and passing some "exam". Its about stretching me and discovering more about the strengths and weaknesses of certain languages and environments - I should do more little practises like this, but in different ways.
Same here. For that goal, PE is a fun and efficient playground. The forum discussions (only accessible after submitting the correct answer - always a number) are also a great way to see how the problem can be solved in other languages and programming paradigms. APL definately scores points in Code Golf :-)
I also like them to keep myself familiar with languages I'm not currently using for real work. I find that syntax slips out of my head very quickly, but that even writing fizzbuzz keeps it from falling away.
I did that with Clojure and it was great. Possibly an unfair metric because it felt as if many of the questions were purposefully built for a functional language.
Interesting, I've been enjoying https://www.codeeval.com/ which also has the headhunter based model and supports a few more languages, but doesn't have the time limits like a real code interview usually would.
I've really been enjoying codewars.com because you get to see the solutions of others after you pass all tests. I've learned a lot of little javascript tricks this way.
Yes, with these challenges you might just become a better computer scientist.
To become a better programmer you need to build large complex systems to practise the current messaging queues libraries, data processing frameworks, scalability issues, building clusters, etc...
I disagree. A real project will teach you a set of problems that are useful at most day jobs but these coding challenges will help you learn a class of skills and techniques that are very hard to learn/figure out on your own. These are much more centered around Computer Science problems than typical software craftsmanship problems. You need both (CS and software craftsmanship based skills) if you want to a complete well rounded Engineer.
I have 11 years in the industry in various jobs. I was very good in the algorithms and data structures part of my course when I studied it, but the frequency that I actually get to use any of that stuff is maybe a couple of weeks per year.
I would say that learning libraries and how to use them will be far more use, as most common problems have been solved, implemented, put in a library and tested for you. A good programmer will use that library rather than reinvent the wheel.
The submission deadline for the 2014 contest is today, but otherwise Hello World Open (https://helloworldopen.com/) would have been an interesting programming challenge to participate in.
Positioned as a sort-of World Championship for programmers, it is a virtual slot car race. The challenge is to create an AI and drive a slot race car on a track against other racing bots. Very entertaining... Finals will be played on June 10th in Helsinki, Finland.
For beginners, easy programming challenges are very practical, since they let them practice getting their loops and conditions right.
Afterwards, programming challenges become a little less practical since they are more challenging than practical programming. However, I think one can still make challenges that are practical, and I'm thinking of doing this on my site http://www.learneroo.com.
Hey, sorry for the self-plug, but try http://pgexercises.com/ . It lets you try SQL exercises in the browser and offers decent explanations to go with it. It's focused on PostgreSQL but the large majority is standard SQL.
There should be a pretty decent range of difficulties for you to test yourself on.
I can also recommend http://codeforces.com/. They hold regular contests where you can compete against others and then see how you improve over time. It is popular in Russia and sponsored by VK.
I feel like I've found the problems thrown up by trying to build open-source (and commercial ones where I have a lot of autonomy to change things) projects to be more informative and useful.
There is checkio.org for Pythonistas. As I know, there is no language choice for now but there will be on the future.It motivates coders with gamification and also level of problems.
I will note, however, that they DO HELP with interviewing. The skillset is quite overlapping... artificial time-pressure, artificially contrived problems, cleverness is rewarded, etc. (But it's not entirely the same, because programming contests don't give points for half-working answers).
Also, IMO the best coding contest site is http://code.google.com/codejam/, because:
1) GCJ has unusually clear problem statements. UVa in particular is terrible for this.
2) GCJ supports EVERY programming language (unlike all others I know of except Project Euler)