Slashdot Mirror
The Risks of Entering Programming Contests
snydeq writes "Fatal Exception's Neil McAllister warns developers of the hidden risks of entering programming competitions, which are on the rise since NetFlix awarded $1 million to BellKor's Pragmatic Chaos in 2009. 'Web and software companies offer prizes for a variety of reasons. Chief among them is simply to raise awareness, interest, and participation in a given software platform or service,' McAllister writes. But the practice of offering and entering software prizes is not without concerns. Privacy implications, class-action lawsuits — many of the prizes leave participants vulnerable to prosecution. Worse is the possibility of handing hard work over to a company without reward. 'Contests like the Netflix Prize are sponsored by commercial entities that stand to profit from the innovations produced by the entrants. Those who participate invest valuable time toward winning the prize, but if they fail to meet the deadline (or to produce the leading results) their efforts could go completely unrewarded. Depending on the terms of the contest, however, the sponsor might still be able to make use of the runners-up's innovations — which, of course, would be a whole lot cheaper than hiring developers.'"
But aren't these risks, for the most part, kind of obvious? It's sort of like saying your employer might exploit you for free labor from your unpaid internship. Duh!
There's no -1 for "I don't get it."
That will most likely disqualify you based on the terms of the competition which usually contains clauses about them being able to use your work or some sort of copyright transfer.
what about pre / in interview code samples or probation period coding?
what stop them from firing you right at the end of the probation period and getting free work.
"...prizes leave participants vulnerable to prosecution." I don't see any in the article.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
The GPL does not preclude that, though it would still most likely disqualify you from competition anyway.
"I use a Mac because I'm just better than you are."
I think it's only fair to point out that the terms of the netflix contest (which I participated in and got a lot out of) are such that you own everything you produce. I think you may have to licence it to netflix if you win and take the $million, but if so it is non-exclusive.
Let's not make a big corporate drama over everything. Every programmer that enters a contest knows (or should know) that his work may go unrewarded AND into the hands of the contest arrangement panel. If the programmer has enough free time to make something really great for a contest, then he's already a big name or capable of making lots of money and great projects, so somebody making use of his contest entry should be but a little blip on his radar; if his contest entry was that great then he surely can go big time.
Once, in a Microsoft interview, I was asked to write a memory allocator. I always assumed that after I left, the conversation went like:
"Great, copy this down. Tell the next guy to write us a sound driver."
Each processor would proceed sequentially as if it had been better for them not to rise against Saul.
Obviously if you enter a competition and don't win you spend effort entering for no reward. I wouldn't think it would be possible too drool let alone develop software without knowing that.
That the prize runner benefits from non-winning entries (if the terms and conditions are as such, and you know them before you enter) is also obvious. That's part of the reason for running one, you might award your million dollar prize for the best piece of crap in a field of garbage and would have been better of hiring programmers (ignoring the promotion beneifits of a competition). Or you might get more and better software than you could have got via hiring for the same cost.
Attending a job interview, writing a cover letter, tweaking the CV to highlight relevant experience, etc, those all require effort or time - and yet they don't have to offer me the job (or offer me the pay/benefits I want). Oh noes... there's risk...
You might think that, but let's face it, memory management in Windows hasn't visibly improved in decades*. Any number of interview candidate submissions could have helped, and yet it hasn't.
Their problem is they weren't sure which one was best; so they used them all, and set up a round-robin system to select which manager to use for which process instance.
God invented whiskey so the Irish would not rule the world.
what stop them from firing you right at the end of the probation period and getting free work.
Usually the main problem is that the code in question needs further work. It is very rare that developers are worth the time it takes to train them for the first 6 months. When you audit code written by people on their trial period before offering them a full time post you are usually just ensuring that it does not contain any glaring great screw ups.
The project you give them will usually be very self contained but with a few external things they need to check in order to see how they deal with it. The main reason for this is that at the end of the day you have to audit it so the candidate is fresh in everyone's mind when the final decision is being made. In my experience you will want to give a potential candidate a decision very quickly after his evaluation day. If they were rubbish they probably did not get that far so you do not wan them to get another offer while you make up your mind. If you have given them a project that involved working on more than 5 or 6 files you have to go through every last line that is different and check it before the code is checked in and that can be a right pain in the arse.
Much better is giving them a dummy project that is going nowhere but builds on a simple area of your existing system. This way they have to look a the existing code and plan their approach but you get an easy audit at 5:30 when they leave.
I am also fond of giving them a project they have very little chance of completing in the time allotted in order to see how they cope with pressure. Obviously you do not count the fact they did not finish it against them but seeing how they cope with an unrealistic deadline is far more valuable than the code the produce ever could have been.
The best employee I have ever had the pleasure to work with came to do a trial day on a day which turned out to be a fallback beta release day to a client. Since the program was supposed to have been handed across to the clients test team 2 days earlier but they rushed in some last minute changes we had no choice but to release on that day. We also knew he was good from his interview so we did not want the candidate to get another offer if we mucked him about cancelling with less than a weeks notice. Then our technical lead got sick on the day of the release.
We went ahead and he found several bugs before the clients testing team. He also showed he was very professional and coped with a very stressful day very well even though he was a recent graduate with no experience on a development team. The end result was him getting dragged to the pub immediately after the day and him being accepted as part of the development team by his co-workers long before management had given him a firm offer (which of course they did, and he accepted).
While I would never aim to make a potential employees first day as much of a disaster as that I do think you can give people a basic stress test without letting them know the work they are doing is actually a bit of a dead end that does not matter as much as it could. Unfortunately jobs that pay well are quite often a little stressful at times and it pays to see how people cope with this before you hire them. This can also help the employee since someone who copes well is going to get a better starting offer than someone who can do the job well but looks like they will require more managerial input when they are in post.
I dont read
A desperate for work idiot.