If you want to work at Big4/5/whatever, you need to do a lot of leetcode or be naturally talented at solving algorithmic problems. It's not as hard as you think, though. Google, for example, really does not ask many leetcode "hard" questions IME. It depends on where you are looking to interview. In general, the most you really need to know is graph traversal algorithms like BFS and DFS and know data structures well. Basic implementations can be bruteforced, and to further optimize you can do things like sliding window algorithms or two pointer algorithms. Dynamic programming usually will not come up. Memoization is something you should know how to do though, and usually is a pretty natural optimization.<p>Of course, if you don't want to work at companies that do leetcode style interviews, there is no point in going much further than knowing data structures well and knowing basic algorithms (probably learn a sort better than bubble sort though... merge sort is pretty easy). You should know about trees, but I really doubt if you are applying for a company with sane hiring practices they will ever ask you to implement auto balancing trees.<p>In my experience interviewing with non-leetcode style interviews, I did get a lot more language trivia. For example, for a position primarily using Java, they ask about polymorphism, final vs finally, stuff like that. On onsites the focus is a lot more on STAR, past experience, and designing things. I personally actually like the former style of interview :)