I never remember the nitty-gritty details of the more complex algorithms and data structures, I only remember they exist and their important properties. If I then have to implement one, I consult google or books. Googling often has the neat side effect that you'll sometimes find refinements/improvements or other (new) potentially better algorithms to solve a particular problem. Or somebody might have done the heavy lifting already and packaged it up under a compatible license (if it isn't something simple like leftPad).

I mean, it's OK to ask for basic algorithms in interviews, to see if the interviewee has at least some understanding of basic stuff and/or can think on their feet and/or can reason about problems appropriately...

But I would still welcome it if instead of giving an interviewee a boring, memorizable problem like "invert a binary tree", the interviewer would find a more general problem and would see how the employee would tackle it, and if the interviewee refers to binary trees as part of the solution without writing out a full implementation from memory that's OK (as long as binary trees would be a valid approach to solve the problem, of course).

> the interviewer would find a more general problem and would see how the employee would tackle it

those are the best interviews imho. specially when both the candidate and the interviewer engage into a productive discussion about the solution the candidate gave.

at the same time, those take time and a lot of companies want a "fast" hiring pipeline, which leads to "invert a binary tree on this whiteboard!".

Just for reference, my company does not ask anyone to implement a binary tree or any well known algorithms in coding interviews.

I see a bunch of comments that look to me as strawman, or really bad interview experience.

A good coding interview should: - not be known by the interviewee if they spent even a few weeks on leetcode - avoid requiring anything that isn’t covered in an average CS101 class - draw its challenges from the need to process a new problem, and gradually uncover the edge cases in it and how to handle them gracefully.

I don’t do leetcode. But went now and tried the first hard question I found. It was “find the median of two sorted arrays”. I find this question to be a good example of very little background knowledge needed. (You’d need to know how to deal with arrays, and what’s a median - not everyone will know these, but it’s a pretty low bar)

This question already has plenty of room for mistakes, edge cases and problem solving. I’m going to take a wild guess from knowing talented veteran engineers I’ve seen that they can surely handle it in the interview structures I’ve experienced.

I don't think the problem is senior folks believing answering questions about bubble sort beneath them (I'm sure some do but I doubt it's the norm), I think the problem is that 99.99% of developers at all levels don't need to know how bubble sort works to do their jobs well.

Guido is not a senior engineer.. he's a "special projects" person. Fewer than 50 such persons would exist in the microsoft stable. Why would you have someone who functions at such a high level bother with low level implementation? There's thousands of shit munching nerds who can implement flawlessly but who need the overarching guidance to deliver product.

Because most really good designers also did low level implementation? Thompson, Ritchie, Leroy, Torvalds. Heck, while I don't know for sure, probably Dave Cutler did, too.

I don't know any product that's pleasant to use that was developed in the way you describe. Python certainly wasn't.

Many threads, SIMD, cache hierarchies, and calculations often being "free" due to general memory pressure means the classic version of any algorithm is pretty much guaranteed to be bad at it's job while a seemingly worse algorithm might actually perform better. You likely won't learn any of that from your algorithms book.

If you tried to implement those algorithms on my team without a very good reason, there would definitely be some serious conversations that followed.

In any case, vomiting algorithms on command doesn't seem to correlate strongly to programming ability. Almost all programming problems have a lot more to do with handling much higher-level complexity issues. The knowledge and art of knowing how to poke some undocumented third-party API to implement our system is much more practical. Knowing how to think at a high level is much more practical. Leave algorithm questions for research positions in that area.

One thing I have always hated about HN, is that they grey out downvoted comments. That has to be the absolute worst UI decision possible. At least at other sites, when you manually expand a downvoted comment, it's actually readable. Here the contrast is purposely so low, I'll never know what you wrote.

It’s not a question of status, but rather the utility of memorizing algorithms as an indicator of success. Notably, it’s probably not because Google exists and anyway the majority of one’s time isn’t finding the optimal algorithm.