Ooh, that sounds fun.<p>In terms of process design, I think you could take a hint or two from the Netflix guys here. Currently you're distributing a single test case. That takes very little work to accomplish: good first step! Consider creating two test cases: one we'll call the probe case, and one we'll call the real case. The real case is kept on your servers and never gets exposed directly to the participants.<p>Make a really freaking simple way for you to check your work on the probe case automatically, without needing to speak to you guys. For example, you could make a simple REST API or even a web page with an upload/submit button. Then run whatever your evaluation function is against the submitted solution for the probe case, and tell folks how good their submission was. For an extra ten minutes of work you can add a leaderboard. (Add a leaderboard!) You can optionally rate-limit this if you're worried about people overfitting to the probe via taking a lot of measurements.<p>This has a better user experience and will get you more viral exposure because a) you've now totally decoupled your ability to run code from people's ability to participate in the contest and b) people can now get immediate feedback that their participation is valued and producing results. Including a leaderboard also gives folks an emotional hook both for participating and for spreading word of your contest: "Oh cripes guys, the top submission for this problem was done in Ruby. Let's show them the awesome power of functional programming. For the greater glory of Lisp!"<p>Of course, you can feel free on putting whatever restrictions you want on code which you individually invite for offline exposure to the real test case.
Did anyone write a solution? I wrote one for fun (not looking for a job) and am interested in comparing findings. Here's the biggest ring I found (assuming there isn't some huge flaw in my code):<p>114317 117417 116711 104623 55965 61543 117666 111454 106702 109719 59735 98844 79232 99084 56944 42023 116674 113113 106336 106877 114731 107692 106107 116790 116420 98958 111863 87465 102051 59239 36249 61496 108406 93936 117489 102314 114890 40853 43144 112933 61454 93895 99996 107278 100940 106030 98559 28959 36931 8629 65535 61589 113214 108605 100944 99853
Is that job still open? I toyed with the idea of applying, but then my gf was a bit shocked by the idea of moving to the states. Still, it sounds like fun.<p>I started coding the exercise, my first approach would have been a clustering algorithm. For various reasons I decided to write my own (though with a standard algorithm) and didn't have enough spare time to debug it properly. Should have just used an existing package... Anyway, if the job is still open, I might give it another shot.
That's the best job application I've seen in a while and something that I've no doubt interests many of us. I think I'll take a stab at their interview problem just for my own amusement. Shame I won't be moving to California otherwise I'd consider going for the job.
This does sound like a neat problem -- and one which I'll be solving soon in my application.<p>Don't want to give away too much, but looks like a basic statistics text might be a good place to start....
Wouldn't this be a problem that was better solved without software?<p>I mean if its actual people doing the voting, rather than just bots, shouldn't this be handled in a less software-focused way?<p>What I'd say is treat it like police detective work, have someone go undercover, act as if it was like any other human 'crime' syndicate...
James took the simple way out with this one. He just took down all of the voting and commenting features. This drives away all of his users and now he doesn't have to worry about voting rings.<p>That's a bingo!