In the Name of God, the Most Beneficent, the Most Merciful
I realize that there are many articles about this subject, so I’m going to try and give valuable information that I wish I had when I started my journey.
If you are a total beginner, read this first.
The single most important aspect of preparing for technical interviews is to solve many coding challenges. Although some tech companies have stopped asking algorithm questions and instead test domain-specific knowledge, most tech giants (and even the small ones) still require candidates to solve coding challenges. Many engineers get frustrated about this. Getting frustrated is completely pointless and a waste of energy that can be spent on more productive ways.
You can use Leetcode, Hackerrank, “Cracking the Coding Interview”, GeeksforGeeks, or whatever you're comfortable with.
I know people that have solved over 300 coding challenges and still couldn’t ace interviews. I have also seen people that solved 5 Leetcode problems fail. When I dig deep and diagnose their problem, it becomes very apparent. They’re not doing it right. Below is the strategy that works well for everyone. Some people might give you a different advice, but don’t listen to them. Just stick to this advice. If you follow too many advices, you’ll get lost.
Before solving any problem, it is important that you keep track of your progress. Without doing this, there is no way for you to know how far you’ve come along. Create yourself a progress sheet that includes things like what problem you’ve solved and how many minutes you allocated for that problem. You can create an excel sheet and keep your progress there or simply print it out and have a physical paper. Use whatever method that works.
The hardest part is to get over the first few questions. I remember when I first started working on Leetcode, I wasn’t even able to solve “Easy” level problems. I got stuck and couldn’t even properly use a while loop! Once you get over the first few questions, you will begin to see a pattern. The more problems you solve, the better your subconscious mind will learn to solve novel problems. For example, after you solve 3 array problems, you’ll notice common strategies such as “sliding window” and “two pointer” techniques. If you’re not familiar with these techniques, that means you haven’t solved enough array problems.
Two common questions that people ask are “How many problems should I solve?” and “How much total time should I spend?”. You should think about both quality and quantity. If the total number of problems measures quantity, solve a minimum of 40 problems. If the total number of hours measures quality, spend 20 hours.
In order for you to be interview-ready, your progress sheet should have a total of at least 40 problems and 20 deep focus hours. If you have anything less, you are probably not yet ready for the interview.
Although 20 hours seems little, you will be surprised as to how much progress you will have made in those hours. These aren’t your ordinary 20 shallow focus hours. These are 20 deep focus hours. Most people aren’t able to focus deeply for more than 4 hours a day. You probably will be drained after 2 hours of deep study time. I highly recommend that you distribute the 20 hours in 4–8 weeks time (preferably more if you have time). Give your brain rest time. Sleep well. Don’t spend more than 2 hours a day solving these problems. This isn’t a race.
Make sure to set realistic and achievable goals. Don’t set goals you have no control over. Instead of saying “I will get three job offers from great companies in 3 months”, say “I will solve x problems and spend a total of y deep focus hours for the next z months”. You have 100% control over that. But you have no control over whether or not you will get the job offer from your dream company.
1. Don’t work at a cafe or other noisy places. Study at your local library or some other quiet place.
2. It doesn’t matter where you get the problem from. It could be from Leetcode, Cracking the Coding Interview, Hackerrank, or anywhere else.
4. Don’t rush to the solution even if you think the problem statement is easy. Ask yourself important questions as if you’re asking your interviewer. Answer these questions to yourself as if you’re the interviewer. Try to whisper these questions and answers. Don’t be afraid of talking to yourself. If you still can’t understand the problem statement after 5 minutes, continue trying to understand it for the remaining time (use up the remaining 20 minutes to understand the problem statement instead of worrying about solving it).
5. Assuming you understood the problem statement, think deep and try to come up with a solution before the timer rings. If a brute force solution comes up right away, think about a more optimal solution. Do not look up the solution. This is the most critical step. Even if you absolutely get stuck and know 100% that there’s no way you can come up with the solution, still give yourself 20 minutes of undivided deep attention. Just ponder. Do whatever it takes to make your brain tick. If brute force is all you have, code that up.
6. If you’re using the Cracking the Coding Interview book, some questions may have multiple solutions. Read through all of them and compare it with yours. If you’re using Leetcode, look at the discussion page and view various highest rated solutions. If you weren’t able to come up with the solution at all, don’t worry. Try to understand the solution as much as possible. Code it up if you have time.
7. Once you hit a total of 30–35 minutes on that problem, do not continue working on the problem — even if you’re in the middle of understanding the solution. Just stop.
Mock interviews are very helpful to prepare yourself for the interviews. However, I think they are overrated.
Mock interviews are to interviewing prep what protein shakes are to bodybuilding. It definitely helps to consume more protein, but most of your results come from cutting calories and lifting weights. Solving problems on Leetcode or CTCI should be your focus.
Try and utilize whatever online applications and/or in-person programs you think are worth your time and money. I don’t believe it’s absolutely necessary. I have seen plenty of people ace technical interviews without doing mock interviews simply by using this strategy.
Study groups can also be effective. If you have friends that are also preparing for interviews, try and meet up weekly to mock interview each other. Structure it however you’d like. It helps to study with someone that’s on the same boat.
Have fun studying. I wish you the best of luck!