The original story here wasn't about code written in an interview, but code written on the job by someone who wouldn't have been hired if they'd had to write code in the interview.

But, 45 minutes for mergesort? I mean, it's not fizzbuzz, but this took me seven minutes, and it passed the test on the first run (well, not counting the test runs that verified the test was invoking an empty function and correctly reporting that None wasn't the correctly sorted list). Does it have some kind of subtle bug I'm missing?

    def mergesort(items):
        return (items if len(items) < 2 else
                list(merge(mergesort(items[:len(items)//2]),
                           mergesort(items[len(items)//2:]))))

    def merge(sa, sb):
        ia = ib = 0
        while ia < len(sa) or ib < len(sb):
            if ib == len(sb) or ia < len(sa) and sa[ia] <= sb[ib]:
                yield sa[ia]
                ia += 1
            else:
                yield sb[ib]
                ib += 1

    def ok(a, b):
        assert a == b, (a, b)

    ok(mergesort([3, 5, 3, 1, 10, 11, 12, 0, 1]),
                 [0, 1, 1, 3, 3, 5, 10, 11, 12])

If I were doing it on a whiteboard I'd probably want to use something like http://canonical.org/~kragen/sw/dev3/paperalgo rather than Python, but I can't imagine it would take 45 minutes. Do you mean in assembly language or something? In minimal space (none of the logarithmic number of copies required by this version)?

I agree that these are not very basic coding skills, but they are kind of basic coding skills, I think? Like, it's covered in the first part of an undergraduate CS curriculum, isn't it?

Super late responding, but I enjoyed your comment and code.

Unfortunately... yes to both your questions. Yes, it is certainly covered in basic undergraduate "Data Structures and Algorithms."

And yes, I would have trouble writing what you just wrote in 45 minutes at a whiteboard, unless I studied up in advance. I know the algorithm in the back of my mind, and I'd be able to hack away at it. I don't mean in assembly, or in minimal space, I just mean a reasonably efficient implementation of quick sort in a high level language like python ruby or java. Again, I could do this with a bit of study, though I'm no longer inclined to do that study. I can't think of a reason, other than interview exams, for me to front load "into to data structures" into short term memory for a midterm exam one. more. time.

Maybe it does say something about my skill and mind set as a developer, that it would take much longer for me to do this than it would for you. I'm ok with that, as long as we're clear on what "basic" coding means.

I maintain that it is an immensely different thing to say you're weeding out people who don't have basic coding skills when the test is "fizzbuzz" vs "implement merge sort".

Well, I tend to spend a lot of my spare time noodling on what I think of as fundamental CS problems (what's the optimum radix for a min-heap? 3, I think, not 2), and I've spent a fair amount of time programming in languages like C where implementing mergesort from scratch is actually a practical thing to do. And I have a prejudice in favor of knowledge with a significant shelf life, like how mergesort works, rather than, say, how to work around the bugs in the latest version of React, which is also practically necessary for getting stuff done. So I might have a bias in favor of that kind of thing.

I certainly agree that mergesort is a lot harder than fizzbuzz, more than an order of magnitude. Fizzbuzz is well under a minute.

I'm pleased that you enjoyed my comment and code! I was reluctant to make it because I feared you might interpret it as an attack.

That's all true, but it's not really relevant to what I was saying. We don't do whiteboard interviews; that was some code I found during a code review. My original comment was in response to the assertion "my resume speaks for itself", and was simply meant to serve as a counter example. A lot of people seem to have interpreted it as "interviews should involve complex whiteboard programming" and/or "you should always use redux for your back office CRUD apps".