Message on Whatsapp 8879355057 for DSA(OA + Interview) + Fullstack Dev Training + 1-1 Personalized Mentoring to get 10+LPA Job
2 like 0 dislike
11,167 views
in Tutorials-Roadmap by
recategorized by | 11,167 views

6 Answers

0 like 0 dislike
Best answer
THE LIST OF LEETCODE QUESTIONS SORTED BASED ON MOST POPULAR QUESTIONS HERE:

https://docs.google.com/spreadsheets/d/1ZXg8-VkK3UQxYxra7oYJeX1joHKSyz3U0WG7SUjrzy0/edit?usp=sharing
Solve it :)
by Expert (107,550 points)
selected by
0 like 0 dislike

I have been actively using leetcode as a platform to prepare for interviews for over 4 months now, and I feel I have learnt a few things along the way, that might or might not be useful for the other person looking for some direction, and getting a clear idea of how to progress on this journey.

 

[EASY]

 

  • If you are just starting off, starting from easy problems is the best way to get in touch with your coding skills again, and/or build up new ones.
  • As mentioned by other users, it’s better to have a breadth-first approach to easy problems. Pick 5-6 questions from each topic and try to master the basics of the topic.I did a depth first of all the easy ones but looking back I feel it’s better to move to the next topic once you feel confident in one.
  • The purpose of the easy questions is to ingrain the basic concepts of a particular data structure or algorithm and if you look closely you will find a lot of questions asking for solutions testing your ability/understanding of language syntax, data structure core basics,etc, basically the “dirty” work, we so often don’t give due attention. Leverage the same and get your hand dirty.
  • You will also find a healthy mix of the use of two-three data structures or algorithms in some problems. Look for such problems, for they are a great way to test your understanding of how more than one DS work together to build a beautiful solution.
  • That being said, I would recommend moving from the “easy” phase as soon as possible, for its the mediums that will be asked mostly in interviews.
  • Must-do Easy questions  [ Download the list here ]

 

[MEDIUM]

 

  • Once you feel confident enough with the basics, you can move onto the medium ones. Medium problems are pivotal in interview preparation since any decent interview will have at least one instance of medium problems. Moreover some of the advanced data structures and algos like graph, backtracking, dynamic programming are not well covered in the easy section, so the medium problems are a good stop to learn them.
  • Again, breadth-first approach works wonder in this case as well. Pick like 10 problems from each topic, try to solve them to the best of your capabilities and practise of easy problems, and if you find it difficult to solve at first, take help from the discussion forum.
  • What's important to note is the purpose of you doing N number of problems, should solely be to learn new techniques, be able to apply the learnt technique in similar problems later, and learn the basics of advanced data structure that you might have missed in the easy section.
  • It's normal to not be able to solve medium level problems at first. Don't feel bad about taking help from the discussion forum, but try to learn the techniques as much as you can.
  • Do not cram the solution. There is no point hoping you will remember the solution in an actual interview, because in a pressure situation it's not advisable to rely just on your memory. Rather place your bets on your acquired skills.
  • While you are solving questions of a particular topic, make sure to give the theory a good read before or during the process of solving questions. It's important to know the basics of implementations of various data structures and algorithms like graph traversals, backtracking, memoization, trees, binary search etc. There are various resources available for the same, geeksforgeeks, Cracking the Coding Interview, Tushar Roy's lecturesBack To Back SWE, to name a few.
  • Once you feel fairly confident after say, 60-70 mediums, it's always a good idea to start giving contests. Contests not only simulate the actual interview scenarios by having a time constraint, they also test your ability to be able to come up with solutions on your own without taking help from any other resources.
  • Keep looking at better solutions posted by other users, compare your solution with them in terms of time and space complexities, know when to make the tradeoff between the two and ask for help whenever you feel stuck. Be open to learning and the rest will fall in place.
  • A comprehensive list of must-do medium problems [ Download the list here ]

 

