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.
