Source: https://techbeacon.com/developer-shortage-or-time-rethink-technical-interview

So what CS stuff should you study and memorise before a technical interview at a major tech company?

Hash tables
Linked lists
Binary search trees
Dynamic programming
Breadth-first search, depth-first search
Quicksort, merge sort
2D arrays
Dynamic arrays
Big-O analysis
To name a few. Those are just the really, really common ones.

Isn't that a lot?

I'm sure it's excessive in a lot of cases, but it always depends.

The worst part about these—I guess let's just call them what they are: algorithm exams—is the luck-of-the-draw aspect. Some candidates may do better in an interview if they get lucky and are asked about an algorithm that happens to be what they studied the night before.

Imagine someone who understands his space and the related algorithms very well but decided to study some algorithms outside his day-to-day needs. If he goes into a technical interview that's for a position in his area of expertise and gets a question about an algorithm that he doesn't know because it has been irrelevant to his work up to this point, and it wasn't one of the extra ones he studied, he will feel cheated—as if it were bad luck, not a skills issue. And I think we can all agree that there should be no element of luck or chance in technical interviews.

But don't take my word for it. Listen to some of these developers:

“The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes.”

— Quincy Larson

"How many people really get to think about breadth first or binary trees daily? Most of us spend our days wondering why Chrome doesn't render a div in the expected way or why some API doesn't do what it should and finding workarounds."

— maxxxxx