[Other points to note]

 

  • Leetcode is a wonderful community to learn, discuss and find support in others going through the same process. Leverage it.
  • Don't shy away from being a part of discussions, ask for help, or ask questions from others just because you feel it sounds stupid.
  • Constantly read articles on Leetcode, not only related to solutions but interview experiences, problems faced during the process etc. You can benefit so much from learning about stories of others here and also derive a sense of belonging to the whole process.
  • Make notes of all what you have learnt from a question, a trick or techinque for these will be handy when you will need to revise.
  • It's okay to feel lost, confused or difficult to solve questions at times. Some questions are harder than others, some are trickier and some have no solid pattern to them. Don't get intimidated by the process. With time and practise everything gets better. Have patience and don't lose hope.

 

In the end, I want to mention that I am still not 'perfect' in solving problems, but leetcode have taught me a lot and I have definately come a long way in this process, and with a little guidance, determination and patience anyone can.

 

Any updates to the list are welcomed, so are any questions and do share your experiences of your leetcode journey, for everyone can benefit from each other's experiences.
Good Luck and Happy Leetcoding!

by Expert (107,550 points)
0 like 0 dislike

Read : https://medium.com/leetcode-patterns 

Solve leetcode problems according to this sheet : https://docs.google.com/spreadsheets/d/1je6J87BX5C5fo5Gbok1TJncVK3-UFkiDznHUzhtHbVU/edit#gid=0

There are multiple ways to pick problems on LeetCode. Some of these, I tried are :

(1) Random Order

- OR -

Sort them based on difficulty level and

(2) Solve in Linear increasing/ decreasing Order of difficulty

(3) Perform "Binary Search" to find your current level and from there on you can start in gradually increasing order. :)

- OR -

(4) Another dimension for picking an order can be based on "tags". For example, you can consider solving problems under certain category such as Dynamic Programming, Graph, Depth First Search etc.

(5) You can also consider picking problems based on decreasing order of "Acceptance" rate.

In general , I have found solving them in increasing order of difficulty while skipping similar type of problems quite helpful. I have also picked problems under certain Tag such as Dynamic Programming or Binary Tree and that has also helped improve skills under certain topic.

Hope it helps.


ADDITIONAL thought :

Overall, I believe that even if you know the solution of a problem, practicing by coding it on LeetCode platform is still helpful because

  • Solving Easy problems helps you memorize syntax & constructs of programming languages.
  • Solving Medium problems helps you improve your programming speed and
  • Solving Hard problems keeps you ahead in Competition.

So, in some sense you will get benefit by solving all the problems. But it is not practical if you are using LeetCode to prepare for interviews. In this case, you will have to make a plan on what kind of companies you are targeting and how much "time" you think you have before appearing for interviews in these companies. You also would want to see the kind of questions the target companies ask. Glassdoor and CareerCup might be helpful in this. If your target company asks "Easy/Medium" questions only I would not waste time on Hard problems. Similarly if the company expects a fairly working code, practicing good number of problems before appearing for interview becomes important

by
0 like 0 dislike

Read this article : https://heidi-newton.com/blog/getting-good-at-leetcode

Checkpoint 0: Beyond the CS Fundamentals

This guide assumes that you have at least heard of the basic tricks such as two-pointers and bit manipulation from CTCI or similar books. You do not have to master them, knowing what they are can help you study the solutions from LeetCode better. If you have studied only the CS fundamentals, you may want to have a quick look at the books before starting LeetCode.

Easy Problems

Easy problems are intended to help you get familiar with the basic tricks. Usually, they have trivial brute force solutions. What you need to learn is to apply the tricks to improve your brute force solutions.

Checkpoint 1: Practicing the Basic Tricks

If you randomly open a few easy problems of each data structure or algorithm and you can pinpoint the optimal solutions and implement them in a few minutes, you may move on to the next checkpoint.

