Is the Coding Interview Preparation Advice Working for You?
A streamlined method to apply strategies in your interview preparation
Each one of us has different levels of technical competence, coding background, problem solving skills, preparation time in hand, etc. Coding interview preparation strategies or guidelines by our peers might not always be directly applicable to us.
I prepared for interviews following the strategies recommended by my friends yet couldn’t clear them. I realized, what worked for them needn’t necessarily work for me. I needed something to gauge whether the strategies are working for me and help me realize areas of improvement. After considering my technical competence, available prep time and keenly observing my preparation methods, I developed and experimented with an iterative process to learn whether I am progressing in the right direction and making corrections quickly. I used this process during interview preparation for Amazon and got an offer. I can attribute a significant part of my success to this process.
Iterative Process To Ingest And Evaluate Strategies
Goal Setting Phase
Keep a collection of all the good interview tips, strategies, approaches, techniques and advice that you would have collected. From here onward I will refer to this collection as ‘pointers’. Select one or a few pointers that you think are helpful and worthy. Form a goal to master it. If needed, breakdown a pointer into smaller chunks for your goal.
A goal should be small, doable, timebox-ed and have qualitative or quantitative benchmarks. It is important to consider your in-hand preparation time, programming fundamentals and problem solving skills for setting a benchmark.
Initially, it will be difficult. But you will become better at it gradually, as you assess yourself acutely.
(I will write how I used this model for interview preparation in italics. Focus on how I incorporated the pointer in the process rather than the pointer itself.)
When I was preparing for an interview, I had asked a friend who got into a tech giant for interview tips. He gave me two important pointers. (1) Aim to solve a medium difficulty level problem on Leetcode (an online platform to prepare for coding interview) in 25 minutes. (2) Make sure your code covers all the edge cases. At that time, my average time to solve a Leetcode medium problem was ~ 45 minutes. I had a good idea about fundamentals of data structures and algorithms, had solved many easy problems and a handful of medium problems on Leetcode. Considering this, I thought to set a goal — for the next 7 days, of all the medium questions I attempt, I will solve at least 50% of them within 35 minutes. Also, I will ensure 100% coverage, that is, all the test cases must be covered by my solution.
Practice Phase
Once you have a goal set, in this phase, you are incorporating the selected pointer and solving a set of problems from different sources like Leetcode, Topcoder, GeeksForGeeks, etc. Don’t modify your goal midway just because you had a bad day at practice. Unless you have realized that the goal is highly unrealistic at the beginning of your practice phase, don’t change it.
Pen down any mistakes you make for each question.Keep in mind your goal before you sit down for preparation.
With the preparation time I had, I used to solve about 4 medium problems everyday. I used to note the mistakes and solving time for each problem attempted.
Evaluation Phase
This phase is important because you want to know your mistakes before you make them in actual interviews. Once the allotted time is over, be unbiased and evaluate yourself.
Look through your past notes. Try to get an idea whether you are improving because of the selected pointer. Ask yourself: Are you more confident? What are the areas that need improvement?
Depending on the selected pointer, the best way to check whether you improved is to get feedback after a mock interview. If that is not possible, record yourself while solving a problem and evaluate.
If you find any major areas of improvement, benchmark them and include them in the current goal. Timebox this goal and use it for the next iteration. Continue the cycle until you meet all the benchmarks for that goal or you are satisfied with the progress. Only then, select a new pointer and set a goal. Practice. Evaluate. Repeat.
After practicing for 7 days, I reviewed all my notes. I analyzed that I solved only 35% of the problems in less than 35 minutes. I didn’t reach my goal of 50%. Also, I observed that I forgot input validations in many solutions. For the next cycle, I updated my goal to not miss any input validations and to practice for 5 more days. After 5 days, I noticed that I hardly missed any input validations. Of all the problems, 40% were solved in 35 minutes. Though I still didn’t reach the goal of 50%, I was satisfied with my progress and was confident that I will improve as I practice more. Then, I pulled in a new pointer, set a new goal and repeated this cycle.
Key observations
- In the example, you can see that I came up with an area of improvement (missing input validation) and included it in the goal for the second cycle. This was a significant area of improvement which was just applicable for me. It was not in the pointer given by my friend. Similarly, you need to figure out what YOU need to improve upon and meticulously work towards it. A peer’s pointer is just a direction, you need to deal with the road bumps on your path.
- Time box your practice for an optimal period. If you plan a small period, the results won’t be reliable. If you set a long period, it might be too late to know that the pointer was ineffective.
- It is important to remember to not repeat the old mistakes after learning something new. For each problem solved, I used to mention a small note for all the mistakes made. When I used to re-solve old problems (which I highly recommend), I checked if I committed the same mistakes. If I repeated a lot of them, I ensured that I set my next goal with criteria/benchmarks to resolve them. It kept the quality of my preparation consistent before adopting a new pointer.
- In my case, I was satisfied and confident with 40% result. As I saw substantial progress, I took up a new pointer and formed a goal to master it.
We don’t have to universally agree upon this process. This is just a means (not a protocol) to help you assess if the pointers are adding value to your preparation. You can make your own process that works for you. All the best!
If you liked this article, you can follow me on Twitter where I share my thoughts, tips and interesting reads on software engineering: @amish1502
Cover Image Source: Background photo created by rawpixel.com - www.freepik.com