LeetCode: The Worst Thing to Happen to Software Engineering

Real life analogy of a live coding interview: "Here's a problem, I'm gonna stand here and watch you solve it in a couple of minutes, but no stress, if you don't make it fast enough, you get fired."

Every company I worked for that required leetcode problems, turned out to be toxic in some way. Every company that I worked for that didn't and instead asked questions relevant to the role, ended up being much better places to work. Just my own personal experience.

Another HUGE problem is non-FANG companies starting to use leetcode for their interviews because they want to copy these massive FANG companies and be perceived as them. All this does is make it harder for people to actually get a job. Imagine you have to do hard leetcode just to get hired at a small company. This just destroys the industry.

I agree with you on this. 99% of my job as a software engineer involves simple code. If I come across a problem that requires some algorithm that I don't remember, I can research it when I need it.

I do embedded systems. I write C code to control real world inputs/outputs. In 25 years, I've NEVER had to do anything with searching or strings; but that's what all the interviewers ask about.

This is fundamentally not a problem with leetcode. If it wasn't leetcode, it would have been something else. The problem is interviewers are trying to do their job with the least amount of effort.

Great video! In 27 years of programming, I've never once been presented with a customer problem that required a software solution within a few minutes or a few lines of code, or that could be solved without first spending many, many days understanding the nuances of the problem. The real test of a programmer is seeing how familiar they are with consuming and outputting CSV 😝

The really annoying thing is that a lot of the jobs that require leetcode interview problems DONT EVEN REQUIRE THAT LEVEL/STYLE OF PROGRAMMING. If you're hiring for a front end developer position, you aren't writing these complex algos. Guarantee someone has already written a module that works 'good enough' to solve your problem faster than it would take you to sit down and write out your own. Not only that but they skip critical skills actually necessary to do the job in favor of leetcode garbage. I had team members who passed leetcode interviews but didn't know CSS for a front end developer position!!

When I was in college these were called programming puzzles or programming contest problems. They're like daily brain stretching exercises. No one ever thought of them as job tests because you almost never run into a need to write this kind of stuff. And you wouldn't actually want to inflict some tight recursive backtracking function on the codebase or your colleagues. If you're using it as a test you're probably just looking for gatekeeping techniques to find people who like the same kind of puzzles you do or went to the same school. Not looking for software developers.

As a Full-Stack software dev working for small/medium companies I found that learning stuff like software architecture and coding patterns was much more beneficial than learning algorithms and data structures for these are mostly already applied on the frameworks and its internal methods that I use. Technical interviews for small/medium companies that require leet code type deep knowledge are definitely not realistic.

I'm old enough to remember when software development was fun. What happened?!?

Testing algorithms and data structures in job interview for a senior dev... Yeah, it's still happening. In my career (15 y) I've had to use typical algorithmic approach maybe a couple of times. The most difficult part is not even memorizing how e.g. streams work in Java or how particular framework works. Most difficult thing in software dev is to read code which is already written and expanding it. Second hardest thing is to resolve bugs of external frameworks and libraries and address exceptional cases.

I think leetcode is misused by interviewers who themself don't know much about coding. When I was involved in the hiring process in my previous company we asked a candidate to bring a project they have worked on (privately) and present it to us. We then did a little live code review and asked based on that project how the candidate would implemented a change that comes out throughout the presentation and review. You learn much more about the person and if it is not their own code you will be able to tell. But such an interview process requires experienced coders taking part in the interview as well.

Thank you for this. I was caught up in the game industry layoffs at the beginning of the year and EVERY SINGLE interview used leetcode or something similar. I've been a software engineer for around 20 years now and cant tell you the last time i hand-coded quick sort or a red-black tree... but those were the types of questions asked. Never mind that a candidate has worked in multiple languages across multiple industries... "if they cant code a quick sort in 15 minutes, we dont want them". I've been on the hiring side in the past and I think the combination of leetcode questions on timed, web based, non-interactive tests are completely worthless for anyone with experience. I'd much rather a candidate walk me through a problem they solved in the past and we have a conversation where they explain the problem, solution, why they chose the solution, how they discovered the solution, etc. But that takes time and hiring managers who also have a clue.... which seems to be more and more rare.

The problem is not LeetCode. The problem is that there are a lot of people responsible for interviewing who simply don't have the skills to do so. They see 'Outsourcing' the responsibility of interviewing to LeetCode as a lazy way out but it is abrogating their responsibilities and putting organisations at considerable risk. Whenever I interview people, I structure questions in ways that will very quickly reveal whether a candidate knows their stuff or not and to what depth. Any competent interviewer should be able to do this. If they can't, the management of an organisation shouldn't be risking the future of their organisation by exposing these people to interviewees.

We chose to use a code review for our interview process. We give the candidate a hypothetical ticket and the PR that was submitted against it and ask them to go to town with the red pen. The PR itself is a grab bag of errors we see people commonly making. We chuck in errors in coding style, forget to add unit tests, reimplement a standard library feature because the engineer didn’t consult the docco, nest if/else, basic SQL errors that would deliver a subtly incorrect result, pointless over abstraction, total lack of abstraction, use of inefficient pattern at an architectural level, use of spaghetti algo to solve some real life data requirement, etc The most important thing I look for is the tone of the candidates responses. In our teams view of the world, PR’s should be treated like pair coding and a spirit of collaboration is required. One word feedback like “No.” or know-it-alls who take pointless “I’ll die on this hill” positions over trivial or subjective code are the reason PR’s can spend a eternity in review, killing you velocity. Conversely we get people who are awesome at writing greenfield code but lack ability around reading other people’s code, and they are the reason teams, despite requiring two lgtm’s and a trip through QA, still manage to push trivial bugs. This kind of process isn’t going to work for a lot of teams given their processes and structure, but for us we have found it gives us the most accurate real world idea of what that person is going to be like when we dump them in the jockeys saddle.

Strong correlation between Leetcode interview questions and Toxic workplace environment.

While I agree that memorizing solutions of LeetCode to pass an interview is bad in ways mentioned in the video, understanding COMMON APPROACHES to write a solution that is memory and space efficient can save so much cost especially using cloud services that base total cost depending on how LONG your code takes to run and how much memory it needs. (reduces the need for scaling vertically or horizontally.) simply, memorizing is NOT the objective you should aim for when learning LeetCode, rather understanding the idea on how to forge an efficient code should be.

I can pretty much code anything thrown my way but fail miserably at leetcode interviews. My mind overthinks thing, I panic, and I fail. I also noticed that at places I worked that implemented leetcode it gave us people who could answer tricky questions but couldn’t code their way out of a paper bag and would miss such obvious things an experience dev would get. Do interviewers want someone who can write scalable enterprise software or answer tricky questions?

Interviews generally are terrible. Had one recently ask me in the context of structuring a website, "what would that look like?". Realised after the interview he meant what would it look like in an architectural or project organization way, ...I think. But as this was right off the back of discussing UIs, I talked about he actual GUI. This seems to happen a lot, people have a "I know what I mean" question, but forget that I can't read their thoughts, so they need to be explicit in asking the question clearly. And follow up and clarify instead of just going silent and being like "oh they didn't answer correctly".