Study Guide

  1. Sort the problems by acceptance rate descending. Problems with higher acceptance rates are relatively easier among the pool of easy problems.

  2. Try to solve the problems with no hints at least with brute force solutions.

  3. It is tempting, but not helpful, to abuse the "run" button. Try Easy ones with a goal to get accepted on the first submission, since this more realistically models a whiteboard situation. It forces you to think of all the use cases yourself. 

  4. Study how the top solutions apply the tricks to improve the performance. Sometimes solutions are up-voted just because they are short and they may not be well documented. Read also the comments below and do not feel shame to ask for clarifications.

  5. Once you are comfortable with the basic problem-solving patterns, go back to checkpoint 1 and decide if you would like to move on.

Medium Problems

Medium problems are intended to train your skills in seeing through the problems. They are usually disguises or variations of easy problems. Brute force solutions sometimes may lead to time limit exceeded (TLE). What you need to learn is identifying what solving patterns the problems are asking for.

Checkpoint 2: Problem Pattern Recognition

If you randomly open a few medium problems of each data structure or algorithm and you can identify what problems they are disguising at and can implement close-to-optimal solutions within half hour, you are ready to challenge the hard problems.

Study Guide

  1. Carefully read each word of the problem statements and look for hints about solving patterns. For example, the number of ways for a task indicates DP, string transformation with dictionary indicates BFS / DFS / Trie, looking for duplicate or unique elements indicates hashing or bit manipulation, parsing indicates the use of stack. If you need a compiled list of tricks and indicators of when to use what, you may check out the book Competitive Programmer’s Handbook

  2. When you have a rough idea about the direction, you are half way to go. Try to at least implement a suboptimal solution. It is okay that yours is not optimal, people spent much effort to polish their solutions to optimize them.

  3. Once you have a suboptimal solution, you may head over to the top solutions to learn what you can improve and any alternative methods to solve the same problem.

  4. Try to thoroughly understand the thought process and implement the optimal solutions based on your understanding without looking at any hints.

  5. Once you are comfortable with seeing through the problem patterns, it is time for the grand challenges.

Hard Problems

Hard problems are bar-raisers. They are intended to be hard and make you struggle. Usually, 45 minutes are barely enough for you to come up with a working solution. What you need to learn is identifying the right directions to solve the problems more than just brute force.

Checkpoint 3: Graduation Check

Hard problems usually have constraints that make the typical tricks not applicable. If you are comfortable with improving existing tricks to solve those problems more than brute force, you are good to go. The time limit is not that important here, you need to learn how to bridge the gap between typical tricks and those constraints.

Study Guide

  1. Solving the problem is more important than finding the optimal solution. Your first task is to at least come up with a brute force solution. Dropping the time and/or space constraints usually help you identify one.

  2. Identify what parts of your solution can be optimized to satisfy those constraints. This has been covered by many books and articles such as the BUD approach from CTCI so I would not go into details.

  3. If you struggle to improve your solution, time to head to the top solutions. Understanding the thought process is critical here. You need to learn what are the right data structure and algorithms to use and how those solutions handle the corner cases.

  4. Once you are comfortable with the stress from the hard problems, try to solve other hard problems with suboptimal solutions.

by
1 like 0 dislike

It’s frustrating to look at LeetCode’s 1500+ problems while getting stuck finding permutations of a string at the same time. How am I ever gonna get that dream job? I’m tired of my friends updating their

LinkedIn

status bragging about their new jobs. I need the shortest path algorithm for getting a job.

We’ve looked at over a thousand interviews (data here), searching for patterns, and here’s what we found that we think can really help you speed up the process.

You Don’t Need to Know Manacher’s Algorithm

Or Bellman-Ford-Moore Algorithm, or Kruskal’s ALgorithm, or Dijkstra’s Algorithm or KMP Algorithm… Coding interviews almost never touch these “academic algorithms”. Researchers spent years coming up with complex algorithms like these and it’s not something you are to figure out at a 45 min interview. A good-enough rule of thumb is an algorithm that’s named after a person(s) you can safely ignore. You may see people discussing it in the forum, but we can safely tell you from data you don’t need to know these algorithms. So save yourself some time and focus on the important stuff.

I Can’t Solve LeetCode Hard Problems

