Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Software Your Rights Online

The Risks of Entering Programming Contests 154

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.'"
This discussion has been archived. No new comments can be posted.

The Risks of Entering Programming Contests

Comments Filter:
  • GPL (Score:1, Interesting)

    by Anonymous Coward on Friday August 13, 2010 @02:29PM (#33243730)

    GPL your entry.

  • by nedlohs ( 1335013 ) on Friday August 13, 2010 @03:02PM (#33244218)

    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...

  • by Ash Vince ( 602485 ) on Friday August 13, 2010 @03:17PM (#33244398) Journal

    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.

  • Re:Pardonez-moi (Score:3, Interesting)

    by Fulcrum of Evil ( 560260 ) on Friday August 13, 2010 @03:52PM (#33244890)
    So you're OK with contests used as a substitute for hiring people to work on your projects?
  • Re:Pardonez-moi (Score:3, Interesting)

    by sohp ( 22984 ) <snewton@@@io...com> on Friday August 13, 2010 @04:13PM (#33245198) Homepage

    There a many corporate-sponsored contests like this photography, mostly geared at amateurs. Back in the 80s I learned to look at the terms carefully, and if anywhere in them was a clause giving up rights to the photographs entered to the contest-holder, to run far away. Prestigious contests always make it clear that all rights remain with the photographer, although they may legitimately request a time-limited right to display entries for promotional purposes only, not for resale ever.

    Stock agencies used to use these contests to pick up vast swaths of decent, if unremarkable, photographs for almost nothing, and with no pesky trouble like having to keep track of who took the photo for credit and payment. I imagine now with Flickr and the flood of digital images, they don't really have work even that hard.

    All this remains true for programming contests, and really any contest where the creative work of an individual is made available to another party.

  • by Anonymous Coward on Friday August 13, 2010 @04:59PM (#33245774)

    Sound in Windows hasn't been a problem for at least fifteen years.

    Good, tell me how to change the volume of the Microsoft GS wavetable synth independently of the wave output in Windows 7. It works properly in XP.

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Working...