LeetCode: The Worst Thing to Happen to Software Engineering
Вставка
- Опубліковано 6 чер 2024
- Should you grind LeetCode all day to get a job? Will LeetCode teach you to be a good coder? If you're tired of grinding endless coding problems and starting to hate it, this video is for you. I don’t think LeetCode is an accurate reflection of a software engineer’s daily duties and it can be misleading for job interviews.
#leetcode #softwareengineer - Наука та технологія
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."
This. ☝️
I've heard that some aren't so bad, and that good interviewers just want to see your problem solving process. But yeah I assume the majority are just nasty problems there to filter people.
Nope, interviwers are more concerned about the thinking process, rather than if you solve the problem or not.
@@luisoncpp definetly...
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.
Same here.
Most coding interviews are basic CS fundamentals. You're just hating because you're bad at basic CS.
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.
And then the shocker when they employ the leetcode memorizers and it turns out they don’t know how to tackle any real world software engineering tasks.
If you can't answer 20 leet code questions, you're not intelligent enough to work on our wordpress site 🤣🤣 that no one uses.
100%
And they are completely different things. Take someone who scored 100 out of 100 in leet code and tell them to upgrade your Spring Boot app from 2.7.2 to 3.3.1 and deal with all the broken entity classes, H2 dependencies, code breaking elasticsearch changes and so on. And see how well he will perform. And on contrary take senior with 10 years of Spring Boot experience who is Oracle Java Certified and so on and send him to leet code interview and see how well he performs...
Case in point. But the supply of SWE/Developers is extremely high thanks to bootcamps, online certs and coding schools like wethinkcode. They are the ones who truly ruined the industry. Promising someone to go from knowing nothing about programming to a fully-fledged SWE in one or two years. So now the bar for technical skills must be raised to weed out the imposters which to me makes perfect sense.
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've found that when I find some code where I get to use some awesome algorithm, that I've often failed to consider that I can use some other tool to solve it faster / better and in more maintainable fashion.
Sadly for application programming it's rarely justified to write cool algorithms.
Code interview rarely ask you about specific coding algorithm, and it's usually pretty simple code. Thinks like linked lists and binary trees are the most simple data structures, asking anything different could be too demanding to do it in less than an hour.
A simple example of something similar but practical: you receive a JSON with posibbly many nested objects, some of them may have a field named _id of type string with a serialized ObjectId(from bson/mongodb). You want to create a copy of the same object but replacing the _id strings by actual instances of ObjectId.
That has happened to me in my workday, but asking this questions in an interview would made it too specific about JavaScript and non relational databases, so it would be better to replace the Json by a tree, and the _id by just a special kind of node.
"I work on simple stack - everything should be simple". Bro, painting buttons and writing low level code on C - completely different. Im completely sure that you are not working on low level (and I don't say you are painting buttons on css, it's an example)
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.
25 years in C and you never had to write your own search algorithm? But you at least would know where to start, yes?
@@evancourtney7746 I think you missed the "embedded" part.
Yes, I know how to research which search algo I'd need but in the bare metal / RTOS world, N is usually very small (like 10), so O(n) search is fast and easy.
@@evancourtney7746 I'd start with LeetCode "search/find [something]" j/k
@@evancourtney7746 In embedded systems, you usually only have a few kilobytes of RAM, so it's okay if you just iterate through an array until you find whatever you were looking for, it won't take long so you don't need to do anything clever.
That's weak bro
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.
Sadly very true.
True! But most of the times, interviewers at tech companies are not doing that as full time job but more of a side task. They are just trying to "optimize" the process as much as possible.
the actual way to interview is to, well, interview people. Like actual speaking and such. I've conducted hundreds of interviews and hired dozens of good quality coders relying 90% on a face-to-face interview and 10% on a simple exam-style test (using pen and paper) to make sure they're not muppets with the gift of the gab (I've met a few of them).
Over-reliance on these tests is poor practice by lazy interviewers and it will come back to bite many of them.
It surely sounds an effective process. For personal interest (since I also, need to routinely conduct interviews), may I ask what kind of questions were you asking on the pen-and-paper part?
@@mariolix89 certainly. We started with some simple design questions (what is MVC, Ajax, etc., give the pros and cons of soap Vs rest). A couple of coding questions asking for them to show it as they would production code in whichever language they were comfortable with (we were happy to retrain good Devs to c#). And some SQL questions that were not hugely difficult. The candidate was given instructions how to answer and each section was given a percentage score. The gotcha was they had 45 minutes to do an hour test, so they had to prioritise how much effort to give each section. It was as much about technical proficiency as it was time management.
The point of the test was to see how they operated under pressure and to make sure they had some technical chops. The rest, actual level of competence, could be teased out in the interview. My favourite interview question: what have you worked on recently that you're proud of? The answer was always varied but it was a level of passion and intensity that I was looking for
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 😝
Leetcode and other such platforms are not for mundane manipulation with json and csv. It's for fun, self-improvement, competition, practice and for the art.
It's great for brain, for coding practice, for learning algorithms and CS.
It's definitely not everything that programmer should know and if some people think that grinding LC can guarantee them dream job - it's their own fault.
Just use it right.
@@bxp_bass sounds like "leetcode" is what you ask the llm to do for you these days (because llms are actually trained on such small stupid algorithmic problems)
@@bxp_basswow, you Just solved the problem
they should test if you can adjust a button margin instead 😂 that would cover 90 % of daily job tasks
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!!
It's just lazy hiring practices. Just because you're fresh out of college and can solve some algorithm problem doesnt mean you're good at working on large scale corporate software projects.
But its much easier to let an automated program "determine" the technical level of a candidate and disqualify you than have a lead engineer take 30min of their day to write a "real world" technical assesment pdf document. Come on, who's got that kind of time...
I was once asked to write code to swap two variables over (honestly). I made the point by writing it in every language I knew :)
@@BillClinton228This!
Whether someone knows algo or not does not mean they can design database tables efficiently, does not mean they write future proof code, does not mean they can voice shortcomings or concerns to their managers, does not mean they have any kind of experience using the tooling that we use in enterprise, etc.
If anything it's probably the opposite. Someone who spends months blindly memorizing leetcode solutions and optimizing them is wasting time instead of practicing things that their future employers will *actually* expect from them.
Most jobs in SWE aren't related to algo at all. I can only think of game dev, robotic/spatial embedded and some specific uses in system programing.
When you end up wasting thousands of dollars because your API exposes complete data from multiple endpoints because you were too busy practicing bfs algos instead of practicing real design problems, hopefully then it'll be a wake up call.
@@charlesm.2604robotics and embedded? Not even close... I don't know about games tho... But I suspect that this things are just almost never used... Same as almost every engineer barely usit the advanced math they learned in college...
@@gabrielbarrantes6946 For gamedev algo is super important, trust me I spent countless caffeinated sleepless nights during my indie gamedev phase, that shit gave me PTSD! 😂
I guess you're right for robotics though the sdk libraries are the ones who implement algo so even in most embedded usecases it's not required 😅
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.
'almost never need to write this kind of stuff' maybe not to extent of mediums/hards on leetcode, and rarely in such arcane ways, but otherwise your statement is just false, or perhaps only true in your own anecdotal experience. Using some of the common patterns like DFS, sliding window, etc, that you learn when solving leetcode problems are for sure powerful in day to day engineering? The truth usually is somewhere in between two extreme views rather than 'almost always' or 'almost never' as you put it. Also... if it means getting paid an absolute ton of money and adding FAANG to your CV, is it really so bad to just play the game and 'learn the secret handshake'? I do agree but just not with the 'almost never' bit
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.
That's right. After 15 years of being a software dev I've used typical algorithms (e.g. graphs) maybe once or twice.
I'm an RF engineer (design of radio circuits e.g. cell phones etc...) and I develop software for internal data analysis and measurements only. This is exactly what I expected. One can and should look up algorithms and can and should get their code from online sources such as Github. Indeed architecture is the big challenge. You can't download that but must create it for each project.
Any good books or other sources to recommend for that kind of thing?
@@yinspiron3348 In my case I feel I went a long way learning from udemy courses and other online platforms. If you search for software architecture or coding patterns on Udemy you can pick and choose (choose ones with good rating) what you want to learn keeping in mind your personal goals or work requirements. I´ts also very common for me to go back to a section of a given udemy course to review some area that I'm having trouble with or even buying a course to learn something that is required for some work I'm doing at some point.
Also some tutors update their courses and that makes them better than books ;-)
@@yinspiron3348 Clean Architecture by Uncle Bob and any Design Patterns book would be your start point.
I'm old enough to remember when software development was fun. What happened?!?
People got into for the money alone and not because they are tinkerers.
you had it good , lucky people.
I wish I was a graduate in the 80's or 90's ... at a time where people made real software to solve real problems .
now they're pretty much like google : "I have a pretty good search engine , but let's replace it by a stochastic function to interpolate search results , and call this AI" hahaha
FAANG madness
@@Daijyobanai True. For me, the change started with Microsoft's infamous interview question "Why are man-hole covers round?" Whether brain-teasers or leet code, neither are effective measures of job performance.
The internet is what happened. Almost every aspect of life was better without it.
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.
This is brilliant! Wish more interviews were like this
Yep, it's the best approach. And I remember the times when it worked. Now it's just a bunch of general questions, leetcode and test task which nobody bothers to even review when it's done.
Which penalizes developers who don't have time to do personal projects.
@@YDV669 Well, in that case you also might not have time to train using Leeetcode, right?
And it doesn't need to be, as you can just resort to an alternative plan for the job interview in these cases and don't hold it against the candidate.
Leetcode or no, the hiring process in software dev and to an extent IT in general is very peculiar. I can't think of any other regular job where people are expected to keep working at their job in their free time. "So, mr. Plumber, can we see some private plumbing you've done recently? Do you spend your weekends catching up on the latest advancements in plumbing tape?"
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.
it's the dumbest thing. For 99% of algorithms a competent programming would just get a library and save time not writing what is essentially boilerplate. For the rest, it should take more than 15 minutes.
Implement a quicksort or a red-black tree in the whiteboard?, that seems pretty dumb imho, but at the same time, I'm not sure how much believe you, since I was an interviewer myself in a big tech company and nobody was suggesting that kind of stuff. I also have seen interview problems from a couple of other big tech companies and they didn't ask that.
Usually they ask for simple things like a window sliding, simple operations on liked lists or a simple operation in the most basic binary tree (not red-back tree).
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.
I disagree, I think the problem is really LeetCode. I have been an interviewer myself and I was instructed to care more about the reasoning process, the coding style, and the questions that the candidate makes to ponder edge cases rather than if they found the most efficient solution for the problem or not.
Interviews are designed to be a conversation with the candidate when they are tackling a technical problem that they haven't found before rather than checking if they memorized the problem or not.
When I interviewed to big tech, recruiters recommended me a couple of books, those books mention that. Nobody told me to grind Leetcode and I didn't do it.
If interviewers are not the problems, and recruiters are not the problems, the problem is the community itself that has been created around Leetcode, and probably Leetcode as a company hasn't done anything to stop it because it's beneficial for them.
@@luisoncpp I'd suggest that it is probably both: Leetcode has a vested interest in the status quo and organisations are 'outsourcing' some or all of the interviewing/recruitment processes.
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.
Someone give this man a damn medal.
Yeah except you can look that shit up, no need to memorize it and you'd often get more bang for your buck switching the language/runtime than swapping out algorithms when it comes to faster execution of things like LAMDA functions...
The idea of understanding solutions to problems of any type is good in itself. However, this is not the objective of newcomers (or even some experienced engineers) for using leetcode. Their objective is to pass interviews. The problem is with interviews and the culture of interviewers, which encourages this stupidity.
@@kevinb1594yeah, nowadays we can just google it or even ask AI like github’s copilot
Yes I agree that's why I think some level of leetcode makes sense. Someone good at overall coding and algorithms should be able to solve any easy-level leetcode problem. But the hard-level ones, maybe 0.1% of devs who never seen the problem before can solve them. But with leetcode, people can memorize solutions to these hard-level problems. Which kinda defeats the whole purpose of asking them.
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".
There is another point to consider here: some interviewers present very vague problems intentionally just to hear which questions the candidate asks. A programming job is a constant pondering between different constrains, a way to evaluate if you can detect which constrains are important is to check if you ask the correct questions for clarification.
Grinding leetcode is like learning scales on the piano in order to join an industry where you're supposed to write symphonies like Beethoven, given time. When you're in the engineering environment, it doesn't work like that day to day... ever... not even in FANG... (trust me on this, I work there).
I've also worked with incredibly competent engineers who, when made redundant, were asked leetcode style questions by small companies who 'think they're Google'. He didn't get the job, confidence so utterly destroyed that he thought he should change industry.
On the other hand, the best interview for engineering I ever had was surrounded with questions like: "You live in a country which drives on the left. The government put you in charge of a new initiative to change the traffic system so everyone drives on the right. So... how would you go about it?". You start proposing logistical solutions and in collaboration with the interviewer, you go down the rabbit hole probing the weaknesses with your idea and you collaboratively change the plan and correct your thinking as the interviewer finds holes in your solutions. It's not about 'correctness'. It's about mental agility and can you think flexibly and creatively.
You can't study for this, and basically the intake of candidates was from people of all walks of life - not just Comp Sci. I got the job and worked with amazing people who were trained in astrophysics, art and textile design. They still work in the industry, some of the best engineers I ever worked with.
While anyone can be a trained monkey, I prefer to work with creative intelligent people and this was (as intimidating as it was) the BEST interview process I have ever come across. The company by the way is a household name and extremely successful in the UK to this very day.
I would disagree with this analogy, because at least scales are useful and used in music all the time, and are good to practice. Imo a better analogy would be leet code is like learning a 3 second piece of a song. It's completely useless, nobody wants to hear it, and you aren't going to learn to play an instrument that way because literally anyone can learn to play 3 seconds of a song on an instrument given enough time
In my opinion, Leetcode should be used for only 1 thing. Learning how to code more effectively. It should be used as training exercises only. Not as an indication of how good someone is at a job that has nothing to with algorithmic programming.
These problems are perfect for ChatGPT. You don’t need a software engineer for them.
Going to use that in the next interview.
Interview with rat-moustache: "how would you [snickers to self] solve this problem [more creepy snickering and inappropriate touching of self]"
Me "[types problem into AI, tells rat-tache to g*t ****ed] like this".
Same way I wouldn't spend a day writing a regex when I could go to one of 50 regex checker sites and do it there in the pre-AI days.
Just what I was thinking.
Because ChatGPT is trained on LeetCode. 🙂
Surprisingly they aren’t lol. Because of the volume of bad solutions online ChatGPT has a ton of bad data
@@investing_engineer I would say that ChatGPT team is separating bad and good learning data quite well. But the problem is rather that ChatGPT cant think on it's own. It's like LeetCode student who has memorized absolutely everything but understands absolutely nothing.
Excellent! With decades of experience, I rarely had to implement data structure algorithms. The biggest problems were understanding the stakeholders, managing expectations, solving the lack of documentation on systems, and other non-coding tasks. You nailed it. It’s the thinking that matters. Everything in engineering is dependent on managing constraints
Leetcode is not bad practise, overuse of it is and ignoring others aspects of Software Engineering is.
Love your commentaries. And am glad you didn't edit out that thing near the beginning. Retired / burned out software eng here. I never had to do much with Leetcode, it was mostly after my time. Though I am giving some of these LeetCode questions to one of my students. I think he needs to know what he is going to face.
I’m subscribing to your channel because you don’t hold back, wonderful to hear your perspective. Keep it up!
TLDR: Leetcode in itself is a haven of learning software engineering.
If you enjoy leetcoding to a certain degree, you're on the right path.
Grinding the hell out of Leetcode while not enjoying it at all just because these fucking corporates set their shitty interviews that way is the real problem.
I myself was benefitted immensely after spending hours on Leetcode, because I like doing it and learnt a whole lot of new concepts along the way. My programming skills certainly skyrocketed and so did my problem solving skills.
It also makes you think more low-level about creating your subroutines for a given problem.
Interviewers seem to not care that these problems are kinda based on CS Data Structures & Algorithms and lots of SWE's don't have formal qualifications, yet the interviewers wants you code like a CS dev when it's not required IRL.
I had interview where instead of LeetCode they gave me frameworks that I had never seen before and asked me to code some features to some dummy 100-200 lines long web app they've created. And what they wanted to see was who well I can read the documentation of framework that I have not seen before and how well I can figure things out - they didn't even care that I finish the solution within given time limit. Since I am not a math person I was fine with it because math questions to me would mean that I could only pass them within time limit if I have memorized it before. But with frameworks if you have general understanding, you will get a ton of hints from autocomplete alone so it's much easier for me and much better for company because my real job wasnt to code algorithms.
It does seem rather pointless using LeetCode because many problems need to be thought out and not just coding a solution from memory! They need to use a real-world problem and give the candidate a test to see if they can problem-solve the answer using reason. This would be a better determination of their coding ability!
Exactly! A lot of these problems are so discrete and in a closed environment. It just doesn’t happen IRL. I just wonder how much affect it has on someone grinding leetcode for 3 months and then coming across an actual SWE problem…
Very good point, also it gives you insight on how the person tackles the problem which is very important. Leetcode will not give you this.
@@mudi2000a I totally agree!
Or ask them to demonstrate and talk through the development process of a personal project.
@@brandyballoon That is a good point and would do much to show their true capabilities!
Coding exercises are generally a waste of time because you can make/contribute to functioning projects instead. Leetcode questions teach you next to nothing about broader project structure and working with other people's code.
The company I work for found that there’s a correlation between how well someone answer DSA questions and how well someone answers system design. Might just be because they’re probably interview prepped more but we hope that DSA knowledge bleeds into system design, which kinda makes sense when choosing the right database for the problem.
Problem solving ability is indeed related. Solving a lot of maths automatically makes you waaaay better at leetcode and system design as well.
@@TapetBart Well technically speaking everything is an algorithm. When people talk about using algorithms, they're talking about the leetcode problems like "Check a linked list to see if it has any cycles."
And well for the most part, I have to say, the argument is more or less valid. I can't think of the last time I even used a linked list, let alone had a need to run some leetcode algorithm on one. While I use things like Hashmaps, I can't remember the last time I've actually written a hashing function. So for the most part, I don't really need to know much about the algorithm behind the Hashmap, just that it has faster lookup than a vector/list/array.
IMO, leetCode is great for getting practice questions and storing up on strategies to efficiently solve unnatural problems using data structures and a few algorithms.
The issue with the industry is the interviewers. Now it's no secret that you need some math skill to be able to solve some problems efficiently while building software, heck you might need it with something as trivial as a clip-path in CSS, however for sometime now the number of math Olympiad style questions masqueraded as DSA (data structures and algorithms) problems has increased greatly on the platform and interviewers might pick that because it has a low acceptance rate or it just seems too hard for a junior engineer to pass. That's where I draw the line.
If a question isn't relying solely on data structures and algorithms knowledge to solve it, and might require some specific math knowledge (for example combinatorics), then in my opinion, it's a screening interview where only the math-heads get through unfortunately.
Most refreshing UA-cam video I have seen in such a long time. Keep making these kind of video'sDee
I like leetcode for challenges against friends, but agree that it isn't a great interview tool
So glad I'm at the end of my programming career rather than at the start! No way I'd get a job today. Back in the day when I was interviewing programmers for a job, we got tired of getting programmers who only knew how to code in theory but had really not put in the time at the computer (i.e. could hardly use the keyboard). In the end I started giving a typing test so we could see if we were getting BSed! :) I guess things have escalated from there!
In Leetcode training, there's an elephant in the room: a perfect Leetcode interview candidate is a chatbot that scanned all the Leetcode canned answers as its training data set. Faster, less expensive than a biological programmer, doesn't complain, doesn't ask for a raise, no unemployment insurance, etc..
This means clever, productive, ingenious programmers will be replaced by Leetcode-trained people. Then the latter will be replaced by AI.
I've been a developer for 20 years, and I've never had a situation where I only have 10 minutes to devise a solution to a problem. This style of interviewing is certainly horrible. Great video!
I have worked with people who solve everything in the LeetCode style and it is horrible, they end up with complicated and untestable code even for the easiest problems.
Completely agree with your assessment.
Being able to identify when an algorithm is required, what data is needed, and how the feature integrates into the larger application is far more important.
You can search or just use pre-built implementations (that are already proven and tested) of most algorithms. You can't do the same for application/solution design.
the problem isn't just leetcode. at my company we use IKM. the problem with IKM is that it tests for an extremely specific skillset, when the job requires multiple skillsets. so we always overtest and always undertest because the company refuses to administer (read: pay for) the multiple required tests. got so bad for my time i just say ok, 30 minute interview and a thorough check of your CV and i'll take the risk. for the most junior only. for the more senior i do a vague take-home test. the idea is i don't have to tell you to use SOLID and Clean architecture if you're really a senior, it's really how you fill in the technical blanks...
Software engineers from all countries - unite! in order to change the rules of the game and keep the high salaries
Right now, I think the software job market needs to strike a balance. It seems DSA is more of an excuse to reduce the number of applicants or some form of hazing ritual.
If an applicant is tested for basic DSA and then moves on to the core of the job requirement, it will be a more balanced process.
Thank you so much for the advice, I do struggle with Leet codes and finds it not as helpful as it seems in real life experience.
One thing I like about leetcode is you can see other people's solutions, analyze them and discover some new tricks which might make your code look nicer or work better. They're sorted by performance and it can really help to adopt better practices in my opinion. But of course grinding and memorizing solutions it's something opposite of programming. I didn't even know it was a thing.
Gold Star for this ! Thanks.
We are a startup and we also do Coding challenge. But it's a full stack project of the candidate's choice of problem statement and technology for 3 days.
This gives us a holistic view of their critical thinking, design thinking and also skills. And then we ask them to explain it by scanning the code and propose scenarios e.g. best data structures for improving a given logic or best infrastructure architecture that would work for a given question or if the technology used moves from SQL to Nosql etc.
It keeps them grounded and forces them to learn the code even if they had to do a blind copy paste
Saw the video on agile and now this one. Subbed.
When I saw this video I was initially very skeptical. However, as a software developer of 30 years I agree with everything you say here. It seems you are giving out genuinely relevant advice and not just looking for clicks/views like some other UA-cam "developers"
As a Product Leader who has not written code for over a decade - you are so right. As a hiring manager who has hired over 100 people over the years - you are so right.
A good software engineer always asks clarifying questions on edge cases and failure modes. After all, with big data even a small percentage of edge cases, is still a lot of edge cases…
How does adding numbers backwards work? Do you expect a different answer as opposed to just adding the two numbers?
The two lists each represent a single number, with each node being a single digit. It’s in reverse order because that’s how you do addition: add the two least significant digits and carry to the next one.
When I interviewed for big tech, the recruiters told me to read Programming Interviews Exposed, where it explains that talking about the thinking process and asking the right questions is important.
I also was a Google employee and we didn't use Leetcode problems to interview people, we were actively told to choose problems that were not in that kind of websites.
Overall I am happy that someone finally talks about this issue, I'm planning to talk about that as well.
I've been in software engineering for decades. I'd never heard of leetcode, lol. I've interviewed hundreds of times. And the way you describe problem solving irl is how I see it. It's usually a set of trade offs. Not a very specific graph theory problem with a single very specific solution.
This is refreshing. Some exercises such as 2some is well worth learning.
I know this isn't the point of the video, but ive never used leetcode, but after seening the examples you gave in the video I might give it a try. Don't get me wrong, i have 0 aspirations to get into faang, nor am I the "grind for interviews" type, but solving the problems sounds kinda fun.
Agree with your take that solving thousands of similar small problems does not really help in the real world when you are faced with a problem you've never seen yet.
The approach you take to tackle these problems, is all the difference between a successful software engineer / dev and those who will not get it.
good video. i have one question tho. what would the alternative be? im in uni rn to become a software engineer, and i thought leetcode would be pretty useful. what would be the alternative then in order to become a better software engineer?
Leetcode is practice, it's not something you want to memorize
As far as I can tell from more than three decades working in the IT business, we do not have leetcode-like interview questions at all in the hiring process here in Germany. We don't ask them, we don't have to answer them.
I just recently discovered leetcode on my journey to learn Rust, and took some problems there as exercises on how to do that in Rust. I found that quite helpful. The work on one problem even evolved into a small example of computer generated art. It was fun.
Thanks for the video ❤
As a cybersecurity engineer (with some software dev background) who sits in on interviews as a technical interviewer, I spend time looking at someone's resume and asking questions to validate their knowledge as well. If someone manages to get to an interview and that don't exactly meet the requirements we find out if they are a team fit and ask abstract questions to see if they could fit the role. A key question I always ask in some way or another is "if you didn't know the answer what would you do?" and I'm literally just wanting them to tell me they Google it. I'm not an expert interviewer but I've not been disappointed by the several candidates I've given a thumbs up for. To get quality hires, you need quality interviewers, which requires a pool of existing quality talent who don't have an ego so large they need to flex hardcore unrealistic problems on candidates. I've certainly asked challenging questions - I've been surprised to get right answers but I'm more asking to see how they handle a problem.
I think there is also a certain level of creativity that makes a great developer. My background was in bioinformatics, so using analytical tools like R and Python to draw conclusions from biological data like genomics. I wanted to expand my skills from what was becoming monotonous number crunching so I would make an interactive app for each plot I made. I started out making basic Shiny apps but then started hooking them up to backend dbs like Mongo prettying them up with HTML, CSS, and JS. Then Docker, deployment, and workflow managers, etc. Then I moved onto other frameworks like Svelte. I’m not a true developer, still an analyst, so I’m still not super knowledgeable about development, but I found that for me at least learning software development was more about abstraction and planning than just writing code to solve problems. Understanding how services worked and interacted together help me out heaps. Then the more I built everyday, the more familiar I became with development. I guess also knowing I don’t have a true dev background takes the pressure off to be “good” at it and just have fun with it and make mistakes.
LeetCode monkey dance is like playing fast rounds of chess for spinal surgeon interview. It's good if you win most of them in general, but why not test skills that will be actually used during spinal surgery.
Back in the 1990's I had one very cool hiring test.
It started with abstract symbols, then it got more and complex basically building a programming language.
It was a test to see if you as a developer could learn new things fast you never saw before.
i do leetcode for fun to take a break from usual SWE tasks, and tbh I must say the platform itself I quite like. It's the culture, like you mentioned, which is the issue
I had the best job ever! It was kind of a niche. I was programming in Groovy; a language none of my colleagues new about and it required fluent English which I also am. The coding problem I was given was a homework exercise. No timing. No stress. It also was written in such a way that the concepts in the problem were ones I would be seeing on the job. I have worked there for 3 whole years, but my contract ended a month ago. Now, I am back looking for a "normal" job in software development and needing to solve these leetcode problems as fast as possible!
Thank you! I'm so sick of this. Meta was the worst genuinely recommended I read "Cracking the Coding Interview" (an over 600 page leetcode style book) twice. Apple was somewhat similar though it felt more off the cuff.
As someone who plans interviews I give candidates problems that look like the ones we actually solve on a day to day basis, and ramp up the ambiguity with seniority. (That said, on my latest job hunt I've seen companies who do it even better and might be stealing techniques from them in the future).
This is how the sys/net admin for Microsoft/Cisco exams (used to) work(s).
I hope they finally fixed those
I've been a software developer/engineer for close to 20 years and now I am currently in a FAANG company and I can tell you that such trivia questions are rarely what you will be doing on a day to day basis. The more important skill is the problem solving. You know.. The VERY THING Leet code is trying to determine. Being able to collaborate, think and talk through problems is way more important. Efficiently writing and communicating ideas is also a really useful skill.
That said, doing leet code to build your Datastructures and Algorithms knowledge is definitely helpful. But we are way past that point with the current Leet Code culture between companies and interviewees
Based on my own experience, my upset part of the current status is that huge amount of ex-faang ppl are typically weak, comparing to last decade. They used to be the strongest of strongest, a lot of my CS heroes were mostly work in faang during the 05 - 14/15ish era.
Also, huge amount of leetcode people appear to have no interests in computer science other a pay check, which is fine. But there must be a balance, I just felt like it could hurt the entire industry in a long term.
Many people from SF just keep talking about leetcode, salary and stock options, many got pissed off when you said something CS (except leetcode) outside of the job.
I don't know the solution, I also think people should have a simple understand of the runtime of your code in Big O.
They don't really appear to understand the fundamental data structure other than apply them into the leetcode.
Are you saying that people who don't know how to use a for loop learn enough loops by heart to pass an interview but not enough to actually solve problems and explain why they do things the way they do?
I didn't know LeetCode at all and in an interview I was asked three questions by the platform. They weren't really difficult and in the end it's fun to solve such tasks. I think that's exactly what the companies want to find out, i.e. whether you enjoy it and how you approach such tasks. They don't want people to practice up and down a platform like this. I'm sorry, every developer should be able to solve the simple to intermediate tasks without having to practise.
As an engineering manager, I don’t use Leetcode questions. I use questions that show me someone knows how to deal with the kind of issues they’ll run into in day to day work.
That said, I can’t just interview everyone, so I like automated coding tests as an initial filter, and those often do involve some DS&A.
I don’t recommend the memorization route. Instead, learn strategies and patterns that can be used for a variety of problems.
I haven't done a lot of Leet Code. But I sure enjoyed coming up with a true O(N) solution of the random array shuffle problem.
But in general I'm the one doing interviews, not the other way around. I don't use leet code because I think it's most important in an interview to find out what strengths the candidate DOES have, rather than discover the ones the candidate doesn't.
So finding ways to make them shine is the true art of interviewing. Then, if those skills match what you're needing or are generally impressive enough, you hire them.
But it's hard to come up with a problem that illustrates if the developer can do the job. I have used a simple problem like "show me a loop that adds up all numbers from 1 to 10" to see if they can do trivial programming.
Just a technical question: why has this video only 360p in the video quality list?
Happens when you watch any video as soon as it's released. It has more options for quality now.
I have become a game dev with Unreal Engine (mostly) and Unity, knowing now all the madness of cpp and c#. I wouldn't say I am super good at it, but I can feel the experience. I just don't care about problems because with enough time they all solvable and with experience it gets easy. St this point I am finding that all those "algorithms" are just OOP bandages. Everything is easier with ECS, but you'll need a battle tested ECS framework compatible with target language.
I assume that most software engineers will have a related college degree in CS, CE, etc. Won't they have already learned the algo's and data structures in their college courses?
Interviewers need to stop being lazy and create their own role specific coding questions. Your subject domain probably has some problem in it that requires data structures and/or algorithms. Derive a question from that. If your domain doesn’t have anything remotely complicated then why are you asking leet code questions in the first place?
I just enjoy the puzzles and making them performant after; but it is a tiny amount of time during my week
Leetcode aslso assumes that their tests are canoical. For example, for some of the problems, you can solve them using floating points or you can solve them using integers. Of course, if you solve those problems using integers you will get exact solutions, but if you solve them using floating points you may have answers that are off by a little. Leet code assumes that you are using floating points, so if you are off by the same amount, then it is ok - if you solve it using integers operations some of the test cases will fail.
If I ever make an algorithm at work that does anything abstract it’s mainly my own doing. Most jobs at work just require going through large amounts of info and grooming it, or making a front end for data entry
I think it's the greatest thing that ever happened. You can learn skills that are easy. This is tough. And demonstrate problem solving skills so company can switch between technologies and projects and know that you will be able to learn and adapt since you have excellent problem solving skills. It differentiates between a good and a bad coder. If you don't need leetcode, than you don't need to go in bug tech, start you own start up then.
Especially in India where there are millions of jobless leetcode gives a fixed clear path and syllabus for a job which is more easily accessible to people than to go to a path where you have to learn ever changing technologies always wonder if this is the right thing to do. Leetcode opens up the job market more than learning 100 skills since each company has different requirements. But if all of them have DSA, that's better.
Agree, i think i smell skill issue in the video
Does memorising leetcode solutions give you good problem solving skills?
Leetcode is only for interviews it's not the actual job. Need to start looking at how to interview people for the job.
Leetcode is also not good for interviews. The only thing a leetcode interview will show is if the candidate memorized / grinded leetcode. It doesn’t say anything else about other skills which are usually more important. Therefore I think it has zero value.
@@mudi2000a this
So many good devs who apply based on the ACTUAL JOB REQUIREMENTS are being passed because they can't do coding puzzles? Maybe they should ask questions about how/what/why you dev in vs can you solve this puzzle to get a job, I don't actually know that you can do your daily job but at least you memorised LeetCode to get a job, now will you be replaced after 6 months coz you don't know how to dev in our tech stack?
The biggest markers of success for most of the types of corporate engineering jobs out there have less to do with accumulated knowledge in a specific domain, and more to do with being resourceful and having the ability learn quickly and produce results when working with unfamiliar tools/tech stacks/code bases while also facing a deadline.
The thing is even in Hungary, many small companies and scaleups are doing Leetcode style interview, which you would say that doesn't make any sense.
They are not FAANG, they are small and cheap attitude companies and they still do it.
FAANG started it
This highlights the difference between a "coder" and a "developer"/Engineer! When I was responsible for hiring developers/Engineers I wanted to see how the candidates approached the problem, first. If they just jumped directly into coding, I would stop them and ask them to explain their analysis of the problem first. If they couldn't it was a hard pass.
As a fullstack engineer at a fortune 500 company, I can confidently say that my day to day work pretty much NEVER involves writing algorithms or solving Leetcode-style problems. My experience has been much more geared towards interfacing with APIs, processing real-world data, and managing deployments in complex microservice ecosystems.
Leetcode doesn't do a good job of teaching programmers practical skills, in my opinion.
I haven't done a huge amount of these types of problems, probably a few dozen or maybe a hundred across various types of lessons and exercises I've done. I have done more maths exercises in my life and much more chess puzzles. As I understand it these types of problems have the following didactic purpose, in descending order of importance.
1. Help understand concepts. Hearing about a tree, or a hashmap is one thing, but implementing it is different. It's possible to think you understand without really understanding, but after you solve a few representative problems you know you at least understand it well enough. Or if you get stuck you know you have some work to do.
2. Help internalize concepts. This is especially important if these concepts are later going to be a small part of a larger picture. If there is one or two elements of the larger picture that give you pause, you can still piece it together, but it shouldn't be too many. The datastructure and algorithmic side is one side that might give you pause, and if it doesn't you are one step ahead. It will probably be easier to spar with stakeholders if you can quickly think about solutions in your head and that's easier if you've solved some similar problems before.
3. Speed. The first benefit of speed is that you can solve a problem faster, and the second and underrated benefit is that you can explore more options if you can code your options quickly.
I have limited sympathy for the idea that leetcode problems abstract away many factors of real life coding. That's sort of the point. You focus on one part of it, to teach yourself that precise part. This only becomes a problem if little practice problems become the only type of study you do. People who know how to learn will supplement this with theoretical reading or viewing that the exercises are hopefully paired with, and with bigger personal projects (coding your own apps for practice, for example), studying important tools, design patters and so on.
Unfortunately a lot of people study these problems for a fourth reason: to do well on important tests. Job interviews in this case. Studying for a test is usually not didactically sound. In this case it leads to internalizing concepts beyond any need and memorizing problems instead of understanding the concepts.
The worst part is people just copy-pasting the solution
I don't code any more - moved to management roles. When I did I only ever got one coding test in an interview. It was to sort a list of words - I was 8 years into my career by this point, so I racked my brain and implemented Bubble Sort.
But, in reality - pretty much any sorting that I did in real life was already in a database - so my 'real world answer' was select * from customer sort by last name ( or whatever ).
I got the job, and it turned out to be pretty good. Although, funnily enough the code base I was given to work on was a complete disaster.
I feel sorry for people younger than me needing to go through a grind like this and need to rote learn - part of the joy of software engineering is solving different problems and not needing to rote learn.
Swe in the past are master of DSA because that’s how they optimized our computers to work under constraints. From making an OS, designing underlying architecture like cache, instructions scheduling. Now we only have to solve a couple of puzzle problems and we are complaining?
Funny, I remember back in the day, shortly after Java had been invented and had quickly become the buzzword de jour, going to a job fair and coming across HR staff looking for developers with a minimum of 5 years Java experience. I always wondered if the ones in charge of or doing the hiring had to take any tests.
There's also the classic story of the guy who invented a certain framework being rejected for a job for not having more years of experience in that framework than it had existed.
@@dekalb Yes, that was the case at the job fair I spoke of. Those people were seemingly oblivious to the fact the language had just recently been invented.
Leetcode is a good way to get better at a programming language and writing efficient code snippets. If you do a few questions each week you can get pretty good.
Leetcode is devoid of real context. As you mentioned, how will I get the input? Where does the output go? Who will be using the output? What is the business value of the output? Are there downstream rules on the use of the output? I've had coworkers (management) that don't understand the business needs completely, suggest solutions to things that when I mention business requirements, destroys the entire suggestions. "We don't need a telepathic interface because it's against company policy to use telepathy." But a leetcoder would already be deep into the code.
To make it short, most programming tasks revolve around either being able to reduce real world problems into puzzles to be solved with programming, or communicating with a team of people working on a very large puzzle and making sure your solution is collaborative with those of others.
Hiring the puzzle solving savants won't necessarily make for a functional programming department.
My typical workday contains three questions:
1) What's actually is our problem?
2) Can we fix it?
3) Should we fix it?
Fixing anything has often a ton of side effects that you need to consider. So you need to communicate A LOT with stakeholders.
Question and Answer riddles like these are unrealistic, because in reality you don't even have the question.
During my 15 years of experience, I noticed there are two types of coders: the ones who actually start to code right away getting to the solution by failing and modifying and the others who think about the problem in their head, ask questions, find the solution and code afterwards.
So for the first kind, I can see leetcode interview working fine. For the other kind, it must be a real pain indeed.
My last tech interview was back in '16. I don't think I'd pass the new interview formats now. Yikes!
Leetcode is basically a puzzle site to me that I do for fun.
What I do as an employer testing candidates is ask them to show me code they did outside of the interview setting, as private project, open source contribution or something else they did on their own, in a language of their choosing.
I look at the code and I ask questions, why did you do this like that, what happens if this function is called concurrently, stuff like that.
My day working with coders is reviewing their code and asking for clarification and improvements, so that’s what I do in an interview.
The moral being: if you create a benchmark (eg how fast can solve leetcode problems) the benchmark becomes the goal. But software development is team work, the most important thing is to communicate about code and understand each other. If you can do that, everything else is easy to learn.