The good news is you don’t have to. 80%+ of the problems you encounter at real interviews are easy and medium problems. So practice easy until you can solve them like a walk down the street. And then focus your effort on medium problems. It’s much worse to fail to code a medium problem bug-free at an interview than to fail to code a hard problem. Also remember you are compared to other candidates who likely also find hard problems difficult.

What Language Should I use?

Use whatever you are most comfortable with. Unless your job requires it, it is very rare for companies to ask you to use a specific language for interviews. That being said, we think python is the easiest choice for interviews thanks to its terse syntax. You probably save 5–10 min of typing/writing, which is a meaningful amount for a 45 min interview.

How Do I Know If I’m Ready for Interviews?

A good rule of thumb is: if you can consistently solve random medium problems within 30 min and within 3 submissions then you should be ready to go to interviews. 30 min because the interview is typically 45 min and you are expected to interact with the interviewer during that time. 3 submissions limit because interviews typically look for bug-free candidates.

How Many Problems Do I need to solve to get a job?

To answer this question, let’s take a trip down the memory lane.

Pre-2014, all you have to do to get a job is reading the book “Cracking the Coding Interview”. It has about ~150 problems and that’s all you need.

In 2014, LeetCode was started. “Two sum”, the “Hello World” coding interview “Two Sum” was the first problem.

By 2015, there were about 200 problems on LeetCode. Interviews at this time are still mostly around basics like Two Pointers, Linked List and Binary Tree Traversal. If you have done 100 problems on LeetCode you’re more than covered for your interviews.

From 2016 to 2018, things are up and people are hopeful in Silicon Valley. Engineering salary is going up and more people are going into software engineering. We start seeing more complex topics such as Depth-first search and even dynamic programming.

From 2019 to 2020, things start to turn sideways. Tens of thousands of people are laid-off. LeetCode now has 1500+ problems. Topic-wise, Depth-first search, Breadth-first search, Two Pointers are still the favorite.

The gist of the story is

It’s more important to master the topics/patterns than trying to do maximize number of problems you do

That being said you probably need to solve 150–200 problems to master the patterns. It’s most efficient to learn all the important patterns first and then practice more problems.

Where Can I Find These Patterns

Head over to ALGOMONSTER

by
1 like 0 dislike

The goal of this answer is not to teach you how to scramble your way into a top tech company, but to help you learn how to acquire algorithmic problem solving skills, which in turn will help you get the jobs you want. We'll start with some general tips that apply pretty much to anything that you want to get better at:

 

  • Consistency is key. You want to start as much in advance as you can, and do it daily. Doing it for one hour a day is better than doing it for seven hours on Sunday only.
  • Focus on active improvement. This means that if you're on auto-pilot or if you're not focusing, then it's OK to just stop and come back later.
  • Remember that everybody is different and there is no one-size-fits-all. So feel free to deviate from this (or any) guide.

 

For generalist SWE roles, you should focus on the Algorithms type of problems. Years ago, these were the only problems, but since then, Database, Shell, and Concurrency have been added. So you should view only Algorithms problems in the problem set:

 

https://leetcode.com/problemset/algorithms/

 

This is going to be your "home base", so let's customize it.

 

  • You can click the "Difficulty" header twice to sort it from easiest to hardest. Interesting enough, this also sorts them within each Easy/Medium/Hard category in reverse order by acceptance rate.
  • Click the empty header in the first column to sort with the unsolved problems on top.
  • Finally, you can optionally run this script in your web browser console to filter out the questions that are locked for non-premium users. Of course, it's a little sketchy to run Javascript you find online in your browser console, but it's pretty simple if you want to understand what it does.

 

Now you're ready to go. Obviously the best thing you can do it just solve every single problem on LeetCode. If you do that, you're really good to go. But, unfortunately, nobody has unlimited time on their hands, so we're going to have to optimize a little.

 

  • Start from easiest to hardest. You can start skipping questions if you feel like the problems are getting too easy for you.
  • Start with problems that have an editorial already written. These are the ones with a little "document page" icon in the "Solution" column of the problem set. As an exercise to the reader, you could re-purpose the script above to filter only for problems that have a per-written editorial.
  • Start with problems that have good reviews. While LeetCode is a pretty great platform, not all problems are created equal. If you open a problem, you can see how many people upvoted or downvoted a problem. I'd initially stay away from problems that have a worse than 2:1 ratio of upvotes to downvotes, and problems that have 4:1 or above are usually of fairly high quality. It's much easier to learn from the higher-rated problems.

 

