Starting to solve DSA problems might seem scary to many and some might have started but failed to continue it for a significiant amount of time. So, why does this happen? What are you lacking? A structured problem solving approach.
You don't read the problem statement and straight away dive to code the solution. That's not what a wise person does and its not something to be ashamed of. Before coding up the solution you first need to understand the problem and plan the algorithm beforehand and test it yourself. Then you can implement it which would not take much time then.
Now comes the main question, how do you start then?
First of all, you should read the question properly and should understand the question well enough, the input format, the output format needed. The core question might be layered with an extra complexity by adding some useless info. You need to extract the core question that the problem asks.
For example, look at this leetcode question below (198. House Robber)
You are a professional robber planning to rob houses along a street. Each house has a certain amount of money stashed, the only constraint stopping you from robbing each of them is that adjacent houses have security systems connected and it will automatically contact the police if two adjacent houses were broken into on the same night.
Given an integer array nums representing the amount of money of each house, return the maximum amount of money you can rob tonight without alerting the police.
The question added unnecessary entities like money, police, robber, house. You don't need to know them for solving the question. You just need numbers and data structures. Its mentioned in the end that you are given an array representing the amount of money, therefore the input is an array of numbers.
On reading the first paragraph carefully or several times if you need to, you can come to a conclusion that at its core, it just asks you this basic thing
Return the maximum sum of non-adjacent array elements from the given input array of numbers.
This core question was coated with many things to confuse the readers and take their time. Now if you get this you can start to focus on the problem that you got now.
Whenever you solve a question always make yourself clear what is the problem you're solving? Break that problem to smaller test-cases, list them and tackle them in an isolated manner by completely focusing on the sub-problem. As you solve the sub-problems, tick them in your list to boost your motivation. Once you tick all the problems, bam! you solved the main problem.
For solving a problem use the PBOI approach. It is an acronym for
P - Pen & Paper
B - Bruteforce
O - Optimize the bruteforce
I - Only now, Implement
Think of the testcases or use the given ones and solve by yourself on paper. It would be pretty easy to solve for you unless some recursion is involved. So, better start with a small testcase.
Now, slow down and carefully go through the process your brain follows to solve the testcase. Translate your brain's process on paper using the steps that computers could understand and perform. This process will take time and you will improve by time and practice.
Once you have the steps, congratulations! that's what you call an algorithm. The next step for you would be to turn this algorithm into pseudo-code. If your programming knowledge is good this step won't be tough.
Now take a test-case, and don't solve by your brain this time, but solve using the pseudo-code that you wrote on paper. Go line by line and pass the control of the program as a real computer would do. Track the variables and data structures on paper and update them at each line. This process is called dry-running the problem.
This helps you by saving time from implementing a wrong solution and then banging your head. If there was a problem in your algorithm, you'd find right away at the time of dry-run and then you can fix it there. This approach would save a lot of time and is efficient.
Once you get a working algorithm, calculate the time complexity of your algorithm and try to optimize it even further on paper itself. You don't need to implement that bruteforce if it working on dry-run. It would just boost your ego. Try to optimize it and after trying enough if you were able to good, else you still have a bruteforce approach.
Finally, comes the step for implementation. Now as you have an optimized algorithm and a pseudo-code for the problem, you can easily implement it in a programming language if your syntactically good in your preferred lanugage.
This was a structured problem solving approach that many of the programmers use. Some knowingly and some unknowingly.
Now, you might be thinking how much time should I try devising a working algorithm? I'd say if you're new to a concept, you should give 45-60 minutes and if you're familiar with the concept you should try for 30 minutes and then look for solutions.
When you look for the solution, you don't have to copy paste it directly, but rather you have to dry-run the found solution to get a deep understanding of the algorithm that is used. In the implementation part too, you don't copy-paste the solution. You should type by yourself because this helps in even deeper understanding of the solution. Copy-pasting might make you feel good to see all the test-cases passing, but in a longer run you won't learn anything. Even if you try other's solution, NEVER COPY-PASTE.
Thank you for reading! Don't forget to leave a like if this blog post has helped you and follow for more such content.
Top comments (0)