First thing I noticed is that the links at the top of the page don't work (in IE9). ...so, basically, they are looking for developers who "think in algorithms, dream in code, and eat control structures" so they can fix those pesky main navigation links. :-)
I think there is something poetic going on here. Sometimes we try so hard to hire people like ourselves we fail to hire the people we need most - those that can fill our blind spots. In this case by doing some boring site maintenance work.
Part of this is self-selective in that we communicate well with people that think like us. Perhaps the other side of the coin is that is takes a lot of energy to determine that someone is a good fit unless they think like ourselves.
To be fair, it is likely that the developers who "think in algorithms" and so on work on search, their core product, and it is the marketing team that handles the rest of the Web site. So you may be implicating the wrong set of people.
That said, it was very enlightening to me just how anxious I was! There is really no downside whatsoever to the challenge, and the possibility of a quick $100, yet I was still questioning whether I should do it.
So, I encourage you, do it! Failing is not that bad. :-p
I agree. It was thanks to your comment that I tried the challenge. I didn’t win, but the challenge was totally fair and I feel like I could have won had I been more familiar with algorithms. Even though I failed, I did get a quick refresher on the algorithm in question and learned a new Python standard library function. So next time this kind of opportunity appears, people, try it! (I say next time because I think the Quixey Challenge is about to end.)
Interestingly, I normally consider myself a good debugger, and about 15 seconds after the minute, I figured it out. I think I might have done so in a minute, if I hadn't been under a 1 minute time limit.
Overall, an interesting thing to try.
Note you can't get money if you aren't in the US (I was told), but you can still get a t-shirt and brief fame.
you need a working microphone to do this. i wanted to do this for fun, but i didn't know that they'd be relying on voice communication (i didn't watch the video they have embedded on the blog)
e: also the prize is for US residents only, apparently (since that's where they are trying to recruit, that only makes sense)
It sounds like a clever idea to get people's attention and I imagine that investing $100 to populate a list of potential candidates is much much cheaper than headhunters -
but I have to wonder if it'll be as successful as the greplin challenge and its ilk, which come across as more "game-y" tests and less transactional.
I'm a first year college student, and I relied on my Java experience and the 3 times I've seen Python code to get me through it. Unfortunately, sorting algorithms were the one thing I didn't pay much attention to, so I was clueless. However, I feel that with a little bit of background knowledge, the problem would be relatively easy.
I gave it a shot, not knowing Python but being familiar with Perl and having a strong base in PHP, but I was unable to complete the challenge. I do think this is an interesting way to come up with some qualified candidates, too bad it wasn't in a language I'm more familiar with.
cool...all the better it's in python. i'm not a pythonista or anything, but still think it's a great all around language (esp. for something like this where the focus is on the algorithm, not the code per se).
Interesting - a debugging challenge in a language where every truly difficult to debug problem is hidden behind performance hungry language features. :)
Although I wish I cared enough about Python to know it well enough to have a crack. :P
This challenge has almost nothing to do with Python. If you can't solve the video-featured challenge, it's because you don't know the quicksort algorithm well.
This challenge has almost nothing to do with Python.
That's absolutely not true once you add the time limit.
As someone that never touches Python if I don't have to, I'd immediately get derailed for a few seconds (5?) guessing what arr[1:] means, then waste some time worrying about whether "if not arr" properly handles whatever it is that the awkward looking filter-without-using-the-word-filter clause spits back (does it return an empty list? null? does null evaluate to false in Python? how about an empty list? is the one-line fix to change that to "if arr.empty", or whatever is the Python equivalent?), etc.
That sort of stuff is not tough to figure out (especially if you make the assumption that this isn't just a Python-gotcha test), but it creates enough mental slowdown to someone that's not familiar with the language that it's at least a big factor.
The failure to consider the case where the target value is equal to the pivot is one of the classic blunders of writing a quicksort (along with not considering type limits and getting involved in a land war in Asia). Almost so much so that I immediately thought that I could have made a pretty good guess at the bug if they had told me the algorithm beforehand :-)
You could look at the code and try and figure out what's wrong, or you could have a rough idea of what is likely to be wrong with an implementation of an algorithm and try to see if it's dealt with in the code. They're probably looking for the latter type of problem solving.
Actually the classic blunder of writing a quicksort would be writing a quicksort. It's not something you'd normally do in a real code-base.
Likewise the classic blunder of these puzzle-tests is that they don't select for the skills that you need to fix real bugs. My first stab at debugging a sort-function would be to write a unit-test. Wonder if any of the candidates did that in the 60 seconds that they were given...
> My first stab at debugging a sort-function would be to write a unit-test.
I applaud your discipline, but I can't help but feel like you're punting at writing code when you say things like this.
And the real problem is that unit tests only reflect your expectations. Unless you're familiar with quicksort, you probably won't know what kind of test to write. You'd have to write a very specific dataset: sort(A) ∃ x: A[x] = A[0]. You're probably not using Quickcheck, and the odds of thinking of writing that specific case are slim.
You have to look at the code to get a sense of where the testable edges should be. And in doing so, you should instantly spot this bug. Anyone who can't see it within 60 seconds would be an instant no hire for any but the most junior positions (if I had any say about it, anyways). Even if they don't know Python, they were told there was a bug.
While I'd tend to agree with you in general, I'd still say that unfamiliarity with Python is enough to blow a minute fretting over semantics - that is not a particularly "line-noise"-free version of quicksort, there's still a bit of non-algorithmic crap to parse (and worry about). As I mentioned above, there's a potential false-bug based on the empty filter statement handling, which is reliant on Python knowledge (it's not at all obvious [and IMO, not a great idea] that a language would auto-convert an empty list to false, some don't, and that's exactly the type of bug that does show up in the real world...).
Bump that to a minute and a half for people that don't do Python, or at least give them a clear assurance that they can assume anything requiring specific Python knowledge is not buggy, and I'd say you're right on, though.
I think there is something poetic going on here. Sometimes we try so hard to hire people like ourselves we fail to hire the people we need most - those that can fill our blind spots. In this case by doing some boring site maintenance work.