It is just trivia and has little to no bearing on if the candidate can actually do the job (unless the job relates to the runtime of sorting algorithms, of course).
It is just trivia and has little to no bearing on if the candidate can actually do the job (unless the job relates to the runtime of sorting algorithms, of course).
One, I've asked. Not implementing sort, but implementing complex compare() functions for sortable values. There are many things I can accept as flaws in a coworker but inability to deal with 3 conditionals at once isn't one of them. And I've had people (interviewed or worse, worked with) who can't sort by last name, first name, age.
The other is the "I gave you code now tell me what's wrong with it" answer but that's not writing a sort algorithm, that's detecting that someone needs a better one.
Personally, I'd be all too happy if we stop interviewing people expecting answers that would never pass a code review. I'd say it's hypocritical but it's not even that. It's just wrong headed, and gives bad information to the candidate.
There may be better ways to assess that, though. For example, you could ask them to give one or two examples each of algorithms that are O(1), O(log N), O(N), O(N log N), and O(N^2), and O(something worse than N^2).
Generate all permutations of the data. Stop when one of them is in order.
O(n*n!).
And most of them just use a native language sort that does something relatively smart out of the box.
It's good to write all of these at don't point so you understand why things are inefficient.
Traditional technical interviews don't seem to help you find the best candidates (Google famously studied their interview process and decided it was no better than chance).
So maybe don't do a technical interview. Or if you do, just take a couple of real problems from work.
If you're making a lot of hires, do some research and run a RCT.
Go ahead and memorize, it'll be obvious if you can't explain how you got that answer.
The memorizers in this industry often get jobs higher up the tree and therefore they are highly represented in the hiring practices.
Anyways, I completely agree with you. In my opinion it is essential to KNOW that you DON'T KNOW (i.e. you don't remember how exactly an RB tree works, you just know there is such a thing). Everything else is just a quick Google session away.