Is regurgitating an algorithm actually a useful way to interview?
I consider myself a good programmer. I have a PhD and about 10 years professional experience. But right now I can't remember the different sorting algorithms, and in the very unlikely situation that I would need them... well there's Google.
> Is regurgitating an algorithm actually a useful way to interview?
I interview developers. It depends a lot of how you ask the question. Asking "please write a quicksort on the whiteboard" is a pretty bad way of interviewing, you should not expect your candidates to memorize every algorithm invented.
However, if you explain how an algorithm works, and then ask them to write the code for it, you can check if the candidate is able to translate a description to code, which is an essential ability of any programmer.
For example: "In a quicksort, you take a random element of the list (pivot). Then you put all the elements greater than the pivot on the right part, and all the smaller or equal on the left part. Then you repeat the process on each part (left and right) of the list until you can't split anymore." Then based on this description write a simple quicksort in your favorite language, of course you can ask any clarifying questions about how the algorithm works.
I expect a competent programmer to be able to translate the description of the algorithm to code. Yes, it's true that in real world you never have to code a quicksort. But working with simple algorithm makes things easier at the earlier stages of interviewing at large companies, when you usually only have a few minutes to check if the candidate can write some code. Better, more real-world questions are asked at a later stage, when you have more time, typically on a face-to-face interview.
> But working with simple algorithm makes things easier at the earlier stages of interviewing at large companies, when you usually only have a few minutes to check if the candidate can write some code.
Fair point, but it seems like you'd be using the wrong filter ahead of time.
No, it isn't. The problem is that interviewing from the side of the interviewer is an incredibly difficult skill and it's an easy short-cut to thinking you've got a way of separating the wheat from the chaff.
I think the point is that they're simple. Like binary search, which a 7 yr old can grasp. Or writing a simple hash table, at least in psuedo code.
Or shuffling an array - anyone can do it, but there's performance and correctness questions.
In practice I'm guessing so many candidates fail out much earlier. The number of people that can't, say, reverse a string, or words in a string (not even getting into Unicode) is staggering.
Or that know you can do this with the API. One of my questions for developers is to ask for things like date format or string reversal.
If they start writing a function and don't even mention the API, that's a significant red flag. I don't need code written from scratch unless necessary.
I consider myself a good programmer. I have a PhD and about 10 years professional experience. But right now I can't remember the different sorting algorithms, and in the very unlikely situation that I would need them... well there's Google.