Eventually, you're going to find a problem that's too hard, and you'll get stuck. That's totally fine. In fact, it's absolutely fine (and perhaps even efficient) to give up on some problems. It's possible that it requires an algorithm or data structure that you haven't seen before, and there's no need for you to pull your hair out trying to re-discover an algorithm or data structure. Here are some tips for how to get un-stuck.

 

  • First, if there is an editorial already written for the problem, start with that. These tend to be fairly high-quality and often include a well-written code solution.
  • Next, open the "Discuss" tab for the problem, and read some of the posts. These vary wildly in quality: some people just post a solution; others go into great detail. Your mileage may vary here, but this is also often a helpful resource if you get stuck.
  • Finally, you can Google the problem itself, and oftentimes other people will have posted solutions or written about it on third-party sites, like their personal blog or Github repo.

 

Once you've gotten into the groove, and you feel mostly confident solving the problems on LeetCode, it's time to refine your skills.

 

  • If you feel weaker in a certain algorithm, you can filter the problem set by "Tag". This is NOT recommended for general practice, since much of the actual problem-solving skill you want to have is the ability to identify the type of algorithm to solve a problem. So, if you have filtered by "Binary Search", you know the solution to the problem is probably going to be binary search.
  • Go through some older problems, and make sure that you have found the optimal solution. Oftentimes, the LeetCode online judge will actually accept suboptimal solutions. If an O(N) solution exists, but you submitted an O(N log N) solution, most likely it's going to still pass. The percentiles for runtime/memory are actually a bit misleading so don't worry too much about that. The only time that it kind of helps if there are two very different runtimes, like O(N) vs O(N^2), and the runtime distribution will look bimodal.
  • The weekly contests are a great way to see where you stack up against the rest of the community. Plus, they apply some time pressure, and usually give new problems that you haven't seen before.
  • This is new and not available several years ago, but the new Mock Interview is actually really good for adding some time pressure. Unfortunately, there is no way to filter out previously solved problems, so you might get repeats of ones you've done before--but you can view this as an opportunity to revisit some of the older problems. Apparently, this can also help you identify areas of weakness.

 

I've never used it, but hearing from others, I'd consider it to almost be "cheating" but LeetCode premium is actually pretty good if you're really in a crunch and want to see what questions companies tend to ask. I do not recommend studying for a specific company, since your goal should be to build up algorithmic problem solving skills, rather than memorizing the answers to a few known problems. However, if you are really in a time crunch, then this could be your best bet. (I'm recommending paying for LeetCode premium, and I'm not even sponsored by LeetCode, believe it or not! That's how good it is.)

 

Finally, if you've got some money to spare, or have a nice friend or library who can lend you the book, I also strongly recommend "Cracking the Coding Interview". 

Don’t rush, and incorporate “spaced-repetition”

 

  • If you aren’t able to solve a problem, don’t just read the solution and move on. At an interview prep course that I taught, I gave my students a list of 40 questions in advance and told them that their midterm quiz would be one of the 40 questions. Students who had simply “read” through the solutions didn’t fare well.
  • Whenever you do end up looking at a solution, or discover a new interesting way to solve a problem, you need to revise it at frequent intervals in order to internalize it. You can keep track of what and when you need to revise by simply using a spreadsheet, or by adding events to your Google Calendar. You can use a fibonacci pattern (e.g. revise on day 3, 5, 8, 13, 21 etc). Alternatively, you can use apps like Anki that have spaced repetition built in.

 I hope that it can help: https://chivagarg.medium.com/be-agile-not-prolific-f0f88b86aace?sk=b54bf971bfe4c18e9f1f7e4059e044a4

by