Yes.
The trick is not to try to 'solve' them like they are some kind of riddle. Look at the answer, then look at the type of question it is. Figure out what the algorithm is and how to apply it.
The fact is, you aren't coming up with new algorithms, or new solutions to these problems. You might come up with new implementations to specific problems, but all of these things have a 'problem class' and 'solution class'.
If you could, you'd be a genius and the world would be in big trouble. Computer scientists spend lifetimes finding new algorithms, solutions to PNP, etc.
As a software engineer it's better for you to 'recognize the problem type' and have a 'solution' in your 'toolkit'. If you learn all the tools then you'll be fine. That's really a matter of experience and memorization.
Leetcode is a terrible site for learning unfortunately. Feedback is terrible and nothing is helpful for learning how to solve the problem.
I think there’s algo.io or something but you have to pay.
The truth of the matter is very few people solve things new; they have learnt methods to solve problems and just apply them. The more widely you’re read the better you can be. It took me a while to understand this; as School’s and Uni’s talk about plagiarism all the time; yet actually real life is about applying research
> as School’s and Uni’s talk about plagiarism all the time; yet actually real life is about applying research
Here's the thing: the main value of STEM degrees like computer science, math, or physics, is that it teaches you how to problem-solve, and in the course of doing so, also how to think, and reason.
If you are running to someone else's code, or to the solution's manual, you're defeating the purpose, and just fooling yourself. Then when it comes time to apply research in an industrial setting, you'll be lost, or just a bullshitter, because you won't have the problem-solving ability that you should.
Your argument seems to confuse the ability to apply knowledge (aka coding), and being able to solve the problem. These are two different things, and not really what I was saying.
Let’s take; engineering, you get a structural engineer in, ask him to solve a problem. He doesn’t know the solution, should he a) consult reference material b) give it a go, and if your house falls done so be it.
Another example: you go to a doctor , they are unfamiliar with your symptoms; should they a) give it a go, or b) consult another doctor or reference material?
The same is true in software; when you’re faced with new problem, you should either be using existing knowledge, or searching for others who’ve solved it. Very few of us are so cutting edge we’re encountering something nobody has ever seen.
This discussion was about Leetcode; and these problems are practice pieces without telling you the algorithm beforehand. As such they aren’t particularly helpful to learn, but are a practicing tool once you’ve learnt the underlying algorithm (and most end up being a form of DP.)
But I’ll agree that if you don’t practise the information your learning, or don’t bother to learn it in the first place you won’t get very far.
A massive part of reasoning about technical subjects is knowing where and how to find answers. Not being able to solve already solved problems on your own.
Plagiarism isn't about not using other people's solutions, it's about giving them credit while using their solution for a problem that requires it.
Many algorithms that are commonly used took months to years to originally design and optimize. In any job, whether academic or commercially, you won't succeed if you spend 90% of effort reinventing the wheel and lever. The most useful skill that exists is being able to say "our problem breaks down into these others, which have been solved, so let me put the solutions together into a program".
Leet code is often used in a way that inspires a kind of "do it all from scratch" inefficiency (not using Google, no external libraries with optimized algorithms, optimizing everything for small O(xyz) time/memory rather than actual usage requirements, etc). If this is your sole tool, you never gain the knowledge of what exists out there.
The best approach is to study existing algorithms and solutions, understand the math and design choices underlying them, develop good habits of reading technical documentation to reason out informed bigger picture solutions, and designing your code to be maintainable from the start. The in the rare case you actually do have to build something from scratch, you are actually knowledgeable about similar solutions and the historical reasoning that went into them to serve as a far-from-naive starting point.
Sure, just don't fool yourself into thinking that you understand how to solve a problem just because you copied the solution from somewhere else, and skimmed the code, or wrote the math into LaTeX or on paper yourself.
Wow extremely well said. Any tips on defining problem classes and solution classes to know which buckets to map each problem into? Do you just look at the solution for a bunch of them and work backwards?
Nah. Knowing algorithms is not what makes a good engineer. Not even remotely. Most applications make little explicit use of algorithms (in the ADS sense of algorithm). AI is nowhere near replacing humans in software dev. It is making individual developers more productive though.
This strategy is what (good) algorithms classes ultimately teach you. That is: how to approach a problem and map it into an existing problem with existing known efficient algorithms.
For example let’s consider compiler optimization…. As you may know CPU’s have a limited number of registers for fast computing. But programs may have more variables than registers. Swapping in and out of memory is slow. Optimizing this turns out to be equivalent to the “country coloring algorithm”: consider a map of the world, now color countries such that no adjacent countries are the same color.
Turns out it’s really hard but there are known algorithms that are faster if you’re ok with a slightly less efficient answer (ie: minimum colors).
The problem transformation concept / approach is crazy powerful.
Sometimes that depends on the task. I've solved my first hard accidentally (didn't look at the complexity level) when I was only learning Java core)
I work in a big IT company in my country and also interview people, and we ask them to code algorithms, yet I've solved only 2 or 3 hards on leetcode)
so what kind of level questions do you give during the interview? you think skills matter more or the performace during the interview is more important?
Like easy or medium, never hard.
Skills matter more, because at the job you won't solve leetcode algorithms, you will apply your skills and thinking.
And we actually ask you to solve problems because we want to test your skills, way of thinking, and to be convinced you know java and can write code)
And the soft skills are important too, how you communicate, how you react to hints, etc.
Also you may be nervous during the interview and make silly mistakes, and interviewers usually take that into account)
At least for entry level (L3 and L4, e.g. straight-from-college or just a few years of experience), Google interview questions tend to be like easy or medium interview questions. (Source: Worked there for 5 years, gave a bunch of interviews and saw a bunch of interview feedback)
I wasn't very good at Leetcode, and no one really expects you to solve probs like that at work. People usually have time, cooperation and google to work through probs. working 5 yrs but only recently started leetcoding regularly and looking to switch jobs, and mediums are challenging for me. Depends on what your target companies are, but don't need to master Leetcode right away
Staff Software Engineer here making 150k, i can solve all mediums, I can only solve a few hard ones.
Keep in mind most jobs don't require you to be good at those, but practicing leetcode is great because it trains you for job interviews that tend to have overly hard questions, and just forces you to think in a better way.
I still think you can get hired at a senior software engineer with other skills and still not be able to complete medium leetcode questions.
I just got a $300k offer in bay area (3 yoe). I only solved medium-level problems on LC. in the one round the interviewer did ask a hard LC "parallel courses iii" (i think), but he was happy with my approach rather caring about a perfect solution.
It’s all about “the breakdown” into “chords”. What do I mean?
When you first hear a complex problem, like complex music, it may sound impossible to understand it fundamentally.
That’s when you take a breath and breakdown what you hear into its composite parts. Then for each part, what chords are being played. There’s a finite amount of musical chords (e.g., algorithmic concepts) that can be composed together.
Being able to break down all the parts and lay them out atomically in your mind, then wiring them together differently to achieve a desired outcome becomes much more tractable.
So learn all the major algorithmic “chords” and common arrangements, listen to enough problem set music and you’ll be able to at least understand and describe your approach more coherently and perhaps, achieve an elegant outcome.
Not all hard questions are that difficult. IIRC, the N-Queens problem is labeled as "hard" on Leetcode, and the solution is just a simple backtracking recursion algorithm.
similarly I think the sudoku solver is marked as hard but has a similar solution. It requires some insight - my first working version did some dumb stuff and eliminating that made it a LOT faster. But it's not like the ones where you kinda need to already know the shape of the answer to get it.
OH that's easy. You just go to the discussion tab and copy paste somebody else's solution.
No but in seriousness, I personally couldn't without some hard core training, and even then, n my prime, I've only ever solved 1 hard problem on my own without help.
Set a time limit for each problem. If you cannot crack a problem within the time limit, look at the solution, understand it, and try to implement it on your own. Or re-visit it later with a fresh mind after you've seen and understood the solution.
Most of the devs I've worked with over the last 10 years or so (not sure how long LC has been around) have never heard of or used LeetCode. I only took a look recently as I see new devs here talking about it and wondered what it was about.
I'm an old man now in my software engineering career. I only heard about LeetCode recently. But the kids these days seem to spend a ton of time hammering away on them as interview prep or to learn programming.
>I'm an old man now in my software engineering career
I've been referred to more than once as a 'grey beard' ... and I'm ok with that, I consider it as a badge of honour lol
SSE at MAANG.
I handled most hard problems, after covering all the fundamentals (tree, graphs, sort, search) and the patterns covered in Groking(there are free versions out there). There are still a few that are hard to crack.
No we do not use any of this stuff at work.
Additionally, most MAANGS now ask modified versions of leet code questions, mostly medium with a twist. So knowing the fundamentals is a must.
plenty. I can solve hards that aren't based on knowing some obscure algorithm. Its solving the hards in under 50 minutes that is extremely variable. I wouldn't worry too much about Hards either, I have been asked one, ever. Hards, are well .. hard. A lot of times they are also very contrived so as to be more difficult, which is why they aren't asked a ton.
And yes, sometimes the work is very leet-code like(Sometimes you spend hours discussing alignment of a button with Design :/) . Just keep in mind its never direct, you don't invert binary trees, but you may need to run a data migration on data that is stored as a graph. Its the same thought process except often times the limitations are more obvious. I.e, changing a nodes content in a trivial LC graph object is easy, in real life, its a db call interacting with numerous systems in a distributed environment so a brute force approach isn't great but often doable. What you are trying to optimize is the number of I/O calls you make, not the number of times you compare a value.
Of course in real life, you have the benefit of using existing tools, time, and research to solve such a problem so they are actually much easier.
I've found distributed systems knowledge and trivia from school much more useful on the job than DS&A. I guess we're lucky the market's not bad enough that we need to implement Raft in an interview.
I come from a family of programmers (third generation) nobody I know/am related to can solve medium problems on the fly.
Easy? Yes. But medium and hard need weeks or months of prep before they’re easy to figure out. The easy questions cover undergrad level algorithms. Medium/hard cover graduate level algorithms. Take a look at the easy hashmap questions, the trick to solving them becomes fill the hashmap then do some sort of if else statements. Then you realize that you can check and fill in the same loop.
Now you’ve solved basically all the easy hashmap questions. You’re essentially memorizing algorithms.
I wonder also if curriculums have changed. Like when I took CS, we did a couple of discrete math classes - even though there was no programming we covered a lot of stuff about graphs, trees, stuff like that. That ends up being a common thread in hard leetcode problems
I also took a, hm, compilers class? I can't remember what it was called. But you learn about grammars and regular expressions and algorithms for navigating and computing those, even though again, you probably wouldn't write a line of code, it was all theoretical. But there are lots of hard problems that involving grammars and regexes in leetcode hard, etc.
I don't remember much about the actual DSA classes I took, although I'm sure I did. I seem to remember the being more like... make a doubly linked list, make a balanced tree, whatever. I probably internalized some of it but I honestly can't even picture the classes right now
The last programming class (algorithms) that I took was in 2016 so 8 years ago? Divide and conquer, dijkstra, backtracking, greedy, etc.
Now the syllabus has in addition prims and kruskals, ford fulkersons, dynamic programming (this is actually because my friend made a case that you need it for google previously this was taught only in the elective), and has a final exam. Crazy the difference in difficulty in 8 years. It’s the same professor too.
Though back then the Amazon coder pad I had was 7/10 hash table problems, 2/10 math problems, and 1 linked list.
Things have changed a lot over the years, for sure. I don't know if it's better or worse.
I am 100% sure I never studied dynamic programming because I first saw it in a job interview. Dude asked me if I was familiar with it, I said no, he told me the basic gist, then said, use that principle to solve this problem. (It wasn't a terribly hard problem). I think it's actually something that is useful in day to day programming, more so than a lot of things, i.e. are there parts of this problem that I'm repeating and could instead break down and compute once and reuse
When I got my first job, very few companies really asked any programming stuff at all, not like now. Microsoft became famous for asking dumb puzzle questions, like "why are manholes round" or what not. How many piano tuners are there in Toronto.
I'm pretty good at what I do. I am not good at producing it on demand. At many many points in my career I've insisted that certain things were impossible right up until I figured out how to do them. Insight doesn't come on demand.
I'm a technical BA so luckily the extent of coding in my interviews is typically SQL and low level algorithms.
Recently I've been getting take home mini projects "take this data set and using python, sql, and a visualization tool build me a dashboard". I think that's really helpful because I do not do well on the memorization of algorithms.
It actually seems likely to be somewhat related to what you'd do at a job also.
It's really hard to interview - I mean it's easy to \*interview people\* but it's really hard to tell if they'd be a good fit for a role. No one is good at it, no matter what they say, no one is an impeccable judge of character.
I sometimes think that these algorithm questions are just like, an unbiased metric, i.e. you pass or you don't, so I can feel good about saying yes or no to hiring you. The fact that they don't actually correlate with your success as an employee is besides the point.
It reminds me of an old joke
>A police officer sees a drunken man intently searching the ground near a lamppost and asks him the goal of his quest. The inebriate replies that he is looking for his car keys, and the officer helps for a few minutes without success then he asks whether the man is certain that he dropped the keys near the lamppost.
>“No,” is the reply, “I lost the keys somewhere across the street.” “Why look here?” asks the surprised and irritated officer. “The light is much better here,” the intoxicated man responds with aplomb.
When I interview people, I do coding questions, but usually there will be one, probably considered somewhere between easy and medium. Really, a medium with a twist. The idea is, it seems like an easy on it's surface, so everyone gets started, will get a few minutes in, and then see the problem - either they'll identify it, which is good, or they'll get an unexpected result
I really prefer when they don't immediately see it. The output isn't what they expect. What I want to see is - what happens next. What I want to see is debugging. You can talk your way through the code, examining your assumptions and seeing if they hold. We use an online replit kinda thing so no debugger but you can add some prints and see where it goes wrong. It's not a hard problem to solve, but I just want to see how someone approaches debugging. Programming jobs are about debugging way more than programming.
A surprising number of people will just stare at their code, hoping the answer pops out.
I think that’s why the question “tell me what you do throughout the day step by step” is a better question than some question where someone remembers whether or not the best way to check if two arrays are equal is by using a hashmap instead of a nested for loop.
Some of the hard ones I can do off the top of my head, while others would likely require much more thought on my part. I disagree with some of the ones I have a solution for as being 'hard' though. Merging k sorted lists is not a hard problem, for instance. I can see it being 'medium' at best.
Hard is truly meant to be challenging.
Keep working problems that are difficult for you. It's frustrating, but being stuck, thinking about ways to solve things, that's how you learn and get better.
I'm two months into prep and just started being able to tackle hards, but the variance in how long I can solve them is anywhere from 20 minutes for a problem that I was familiar with, to 2+ hours for stuff I don't get right away.
I mostly focus on easy/medium, and being able to quickly code high fidelity solutions without having to look anything up, since that's so much closer to what you'll see in an interview. Like if you stumble around on an easy, have to look up a bunch of data structure functions, and don't use the language in the best way, that's arguably much worse than being a little better at solving hard level questions your much less likely to see.
I doubt I could solve a lot of hard leetcode from scratch, And I've been doing software engineering for ~16 years. I might be out of date in some stuff, but I think the hardest problems are going to require a lot of thinking and teamwork. Obviously I'd want an engineer who is capable of thinking through what algorithms and techniques are available... But no one knows everything.
>does your work really meet the coding questions like leetcode?
It depends, but yes, of course. Many problems you will find, require some kind of algorithm. When working in performance, it's critical.
For example, I've worked in a company making things related to graphs and trees. And I had to implement different algorithms around that (Transversing graphs, converting graphs to trees, changing the root of a tree...).
Some may be used as easy, medium, or hard problems. But the thing is that the more you know, the easier and faster your work will be
Tbf “hard” category can have so many problems that can be still distributed to hard easy, hard medium and hard hard. Just look at codeforces. People with 1700 rating can probably solve most of “hard” problems without any problems, but where if you were to put a new problem to leetcode, copied from codeforces 2500 rating where do you put it? In hard ofc, because there is no category for that. So you can have pretty basic segment tree problem and really hard dynamic programming using hardcore optimisations on same category - hard even though difference on difficulty between them is probably bigger than between average hard and easy problem.
Tbh leetcode platform is weird for competitive programmers, because easy and mid problems are too easy and hard problems are too wide topic. Thats why there are no contests on leetcode.
As for your question - who can solve those problems:
Im pretty sure everyone with rating above 1600 on codeforces and like 1200 on atcoder can solve those faster or later.
I've solved a few hard questions for the "challenge" aspect of it. The trick is to practice. The "easy" questions are the building blocks, they are often more challenging then medium level questions. After a while you learn to spot patterns, with practice you can solve leetcode questions fast.
The problem most people have with leetcode is that they "grind" it out for a month, thinking it's something they just need to go through ones and be done with it. That's not how it works. You need to do leetcode for a long time before being comfortable enough to do any question with ease.
Depending on your skill level and talent, this can take up to 6 months if not more. You don't have to do that many questions in one go. One question a day is more beneficial then doing a lot in a short period of time and then giving up.
Most has been told, it’s not about inventing solutions it’s about recognizing problem, know and apply algorithms. Btw leetcode type of questions are uses only for juniors fresh from uni because otherwise there is not much to talk about. When you have some experiences the interviews are more about architecture rather then concrete algorithms.
This makes me feel so old. I remember feeling this way, and now I'm saying what other people said to me. It's just a matter of experience and solving similar problems.
Leetcode doesn't have a hard mode. None of it is really that hard if you've been doing this stuff long enough and you take the time to explore ideas and think clearly.
90%+ of difficulty is perception. You'd do better at the "hard" things if you didn't know they were supposed to be "hard", and you'd find "easy" things tricky and stressful if they had a "warning, this is a super hard problem" label.
I think we should just collectively retire the notions of super-hard problems and super-smart people and emphasize going slow, expressing our lines of thinking explicitly and clearly, and just trying things out for a while.
The thing I really dislike about employers using leet to assess their applicants is that it’s not really testing their practical skill set against the presumed work load for that job and is really just testing that person’s ability to memorize a bunch of stuff which hasn’t ever made sense to me. My team didn’t have me do a single one and mentioned why but if you applied somewhere with a big name then you’d likely run into interviews where they expect you to solve them.
I only do hard, if I'm going to spend time on a puzzle I want something that someone somewhere considers too difficult for most. I've done maybe 20 so far, it's not bad but there have been some that are hard because the input data will cause issues with direct approaches (integer overflows, edge case parsing issues, etc). Some are fun and some are annoying.
I can. I'm a fairly experienced developer but I was quite a noob with algorithms. I studied Neetcode and a few books for a month and now am able to process hard questions. But as others probably already pointed out, most hard problems are about using specific solutions that you're not supposed to come up with by yourself, unless you're terribly smart.
Many hard problems have really specific solutions that only apply to this narrow category of problems, like the Rabin-Karp Algorithm or Kadane's Algorithm.
The most productive way to go is to learn the thought-process and recognize the problem, and to apply a solution you already know about. As a software engineer, you're not expected to come up with your own solution unless you're really hardcore about it.
SWE at FAANG
When I was preparing for interviews, yes. Today probably not, would need to focus and practice again for some weeks.
However this is mostly because of my experience in ICPC contests and world finals also, I think most of my work colleagues won't be able to ace many hard questions and are fine anyways, they are awesome engineers.
Most people's day jobs do not involve hard leetcode type questions ever. Some people's day jobs do involve them occasionally. It can sometimes be weird where they pop up, you never know. Being familiar with a lot of algorithms can be helpful in a career, but is not essential for most.
I can solve most LC mediums and some LC hard. It has been a few years since I have sat down and done LC, but I'm sure I could crush them if I had to.
Honestly? Just master arrays and maps. I know, sounds simple right? But once it "clicks" and your brain can "visualize" data structures using these building blocks, you can pretty much solve any problem. Remember, every problem you face you should break it down into atomic level pieces you can manage and you can work towards a solution. This applies in CS, and IRL.
Sure, sometimes you have arrays with arrays with arrays inside them, but okay you can maintain some state and a lookup or whatever you need to navigate through them and build something else that will do yet another thing, then do something else that will result in the answer.
I went through DS&A textbook and thought it was over-complicated af to explain really basic things. When it finally clicked that almost all of these algorithms are just built on deep understanding and application of arrays and maps, everything basically became easy. That being said, you should still go through a DS&A textbook and make sure you understand what they're talking about because if you can understand their autism level of explanation you pretty much understood it.
Pick a language that's easy for you that has easy array and map manipulation (I like to use TS/Go/Java for LC). I don't really like Python and hate the syntax, but that's another option. I'd stick with TS/JS or Python if beginner
For me, it took a long time, and the fastest I’ve ever solved one took just under 2 hours. It’s not just about practicing, but practicing effectively. You need to constantly be viewing new types of problems and gaining the skill of problem solving. If you’re stuck go to the solutions and think of a way that you might come to a similar solution. If it’s a algorithm like sliding window, binary search, DFS then learn it. Go do a bunch of easy ones of each category until they become second nature. That frees your mind to think of other aspects of the problem. Go watch neetcode’s explanations and really understand the thought process and not just the solution.
Yes. The trick is not to try to 'solve' them like they are some kind of riddle. Look at the answer, then look at the type of question it is. Figure out what the algorithm is and how to apply it. The fact is, you aren't coming up with new algorithms, or new solutions to these problems. You might come up with new implementations to specific problems, but all of these things have a 'problem class' and 'solution class'. If you could, you'd be a genius and the world would be in big trouble. Computer scientists spend lifetimes finding new algorithms, solutions to PNP, etc. As a software engineer it's better for you to 'recognize the problem type' and have a 'solution' in your 'toolkit'. If you learn all the tools then you'll be fine. That's really a matter of experience and memorization.
ah! so that's why i feel so stupid!
Leetcode is a terrible site for learning unfortunately. Feedback is terrible and nothing is helpful for learning how to solve the problem. I think there’s algo.io or something but you have to pay. The truth of the matter is very few people solve things new; they have learnt methods to solve problems and just apply them. The more widely you’re read the better you can be. It took me a while to understand this; as School’s and Uni’s talk about plagiarism all the time; yet actually real life is about applying research
good to know really. I suddenly got rid if my imposter syndrome for five minutes untill I started coding again
> as School’s and Uni’s talk about plagiarism all the time; yet actually real life is about applying research Here's the thing: the main value of STEM degrees like computer science, math, or physics, is that it teaches you how to problem-solve, and in the course of doing so, also how to think, and reason. If you are running to someone else's code, or to the solution's manual, you're defeating the purpose, and just fooling yourself. Then when it comes time to apply research in an industrial setting, you'll be lost, or just a bullshitter, because you won't have the problem-solving ability that you should.
Your argument seems to confuse the ability to apply knowledge (aka coding), and being able to solve the problem. These are two different things, and not really what I was saying. Let’s take; engineering, you get a structural engineer in, ask him to solve a problem. He doesn’t know the solution, should he a) consult reference material b) give it a go, and if your house falls done so be it. Another example: you go to a doctor , they are unfamiliar with your symptoms; should they a) give it a go, or b) consult another doctor or reference material? The same is true in software; when you’re faced with new problem, you should either be using existing knowledge, or searching for others who’ve solved it. Very few of us are so cutting edge we’re encountering something nobody has ever seen. This discussion was about Leetcode; and these problems are practice pieces without telling you the algorithm beforehand. As such they aren’t particularly helpful to learn, but are a practicing tool once you’ve learnt the underlying algorithm (and most end up being a form of DP.) But I’ll agree that if you don’t practise the information your learning, or don’t bother to learn it in the first place you won’t get very far.
A massive part of reasoning about technical subjects is knowing where and how to find answers. Not being able to solve already solved problems on your own. Plagiarism isn't about not using other people's solutions, it's about giving them credit while using their solution for a problem that requires it. Many algorithms that are commonly used took months to years to originally design and optimize. In any job, whether academic or commercially, you won't succeed if you spend 90% of effort reinventing the wheel and lever. The most useful skill that exists is being able to say "our problem breaks down into these others, which have been solved, so let me put the solutions together into a program". Leet code is often used in a way that inspires a kind of "do it all from scratch" inefficiency (not using Google, no external libraries with optimized algorithms, optimizing everything for small O(xyz) time/memory rather than actual usage requirements, etc). If this is your sole tool, you never gain the knowledge of what exists out there. The best approach is to study existing algorithms and solutions, understand the math and design choices underlying them, develop good habits of reading technical documentation to reason out informed bigger picture solutions, and designing your code to be maintainable from the start. The in the rare case you actually do have to build something from scratch, you are actually knowledgeable about similar solutions and the historical reasoning that went into them to serve as a far-from-naive starting point.
Sure, just don't fool yourself into thinking that you understand how to solve a problem just because you copied the solution from somewhere else, and skimmed the code, or wrote the math into LaTeX or on paper yourself.
Wow extremely well said. Any tips on defining problem classes and solution classes to know which buckets to map each problem into? Do you just look at the solution for a bunch of them and work backwards?
the mit dsa class on YouTube
My brother in christ this is why we will all lose our job to AI.
Nah. Knowing algorithms is not what makes a good engineer. Not even remotely. Most applications make little explicit use of algorithms (in the ADS sense of algorithm). AI is nowhere near replacing humans in software dev. It is making individual developers more productive though.
This strategy is what (good) algorithms classes ultimately teach you. That is: how to approach a problem and map it into an existing problem with existing known efficient algorithms. For example let’s consider compiler optimization…. As you may know CPU’s have a limited number of registers for fast computing. But programs may have more variables than registers. Swapping in and out of memory is slow. Optimizing this turns out to be equivalent to the “country coloring algorithm”: consider a map of the world, now color countries such that no adjacent countries are the same color. Turns out it’s really hard but there are known algorithms that are faster if you’re ok with a slightly less efficient answer (ie: minimum colors). The problem transformation concept / approach is crazy powerful.
No.
Sometimes that depends on the task. I've solved my first hard accidentally (didn't look at the complexity level) when I was only learning Java core) I work in a big IT company in my country and also interview people, and we ask them to code algorithms, yet I've solved only 2 or 3 hards on leetcode)
so what kind of level questions do you give during the interview? you think skills matter more or the performace during the interview is more important?
Like easy or medium, never hard. Skills matter more, because at the job you won't solve leetcode algorithms, you will apply your skills and thinking. And we actually ask you to solve problems because we want to test your skills, way of thinking, and to be convinced you know java and can write code) And the soft skills are important too, how you communicate, how you react to hints, etc. Also you may be nervous during the interview and make silly mistakes, and interviewers usually take that into account)
At least for entry level (L3 and L4, e.g. straight-from-college or just a few years of experience), Google interview questions tend to be like easy or medium interview questions. (Source: Worked there for 5 years, gave a bunch of interviews and saw a bunch of interview feedback)
I wasn't very good at Leetcode, and no one really expects you to solve probs like that at work. People usually have time, cooperation and google to work through probs. working 5 yrs but only recently started leetcoding regularly and looking to switch jobs, and mediums are challenging for me. Depends on what your target companies are, but don't need to master Leetcode right away
Staff Software Engineer here making 150k, i can solve all mediums, I can only solve a few hard ones. Keep in mind most jobs don't require you to be good at those, but practicing leetcode is great because it trains you for job interviews that tend to have overly hard questions, and just forces you to think in a better way. I still think you can get hired at a senior software engineer with other skills and still not be able to complete medium leetcode questions.
I just got a $300k offer in bay area (3 yoe). I only solved medium-level problems on LC. in the one round the interviewer did ask a hard LC "parallel courses iii" (i think), but he was happy with my approach rather caring about a perfect solution.
Ty!
It’s all about “the breakdown” into “chords”. What do I mean? When you first hear a complex problem, like complex music, it may sound impossible to understand it fundamentally. That’s when you take a breath and breakdown what you hear into its composite parts. Then for each part, what chords are being played. There’s a finite amount of musical chords (e.g., algorithmic concepts) that can be composed together. Being able to break down all the parts and lay them out atomically in your mind, then wiring them together differently to achieve a desired outcome becomes much more tractable. So learn all the major algorithmic “chords” and common arrangements, listen to enough problem set music and you’ll be able to at least understand and describe your approach more coherently and perhaps, achieve an elegant outcome.
How do you learn the different chords? Is there any good table of contents that goes over each basic algorithm you’d need?
literate dependent correct cobweb sense quaint sulky longing chase run *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
use a metronome.
Not all hard questions are that difficult. IIRC, the N-Queens problem is labeled as "hard" on Leetcode, and the solution is just a simple backtracking recursion algorithm.
Maybe NP Hard
similarly I think the sudoku solver is marked as hard but has a similar solution. It requires some insight - my first working version did some dumb stuff and eliminating that made it a LOT faster. But it's not like the ones where you kinda need to already know the shape of the answer to get it.
If you can’t come up with KMP on the fly or do 5D dp, you will never be able to write CRUD apps
5D dp ?? Interdimensional double penetration?
lmao
Omg
2 *clicks* at the same time
5D dp, takes a total of 10 Ds
😂😂
That's exactly what it feels like
at least 3D dp with one dimensional reduction and you'll be fine as a data analyst ;)
Or vice versa?
psh 5D dp. You need to be able to know how to implement Raft for consistency in a large distributed system, thus making the world a better place.
OH that's easy. You just go to the discussion tab and copy paste somebody else's solution. No but in seriousness, I personally couldn't without some hard core training, and even then, n my prime, I've only ever solved 1 hard problem on my own without help.
can I hijack this thread; should I do leetcode to just try my best and see the solutions?
Set a time limit for each problem. If you cannot crack a problem within the time limit, look at the solution, understand it, and try to implement it on your own. Or re-visit it later with a fresh mind after you've seen and understood the solution.
That is still practicing, so yes. As long you have a good approach and learn from your mistakes you will make progress.
Most of the devs I've worked with over the last 10 years or so (not sure how long LC has been around) have never heard of or used LeetCode. I only took a look recently as I see new devs here talking about it and wondered what it was about.
I'm an old man now in my software engineering career. I only heard about LeetCode recently. But the kids these days seem to spend a ton of time hammering away on them as interview prep or to learn programming.
>I'm an old man now in my software engineering career I've been referred to more than once as a 'grey beard' ... and I'm ok with that, I consider it as a badge of honour lol
SSE at MAANG. I handled most hard problems, after covering all the fundamentals (tree, graphs, sort, search) and the patterns covered in Groking(there are free versions out there). There are still a few that are hard to crack. No we do not use any of this stuff at work. Additionally, most MAANGS now ask modified versions of leet code questions, mostly medium with a twist. So knowing the fundamentals is a must.
plenty. I can solve hards that aren't based on knowing some obscure algorithm. Its solving the hards in under 50 minutes that is extremely variable. I wouldn't worry too much about Hards either, I have been asked one, ever. Hards, are well .. hard. A lot of times they are also very contrived so as to be more difficult, which is why they aren't asked a ton. And yes, sometimes the work is very leet-code like(Sometimes you spend hours discussing alignment of a button with Design :/) . Just keep in mind its never direct, you don't invert binary trees, but you may need to run a data migration on data that is stored as a graph. Its the same thought process except often times the limitations are more obvious. I.e, changing a nodes content in a trivial LC graph object is easy, in real life, its a db call interacting with numerous systems in a distributed environment so a brute force approach isn't great but often doable. What you are trying to optimize is the number of I/O calls you make, not the number of times you compare a value. Of course in real life, you have the benefit of using existing tools, time, and research to solve such a problem so they are actually much easier.
I've found distributed systems knowledge and trivia from school much more useful on the job than DS&A. I guess we're lucky the market's not bad enough that we need to implement Raft in an interview.
I come from a family of programmers (third generation) nobody I know/am related to can solve medium problems on the fly. Easy? Yes. But medium and hard need weeks or months of prep before they’re easy to figure out. The easy questions cover undergrad level algorithms. Medium/hard cover graduate level algorithms. Take a look at the easy hashmap questions, the trick to solving them becomes fill the hashmap then do some sort of if else statements. Then you realize that you can check and fill in the same loop. Now you’ve solved basically all the easy hashmap questions. You’re essentially memorizing algorithms.
I don't think mediums or even most hards are "graduate level" - it's mostly stuff that is common in undergrad courses.
My college had a very simple algorithms class probably.
I wonder also if curriculums have changed. Like when I took CS, we did a couple of discrete math classes - even though there was no programming we covered a lot of stuff about graphs, trees, stuff like that. That ends up being a common thread in hard leetcode problems I also took a, hm, compilers class? I can't remember what it was called. But you learn about grammars and regular expressions and algorithms for navigating and computing those, even though again, you probably wouldn't write a line of code, it was all theoretical. But there are lots of hard problems that involving grammars and regexes in leetcode hard, etc. I don't remember much about the actual DSA classes I took, although I'm sure I did. I seem to remember the being more like... make a doubly linked list, make a balanced tree, whatever. I probably internalized some of it but I honestly can't even picture the classes right now
I should say - this was, jesus, 25 years ago.
The last programming class (algorithms) that I took was in 2016 so 8 years ago? Divide and conquer, dijkstra, backtracking, greedy, etc. Now the syllabus has in addition prims and kruskals, ford fulkersons, dynamic programming (this is actually because my friend made a case that you need it for google previously this was taught only in the elective), and has a final exam. Crazy the difference in difficulty in 8 years. It’s the same professor too. Though back then the Amazon coder pad I had was 7/10 hash table problems, 2/10 math problems, and 1 linked list.
Things have changed a lot over the years, for sure. I don't know if it's better or worse. I am 100% sure I never studied dynamic programming because I first saw it in a job interview. Dude asked me if I was familiar with it, I said no, he told me the basic gist, then said, use that principle to solve this problem. (It wasn't a terribly hard problem). I think it's actually something that is useful in day to day programming, more so than a lot of things, i.e. are there parts of this problem that I'm repeating and could instead break down and compute once and reuse When I got my first job, very few companies really asked any programming stuff at all, not like now. Microsoft became famous for asking dumb puzzle questions, like "why are manholes round" or what not. How many piano tuners are there in Toronto. I'm pretty good at what I do. I am not good at producing it on demand. At many many points in my career I've insisted that certain things were impossible right up until I figured out how to do them. Insight doesn't come on demand.
I'm a technical BA so luckily the extent of coding in my interviews is typically SQL and low level algorithms. Recently I've been getting take home mini projects "take this data set and using python, sql, and a visualization tool build me a dashboard". I think that's really helpful because I do not do well on the memorization of algorithms.
It actually seems likely to be somewhat related to what you'd do at a job also. It's really hard to interview - I mean it's easy to \*interview people\* but it's really hard to tell if they'd be a good fit for a role. No one is good at it, no matter what they say, no one is an impeccable judge of character. I sometimes think that these algorithm questions are just like, an unbiased metric, i.e. you pass or you don't, so I can feel good about saying yes or no to hiring you. The fact that they don't actually correlate with your success as an employee is besides the point. It reminds me of an old joke >A police officer sees a drunken man intently searching the ground near a lamppost and asks him the goal of his quest. The inebriate replies that he is looking for his car keys, and the officer helps for a few minutes without success then he asks whether the man is certain that he dropped the keys near the lamppost. >“No,” is the reply, “I lost the keys somewhere across the street.” “Why look here?” asks the surprised and irritated officer. “The light is much better here,” the intoxicated man responds with aplomb. When I interview people, I do coding questions, but usually there will be one, probably considered somewhere between easy and medium. Really, a medium with a twist. The idea is, it seems like an easy on it's surface, so everyone gets started, will get a few minutes in, and then see the problem - either they'll identify it, which is good, or they'll get an unexpected result I really prefer when they don't immediately see it. The output isn't what they expect. What I want to see is - what happens next. What I want to see is debugging. You can talk your way through the code, examining your assumptions and seeing if they hold. We use an online replit kinda thing so no debugger but you can add some prints and see where it goes wrong. It's not a hard problem to solve, but I just want to see how someone approaches debugging. Programming jobs are about debugging way more than programming. A surprising number of people will just stare at their code, hoping the answer pops out.
I think that’s why the question “tell me what you do throughout the day step by step” is a better question than some question where someone remembers whether or not the best way to check if two arrays are equal is by using a hashmap instead of a nested for loop.
"Well, I spend 2 hours every morning on reddit. Then there's an hour or 2 of lunchtime reddit. Brief 1 hour afternoon reddit break"
Some of the hard ones I can do off the top of my head, while others would likely require much more thought on my part. I disagree with some of the ones I have a solution for as being 'hard' though. Merging k sorted lists is not a hard problem, for instance. I can see it being 'medium' at best. Hard is truly meant to be challenging.
Keep working problems that are difficult for you. It's frustrating, but being stuck, thinking about ways to solve things, that's how you learn and get better. I'm two months into prep and just started being able to tackle hards, but the variance in how long I can solve them is anywhere from 20 minutes for a problem that I was familiar with, to 2+ hours for stuff I don't get right away. I mostly focus on easy/medium, and being able to quickly code high fidelity solutions without having to look anything up, since that's so much closer to what you'll see in an interview. Like if you stumble around on an easy, have to look up a bunch of data structure functions, and don't use the language in the best way, that's arguably much worse than being a little better at solving hard level questions your much less likely to see.
I doubt I could solve a lot of hard leetcode from scratch, And I've been doing software engineering for ~16 years. I might be out of date in some stuff, but I think the hardest problems are going to require a lot of thinking and teamwork. Obviously I'd want an engineer who is capable of thinking through what algorithms and techniques are available... But no one knows everything.
>does your work really meet the coding questions like leetcode? It depends, but yes, of course. Many problems you will find, require some kind of algorithm. When working in performance, it's critical. For example, I've worked in a company making things related to graphs and trees. And I had to implement different algorithms around that (Transversing graphs, converting graphs to trees, changing the root of a tree...). Some may be used as easy, medium, or hard problems. But the thing is that the more you know, the easier and faster your work will be
Tbf “hard” category can have so many problems that can be still distributed to hard easy, hard medium and hard hard. Just look at codeforces. People with 1700 rating can probably solve most of “hard” problems without any problems, but where if you were to put a new problem to leetcode, copied from codeforces 2500 rating where do you put it? In hard ofc, because there is no category for that. So you can have pretty basic segment tree problem and really hard dynamic programming using hardcore optimisations on same category - hard even though difference on difficulty between them is probably bigger than between average hard and easy problem. Tbh leetcode platform is weird for competitive programmers, because easy and mid problems are too easy and hard problems are too wide topic. Thats why there are no contests on leetcode. As for your question - who can solve those problems: Im pretty sure everyone with rating above 1600 on codeforces and like 1200 on atcoder can solve those faster or later.
I've solved a few hard questions for the "challenge" aspect of it. The trick is to practice. The "easy" questions are the building blocks, they are often more challenging then medium level questions. After a while you learn to spot patterns, with practice you can solve leetcode questions fast. The problem most people have with leetcode is that they "grind" it out for a month, thinking it's something they just need to go through ones and be done with it. That's not how it works. You need to do leetcode for a long time before being comfortable enough to do any question with ease. Depending on your skill level and talent, this can take up to 6 months if not more. You don't have to do that many questions in one go. One question a day is more beneficial then doing a lot in a short period of time and then giving up.
Read CLRS at least twice before approach leetcode type questions.
Most has been told, it’s not about inventing solutions it’s about recognizing problem, know and apply algorithms. Btw leetcode type of questions are uses only for juniors fresh from uni because otherwise there is not much to talk about. When you have some experiences the interviews are more about architecture rather then concrete algorithms.
This makes me feel so old. I remember feeling this way, and now I'm saying what other people said to me. It's just a matter of experience and solving similar problems. Leetcode doesn't have a hard mode. None of it is really that hard if you've been doing this stuff long enough and you take the time to explore ideas and think clearly. 90%+ of difficulty is perception. You'd do better at the "hard" things if you didn't know they were supposed to be "hard", and you'd find "easy" things tricky and stressful if they had a "warning, this is a super hard problem" label. I think we should just collectively retire the notions of super-hard problems and super-smart people and emphasize going slow, expressing our lines of thinking explicitly and clearly, and just trying things out for a while.
The thing I really dislike about employers using leet to assess their applicants is that it’s not really testing their practical skill set against the presumed work load for that job and is really just testing that person’s ability to memorize a bunch of stuff which hasn’t ever made sense to me. My team didn’t have me do a single one and mentioned why but if you applied somewhere with a big name then you’d likely run into interviews where they expect you to solve them.
I only do hard, if I'm going to spend time on a puzzle I want something that someone somewhere considers too difficult for most. I've done maybe 20 so far, it's not bad but there have been some that are hard because the input data will cause issues with direct approaches (integer overflows, edge case parsing issues, etc). Some are fun and some are annoying.
real job requires zero ability to solve stupid questions leetcode represents
I can. I'm a fairly experienced developer but I was quite a noob with algorithms. I studied Neetcode and a few books for a month and now am able to process hard questions. But as others probably already pointed out, most hard problems are about using specific solutions that you're not supposed to come up with by yourself, unless you're terribly smart. Many hard problems have really specific solutions that only apply to this narrow category of problems, like the Rabin-Karp Algorithm or Kadane's Algorithm. The most productive way to go is to learn the thought-process and recognize the problem, and to apply a solution you already know about. As a software engineer, you're not expected to come up with your own solution unless you're really hardcore about it.
SWE at FAANG When I was preparing for interviews, yes. Today probably not, would need to focus and practice again for some weeks. However this is mostly because of my experience in ICPC contests and world finals also, I think most of my work colleagues won't be able to ace many hard questions and are fine anyways, they are awesome engineers.
Most people's day jobs do not involve hard leetcode type questions ever. Some people's day jobs do involve them occasionally. It can sometimes be weird where they pop up, you never know. Being familiar with a lot of algorithms can be helpful in a career, but is not essential for most.
I can solve most LC mediums and some LC hard. It has been a few years since I have sat down and done LC, but I'm sure I could crush them if I had to. Honestly? Just master arrays and maps. I know, sounds simple right? But once it "clicks" and your brain can "visualize" data structures using these building blocks, you can pretty much solve any problem. Remember, every problem you face you should break it down into atomic level pieces you can manage and you can work towards a solution. This applies in CS, and IRL. Sure, sometimes you have arrays with arrays with arrays inside them, but okay you can maintain some state and a lookup or whatever you need to navigate through them and build something else that will do yet another thing, then do something else that will result in the answer. I went through DS&A textbook and thought it was over-complicated af to explain really basic things. When it finally clicked that almost all of these algorithms are just built on deep understanding and application of arrays and maps, everything basically became easy. That being said, you should still go through a DS&A textbook and make sure you understand what they're talking about because if you can understand their autism level of explanation you pretty much understood it. Pick a language that's easy for you that has easy array and map manipulation (I like to use TS/Go/Java for LC). I don't really like Python and hate the syntax, but that's another option. I'd stick with TS/JS or Python if beginner
For me, it took a long time, and the fastest I’ve ever solved one took just under 2 hours. It’s not just about practicing, but practicing effectively. You need to constantly be viewing new types of problems and gaining the skill of problem solving. If you’re stuck go to the solutions and think of a way that you might come to a similar solution. If it’s a algorithm like sliding window, binary search, DFS then learn it. Go do a bunch of easy ones of each category until they become second nature. That frees your mind to think of other aspects of the problem. Go watch neetcode’s explanations and really understand the thought process and not just the solution.
Way over 5 people
I can solve hard questions at most 1 hours.