[northisup]

Who is still asking candidates to talk about sorting algorithms?

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).

[hinkley]

There are two situations where I wouldn't harass my coworkers for asking sort related questions.

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.

[why-el]

I see your point, and usually these work best if the interviewer can prove that such a thing is needed. For instance, many jobs might require sorting of data that cannot fit on disk (think for instance of loading a massive file that you want to parse, and sorting might help you in processing it), in which case knowing merge sort (the disk variety) can help. So yes, the onus is on the interviewer I think.

[jaunkst]

I'm less worried about understanding of sorting algorithms than I am about understanding of patterns. With any team at scale my hardest challenge is about patterns. More importantly why a pattern is used. Efficiency of a sorting algorithm can be refactored. Is the implementation of the sorting composable? I'll hire without question someone who understands patterns and composablilty over someone who can site an ideal solution. Seriously at what cost does readability over complexity really mean anything to consumer value. I understand that in very limited scope computational efficiency is imperative but let's be pragmatic and say good programming and understanding of best practices trump perfect solutions.

[adrianmonk]

I think the intention is that the job will relate to the running time of other algorithms and that sorting things is a toy problem you can use to test whether they know anything about that subject in general.

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).

[mjcohen]

Behold, the worstsort:

Generate all permutations of the data. Stop when one of them is in order.

O(n*n!).

[saagarjha]

Sorting is such a foundational problem in computer science that pretty much every job will end up relying on the runtime of sorting algorithms. Not every job requires being able to write a bulletproof dual-partition QuickSort, of course, but knowing complexity bounds is important, even if you’re just calling your standard library’s implementation: it places fundamental bounds on what things you can improve.

[GordonS]

Dev with decades of experience here - I've worked with a variety of languages and platforms, and across different domains. I'm not sure I've ever had to implement a sorting algorithm, or even had sorting as an optimisation issue (and I love micro-optimisation, a bit too much TBH!). I've had to sort things, of course, but standard (or at least "common") libraries invariably have sorting functions built-in.

[CzechTech]

Pretty much every job? I'd say about 10%. With all the web and web-adjacent jobs around, maybe even less. Most stdlibs are already written in a sensible way, so calling "sort" usually means calling quicksort. Most people just do not care, they have tickets and bosses to worry about.

[nkozyra]

Absolutely. While every job will depend on sort, so many of them will have negligible benefit by changing the least efficient algorithm to the most.

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.

[ggggtez]

Disagree. If you think that, what do you ask? "How would you Google or Stack overflow for the answer?" That's hardly going to provide any useful signal. At the end of the day you need to ask something that shows evidence there candidate knows something about efficiency tradeoffs.

[hopscotch]

Sorting algorithm complexity and implementation is rote-learnt at this point. Hardly tells you much.

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.

[ggggtez]

I get the feeling that the people who don't like algorithms interviews are also the people who find them difficult to pass.

Go ahead and memorize, it'll be obvious if you can't explain how you got that answer.

[CzechTech]

Some people like that sort of thing. Mostly the "academic" types. The memorizers. There are people who got through their higher education by using memory instead of wit. I know some of those people, I went to school with some of them, they were always studying and ramming as much "data" into their brains as possible... while I was getting through with minimum of effort by just coding a lot and trying to think about things in my own way.

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.

[mattcaldwell]

This has to be the most misguided attitude that you can have. I don't think this will serve you well in your career.