The more experience I have the harder they are for me to solve, as engineering problems tend to have very different mental models to reach the solution.
That is what I think the true purpose of it is. It's poorly hidden age discrimination.
Funny thing is I had an interview some years ago and he asked me about cycle detection, so I gave the basic set approach, then added the tortoise and hare as a memory free solution.
It immediately made him uncomfortable and I didn't get the job, because he didn't like the tortoise and hare solution not being as "tractable" as the set solution.
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.
Going to call bullshit on that, since in recent interviews most people have been getting hard problems and not "trapped rainwater" prefix sum hard problems, but the kind where the optimal solution has nearly 100 lines of code involving multiple steps (topological sort combined with dp and other garbage at one go).
Easy problems literally mean jack and I don't even think 50 medium problems could span all of the possible topics.
It was 2019, so things may have changed but I doubt it. Maybe I was lucky? Or maybe you were unlucky. I also applied as a Senior SWE (mobile) if that makes any difference.
Out of the 12 companies I applied for I was given 2 hards (both were private startups), the rest were all mediums.
>nearly 100 lines of code involving multiple steps
I was never given anything even close to involving a 100 line solution. Are you sure this was even the correct/optimal solution? Either that or you're very unlucky. Which companies were asking such questions?
>50 medium problems could span all of the possible topics.
I was given problems that I hadn't encountered before, but I was able to solve them by deduction/critical thinking and applying the appropriate algorithms/patterns. Often the easy solution and the optimal solution weren't even that different, and just involved using a hashtable.
Grinding through hundreds of LC to try and memorize/familiarize yourself with the solutions really isn't the right method. Have you read Cracking the Coding Interview? Gayle McDowell has some videos on youtube in which she explains her process.
I was given problems that I hadn't encountered before, but I was able to solve them by deduction/critical thinking and applying the appropriate algorithms/patterns. Often the easy solution and the optimal solution weren't even that different, and just involved using a hashtable.
Can be anywhere from 1 minute to hours, depends on the problem. The whole classification thing is kind of ridiculous, because some hard problems are easy and some mediums are hard.
My role isn't to assess if you're competent or not. My role is to assess if I want you on my team or not. There's a difference.
And yes, if I ask you a technical question and you freeze, I don't want you on my team. It doesn't mean you're a bad engineer. It means you're not a good fit.
My role isn't to assess if you're competent or not. My role is to assess if I want you on my team or not. There's a difference.
Pretty much sums up how the hiring process is a gamble. So if you don't like somebody and they could be an asset to the company you would not hire them?
I actually like puzzles where I see that it involves analytical thinking, or creativity. Open-ended stuff where I am allowed to let my mind take over and not worry about a time limit or some artificial constraints.
I also find it unbearable to "solve" something I see the solution to, or can describe how to solve it. In fact, if I see the solution, I find myself unable to go through the steps to actually do it, especially if there is a time constraint involved.
The trick you have described was my way to do the problems in my spare time back when I hadn't seen them before, but the whole problem is that leetcode problems are designed for an incredibly narrow range of solutions.
Analytical solutions that have poor worst case run times, but incredibly good average case run times are not allowed and a lot of mathematical approaches involving matrices and exploiting vectorization aren't allowed either.
Leetcode-style problems force you to put your mind in a very narrow box and I simply can't do that. I've always had a very great need of orthogonalization in how I think and operate; i.e. if something doesn't stimulate me enough, I need another concurrent activity that is completely different to keep me motivated.
