As a non-software engineer who codes as a hobby but has no real software career experience I find leet coding challenges to not be particularly difficult or frustrating.
Can someone with better understanding explain the negative sentiment around leet coding. Are most SWE just mediocre at coding or is there just some fundamental difference between leet coding and the skills needed to be a SWE?
> Are most SWE just mediocre at coding or is there just some fundamental difference between leet coding and the skills needed to be a SWE?
At the risk of catching a lot of shit for this, I’m going to say yes to both of those.
A large amount of software development jobs involves taking various components big or small, and gluing them together with business logic of varying complexity and then trying to figure out what’s going wrong when one of the components or glues fails. Pretty much every job I’ve had personally has ended up being call some API / Query some DB and perform business logic on the results. There are a LOT of jobs like this out there, and a lot of them pay pretty good, by anyones standards who’s not into the whole tech culture. You perform at these just fine without hardly any knowledge of implementing many data structures or optimal algorithms.
I agree entirely with both these points, although i would note that the space of unlike-leetcode work is larger than just gluing. I've spent a lot of time in my career clarifying user requirements, hunting problems in data, writing build scripts and test tools, laying out UIs, parsing weird file formats, etc.
I have also sunk weeks on algorithmic problems much more complicated and less clear-cut than anything in leetcode!
The leetcode puzzles have no correlation with day to day software engineering.
But yes, that kind of puzzles can be fun sometimes! (Back when I had no family and free time for such things).
But worst part is that the interview experience is entirely different from doing puzzles for fun at home. In an interview you need to present a carefully choreographed act where you:
- pretend to be quickly discovering the solution out of the blue (even though the original algorithm took some PhD multiple years to figure out)
- never solving any part too quickly, or they'll fail you for having seen it before (of course you've seen it before if you've done the requisite months of practice)
- never solving any part too slowly, or you'll be labeled "yet another who can't even write an if statement" (comment seen often on HN)
- maintain a running commentary to "show how you think", make it credible
- while doing all this, be writing syntax perfect code on a whiteboard
- while the interviewer makes derogatory comments about how much help you appear to need, alternates between browsing social media on their phone
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.
My take as someone with a PhD in CompSci , Bsc in Software Engineering, and with 10+ in the software dev industry my take is that Leetcode type problems suck. They are "gotcha" types of tests for which you only need to know their specific answer.
As an interviewer I learned that they don't tell me anything useful: people who show they can solve them just show that they spent months churning.
Most of the problems in Leetcode are related to CompSci theory (DP, DFS, efficient graph or tree reversal, etc). Reality in most software Engineering jobs couldn't be further away from the that. Even if you are working with C, you'll likely use Boost or a similar library to solve a problem that requires any of that (implementing your own low level libraries is a sign that you are a jr dev... I've seen lots of them trying to implement their email validation fn or similar).
Exactly. I think it is reasonable to ask candidates to demonstrate basic programming competency, but "gotcha" questions are terrible.
Consider the interview question: "Write a function that can detect a cycle in a linked list."
> Between 1955 and 1967, the problem of “how do we determine if there is a cycle in a linked list without modifying the list or using an extra memory” was a essentially an open problem. Meaning, any number of PhD candidates in Mathematics or Computer Science could have written about it as part of their dissertation. With all of those hundreds and hundreds of minds, this problem remained open for 12 years.
> Do you honestly think you could, in a twenty minute interview, from scratch, come up with the solution to a problem that remained open in the field for 12 years, all under a pressure far more intense than any academic? Seems pretty damn unlikely, the only reason you think you could do so is that you’ve heard the answer before, and it seems obvious and simple in retrospect. In other words, “a-ha!”
While I agree that this is an example of a particularly ridiculous interview problem, and "gotcha" type interview problems are bad in general, I don't think it's accurate to say it was an open problem for 12 years. An open problem is one that has been posed but unsolved. In this case, the invention of the linked-list data structure in 1955 does not mean anyone had actually posed the problem of cycle-finding. It's possible, even probable, that the problem hadn't been seriously considered until Floyd did so and came up with the algorithm he published in 1967.
OTOH, if you've never done a few of those problems, you won't even know it's called a cycle, why they're bad, how to avoid them or find the library. There is usefulness in knowing the basics, and one way to know if your candidate knows, is by taking a look at the problems he/she tackled, or the courses taken. I agree it's a problem most devs won't encounter.
But that interest in the technical/algorithmic side of programming has turned into a paid job competition board ... I'm baffled.
Knowing that someone has the ability to grind leetcode for a few months is a pretty good signal of high conscientiousness. That's useful.
If they can use what they learned to solve variations on the problems they previously solved it's probably a good signal of above average intelligence. That's also useful.
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.
I feel the same, I can't really relate to the idea that leetcode style problems are about "memorize and regurgitate". Maybe you need to know a few basic data structures, but beyond that it feels like you can just figure things out as you go. Is the classic "invert a binary tree" actually so hard to figure out that you could only solve the problem if you had memorized the solution beforehand?
Agreed. My skill for straight up memorizing things is terrible. I dont know how one could do it with leetcode, especially since a lot of problems are “kinda similar, but with one major change that alters the entire approach.” To me, it is mindblowing to even attempt memorizing it at all. I will never understand how one can even attempt to deal with leetcode by memorization.
For me, leetcode just helped with intuition for tools and approaches. When i see a problem, i think “ok what are the constraints? With this in mind, would it be better solved using graph structures or some recursion? Which would be cleaner? Which would be better for memory? What about speed? Etc.”, and from that point, it is just pure problem solving on the spot. Occasionally, i get those “oh, I remember solving a problem that wasnt quite like that at all, but it reminds me of it on fundamental level, and back then i remember using a recursive approach (though i dont even remember the problem at all anymore). What would happen if i approached this current problem the same way?”.
It just straight up helps me keep going and coming up with possible approaches to consider, as well as analyze and evaluate them, rather than being frozen on a problem for a while. And those “approaches” aren’t specific to a single unique problem, they apply on a fundamental level to a lot of other completely unrelated problems.
Yes, I’ve seen double nested for-loops in production code, which later became a performance bottleneck that had to be addressed. The issue is that “the problem” in that case was something that can be solved in linear time, and it would be a leetcode easy problem level of difficulty. It instantly jumped out to me wildly the second i saw that piece of code, but no original code reviewers were concerned. This is the kind of stuff leetcode is supposed to help with. Not with solving specific problems, but giving you a solid toolset and intuition on fundamental screwups and how to avoid them and spot them quickly in bajillion different situations that dont look the same at all.
Memorization won’t be your friend here, unless you possess one of those photographic memory brains that remembers the faces of every single person they’ve ever encountered. If you are going into leetcode with the mindset of “i am trying to memorize as many problem solutions as i can”, you are gonna have an awful time.
10+ YOE myself, ranging from CTO to big orgs. I can tell you when I was fresh out of school I actually liked those kinds of challenges, but I trained on them relentlessly as part of participating in programming olympiads and the like.
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.
First thing you do is you ask people is that the problem they are actually need solving - most of the time refining the problem leads to there being something totally different that is requires. A process of asking people “why you want this hard to implement thing” and discovering that what they actually need is something smaller and more aligned with whats currently working. Leet code is the opposite usually - you see a simple problem but “there is a twist” that would be considered scope creep generally.
Then the implementation of the solution itself requires knowledge in your head, whereas years of experience has led me to put a lot of that knowledge out of my head and into “places I trust to find the answer” - google stack overflow, HN etc. And keep in my brain only the general abstractions of how to apply them. This allows for vastly more powerful solution making as you can stand on the shoulders of giants.
Example - see you have a leetcode puzzle. My first instinct is to use my google fu to find out what the best current solution is out there, understand it and either apply it or modify it a bit if it needs tweaking.
But that would be considered “cheating”. Leetcode: 1, Life skills: 0.
And there is the damn time pressure. Every time I’m pressed for time on my day job, its a signal something in tech or management has gone wrong, and I seek to optimize and fix that. Rushed engineers make poor, shortsighted decisions.
Each time I do an interview I feel out of sorts as all my instincts scream “something is really bad, you should _not_ be doing this solution this way it will bring pain in the future” But you have to power through. And I probably look way less impressive than someone who has the solution memorized.
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.
I mean there’s two camps. One camp can do them easily or with practice, another camp can’t.
The first camp is pretty “meh” about leet code interviews because for them you just study a bit and get a high paying job.
The second camp is pretty vocal about how bad leet code is because it’s somewhat of a personal attack on their abilities.
Personally I agree with the criticism that leet code can be learned with enough practice and so it’s not totally indicative of a positive hire. But then I also sorta feel like there’s enough examples out there that people should be able to ace these tests with practice.
Some SWE just write code, they wanna make features and build a product. They don’t care about this stuff because things are fast enough without the extra thought — and if they turn out not fast enough they can still fix the issue.
Other SWE are more careful with their code, performance, etc. this is more of a systems engineer personality. Writing C, managing memory, writing optimized code the first go round. Yah, being thoughtful and careful pays off here.
No one’s right or wrong imo, or one better than the other.
Should FAANG do leet code interviews? I dunno, there’s surely better ways to interview, but at the same time they’ve hired plenty of highly talented engineers so something’s working for them?
Should SWE’s just spend a few weeks on leet code and learn the tricks? Ya, it’s pretty easy. But if you don’t want the job then don’t do it?
All the endless criticism of leet code generally comes from people who fail it. Shrug.
You'd be shocked at how bad the average software developer is at writing software. I've interviewed many people who can't solve FizzBuzz level problems. In interviews I have people program a function to rearrange characters in a string, appropriately named "SimpleProblem", and >50% of candidates with experience can't write a function that compiles and solves the problem.
LeetCode is just what you get when you ask Software Engineers to solve the interview problem - they like showing off their chops so that's what you get. It doesn't need to be that complicated though. I know with about 80% certainty whether someone will work out based on how they solve that "SimpleProblem". The other 20% - just fire them if they don't work out. It doesn't need to be that hard. You don't need 100% certainty for a hire, you'll never get there. Just fire the ones that don't work out. You don't even need to feel bad for them - in this market they'll find another job by the end of the month.
> In interviews I have people program a function to rearrange characters in a string, appropriately named "SimpleProblem", and >50% of candidates with experience can't write a function that compiles and solves the problem.
I would struggle with this problem, because it's difficult to read whether you want me to push back against the requirement itself and try to solve the real problem instead of shuffling chars, or perhaps you want me to talk about the edge cases you're likely to encounter while I write the naïve solution, or maybe you want to pretend it's the 80s and nothing outside your chosen charset could ever exist in real data.
In my experience leetcode mostly tests algorithmic thinking. Write a sort function, for example, but the problem is, in real life you use a library with a well tested, battle-hardened sort implementation.
It IS important that you understand the algorithms, but I think they are far less important than data modeling and systems design. In any application, you must be able to understand and design how you model business things, and where you put them, and how and when you access them. Also how you fit a small unit of business logic into the larger picture.
This is much harder to test for, since for a given problem there might be multiple, equally valid models and solutions. So obviously the kind of auto-verification leetcode sites do does not work. There must be a human evaluating the solution, which is much more expensive.
My guess is a sense if urgency in doing them? That is, you don't give them overly frustrating. What about getting them done in fifteen minutes? The time constraint is a major part of it. Add in any discussions, and it adds to anxiety for those of us that aren't good at social.
There's zero difference. It teaches you how to solve problems analytically. In the real world you have to solve problems analytically too, even if you have a terrible corporate job writing some template for a bank you're going to run into something that needs solving eventually.
Here is the truth about leetcode, advent of code, codeforces, whatever similar problem site:
There is no memorization involved, just like you don't memorize every math problem on earth to map directly to a correct answer you instead derive the answer using the skills you have in math from experience solving problems before. Polya has a book for this, called 'How to Solve It' he just happens to have used math to teach problem solving but it's the exact same concept.
You have at your disposal problem solving strategies such as: complete search, dynamic programming, greedy and divide and conquer. You don't need to memorize any code to write a greedy search, you could ad-hoc hack that together just know what a greedy strategy is. You don't memorize all search algorithms throughout history ever invented.
There is no grind. People who haven't done it assume you sit there for hours daily writing brute force algorithms, no. Instead it's exactly like doing a crossword puzzle over a coffee and something you can do at your leisure where in a month or so you're now at leetcode medium/hard no problem.
In my limited experience, the difference between these problem solving sites and a job interview is after your hacky ad-hoc greedy search solution they will ask you to optimize it 'can we make this faster' so really for an interview you only need knowledge of the language you are using and it's built-in data structures what their complexity is. That doesn't require much memorization either just know how they are implemented looking at the standard library or documentation where hopefully somebody has explained the implementation 'this dynamic array has constant time access, but linear replication when full'. Only that level of knowledge, like knowing how to move something out of a loop so it's not repeatedly initializing or rewriting your solution in another data structure no insanely advanced algorithm analysis needed just practice using the language standard library or container libraries enough and this will be easy. People make this harder than it really is, tl;dr learn problem solving techniques either from logic philosophy texts, math or programming problems, learn the standard library of the language you want to use, that's it.
Honestly curious, how long does it take to do an average medium problem and pass all test cases? Are you spending like, an hour or ten minutes? Somewhere in between?
Depends a lot on the problem, for medium probably between 15-30 min for most. I have interviewed at FAANG companies for software roles and done the whole on-site leet coding gauntlet. Did about an hour a night for a week total prep. I can solve their problems, what gets me is when I finished early and they ask more academic follow up questions. Like getting backed into a corner and having to admit I have no idea what big-O notation is.
How do you know that scanning an array looking for a number in a sorted array vs. searching for it is slower? Just kind of intuitively? Do you have your own terms for it? I too sometimes get dinged because I use the non academic terms for things...
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.
Can someone with better understanding explain the negative sentiment around leet coding. Are most SWE just mediocre at coding or is there just some fundamental difference between leet coding and the skills needed to be a SWE?