I'm not going to be handing out degrees based on these. If you mean the utility of the specific questions, the point is that knowing these things is indicative of your general level of knowledge in certain areas.

>knowing these things is indicative of your general level of knowledge in certain areas.

Very possibly. But is knowing the same as remembering? Compare remembering the specific value of quicksort's worst case to knowing that some sort algorithms are better than others when, say, the input is likely to already be sorted, and that you should go crack open CLRS if you dont recall which.

If you can't remember quicksort's average vs. worst cases, odds are that the behaviour of sorting algorithms isn't sufficiently top-of-mind that you'll say "wait, this data might already be sorted! I might need to use a different algorithm here".

Quicksort is usually randomized. So it is not a matter of the order of the elements, it is a matter of very bad luck on selecting your pivots. So even if worst case performance is very bad it is very unlikely. But you have to understand why.

You probably will never implement quicksort, but it is useful to know, how it works, as you may be able to use some of the ideas on your own algorithms. Quicksort is also beautiful, so it can be a good inspiration on writing good software.

> I wonder about the utility of an exam that one can ace with five minutes of googling.

I won't debate the utility of the exam, but the majority of the tests I have taken can be aced with five minutes of googling.

Likewise for myself. Though I suspect that it's because testing for memory is easier than testing for knowledge, especially when one can simply assume that the former accomplishes the latter.

Because any professional worth of its salt is supposed to be able to work with googling.

But the author specifically asked people not to "cheat".

Typo. I meant to say "without"

I use these kind of questions in interviews. You either know the answers or you don't. There's no looking at your 'phone in an interview (at least not one with me being the interviewer).

Why is the software development interview so radically different from the kinds of conditions a developer actually works under? I mean, I can't imagine someone on the job struggling with code, but only being able to look at a printout of it rather than in an ide/debugger, unable to look at a book, the internet, or ask someone for advice, and having a strict 30 minute or so time limit to figure out their problem.

Fair enough. I take a different approach in my interviews: try to gauge how useful the person will be to the team. We have internet access, and a library with CLRS if someone needs to implement a bipartite graph test. It matters more to me that they'd know why they'd need one.

We use those kinds of approaches too. I never said the interview consists solely of closed book tests, they're just one thing I find useful to help gauge the suitability of an interviewee.

[EDIT] The thing I'm most looking out for is how a candidate answers when they don't know the right answer.