It is a legit question, I'd finished my degree in 2016, it was a degree more focused in the job market, so I haven't had strong classes about CS fundamentals.<p>I'm working as a backend engineer for about 6 years, currently I'm ok with my salary and have no plans about applying to FAANG companies.<p>- I have some understanding about basic DS like Trees, Stacks, Queues and what are the benefits and drawbacks of using each one, but never worked with Graphs, and have no idea what is a Trie or a AVL tree, neither how to implement those DS.<p>- I understand what's the idea of Greedy Algorithms, Divide and Conquer Algorithms... But I don't know which sorting algorithms are the best, how to implement then (just bubble sort :/). I'm also quite bad at Leetcode style challenges.<p>Usually I expend my time studying about system design and not DS/Algo, my question is if I should invest some time learning those things, if it's really helpful in turning me a better developer or if it's really useful for those who are targeting interview in FAANG companies.
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 :)
FAANG is an investor term for people who want to throw money at the tech bubble. If, as a developer, you are not offered equity to work there I would forget that term as what you are really doing is brand name shopping for vanity.<p>> so I haven't had strong classes about CS fundamentals<p>I wouldn't worry about that. Most developers either treat their undergrad CS education like a weak trade school they don't take seriously, or are preparing for further education.<p>Honestly, it sounds like you are shopping for buzzwords in preparation from some future job interview. I would instead focus your energy on solving hard problems and building valid experience.
I don't think it's particularly important to know a big list of what all the data structures and algorithms are, what you really want is to be good at thinking about them and coming up with your own when you need it. But it's easy enough to get a big list of common data structures into your head. It takes about 2 seconds to learn what a trie or AVL tree are. Correction: 6 seconds, just type "avl tree" into Google and you'll be told precisely what it is in one sentence. In my head, all I remember is, it's a BST with some sort of balancing mechanism, and hey, balanced search trees exist, and the performance cost is from pointer chasing and rebalancing logic.<p>If it will make you more comfortable with the world to understand how popular sorting algorithms work, it's easy enough to learn that. They're all really simple, just a quick dive into Wikipedia. You'll be like, "Oh, that's what merge sort is."<p>You have worked with graphs. Git history is a directed acyclic graph.<p>Could you have made Git? Is there software you can't make right now because you're weak in data structures/algorithms type stuff? If so, then improving your ability in that department will make you a better developer.
Knowing obscure data structures or specific algorithms is rarely useful. But if you can’t do well on leetcode type problems it indicates a poor fundamental understanding of algorithm design, which is fundamental to the profession. Honestly it’s surprising you can work in the industry for 6 years without knowing this. It would be like, say, a radiologist working for 6 years without ever studying human anatomy. So, yes, you should study these topics.