Dude, that will not carry you through a hard problem.
You need the pocket Dijkstra, Kruskals, Union-find, Bellman-Ford, KMP, Kadanes (sliding window), LCS, DP (1-n dimensional), Topological Sorting, NP-hard heuristics (usually DP), BFS, DFS, Backtracking, Memoization (basically DP, but usually used in DFS), Prefix sums (DP as well), that weird palindrome-specific algorithm I can't remember, binary search, bisection (numerical anaylsis ftw!)
You also need tries, heaps, red-black trees, B-trees, DAGs, priority queues (heaps)
But wait.. there's more!
Euclidean algorithm, Josephus Problem, Sieve of Erastosthenes and all the number theory bullshit I can't remember and refuse to, because it has fuck all to do with daily engineering.
I have a masters degree from CMU, certainly a very top school in CS. I probably could've passed this style of interview fresh out of school. I did enjoy algorithm classes, it was fun.
It was also well over 20+ years ago and having had a successful career in silicon valley as an individual contributor, I have used that knowledge... never. Not once. It has no relevance to software engineering. I've forgotten nearly all of it. Want to hire someone to design and implement solid, performant, maintainable, secure production code? That's me. Want to test me by regurgitating memorized algorithms? Nope, I'm not participating in your game. The loss is yours.
I think that's a great reason to throw out the hard and harder medium questions.
I've never ever even heard of an interview problem where a b-tree or RB tree was required to solve it.
But my point stands that there are a ton of great little questions that involve very very basic data structures and tree traversal algorithms that you can use to glean quite a lot about a candidate.
You're absolutely right that asking a candidate if they can solve a 2D DP problem isn't telling you anything other than if they'd either seen this problem or they are good at this algorithm. I'm stating that you can learn a lot and eliminate some bad folks by asking some basic coding LC questions.
If you're talking FAANG you're talking hard level. If you're talking a company that fancies itself FAANG, you're talking medium-hard while being treated like a human septic tank, which could happen at FAANG as well.
I think most candidates could give a solution, just not while they are being treated like sardines and prodded with a stick.
It has made me ask myself: do I really want a job at FAANG, or any high level company? I mean if it's pumping out leetcode while simultaneously dealing with office politics and sadistic managers, I think I'll just go back to selling cocaine.
Are you failing interviews or are you just failing leetcode?
I've done 700+ LC and I still regularly get stuck on Meds/Hards, but I imagine if you know all these concepts and can explain tradeoffs during an interview, you have a better chance of passing than someone who immediately spits out a memorized solution but can't explain why they chose that specific approach over another.
FAANG just wants immediate, perfect solutions. The OA is also now exclusively hards. People on Blind talking about giving interviews and only accepting perfect, canned solutions. No talking through, no hints, or you fail.
You need the pocket Dijkstra, Kruskals, Union-find, Bellman-Ford, KMP, Kadanes (sliding window), LCS, DP (1-n dimensional), Topological Sorting, NP-hard heuristics (usually DP), BFS, DFS, Backtracking, Memoization (basically DP, but usually used in DFS), Prefix sums (DP as well), that weird palindrome-specific algorithm I can't remember, binary search, bisection (numerical anaylsis ftw!)
You also need tries, heaps, red-black trees, B-trees, DAGs, priority queues (heaps)
But wait.. there's more!
Euclidean algorithm, Josephus Problem, Sieve of Erastosthenes and all the number theory bullshit I can't remember and refuse to, because it has fuck all to do with daily engineering.