DEV Community

Cover image for Not Your Usual Study Guide to Cracking Coding Interviews
Nouran Bakry
Nouran Bakry

Posted on • Updated on

Not Your Usual Study Guide to Cracking Coding Interviews

Preparing for coding interviews can be a pain. I found a way to make the process easier.

I have been preparing for technical interviews and I have practiced problem-solving for a while and I have developed my study guide. I am hoping that this article will help you develop an effective study plan to ace technical interviews.

Before you begin your interview preparation, you need to have a clear goal in mind, what kind of company do you want to work at? Some strategies will be effective only for some companies and not effective for others. For instance, some companies are looking for software engineers that are experienced in a particular field or stacks like a Java Developer, An Android Developer, or an ios developer, while for some of these job opportunities you may be asked to solve problems but that will mostly be a small scope of the interview. The interview will mainly focus on that particular stack or technology. In this article, I am discussing preparing for general Software Engineering roles at companies whose interviews focus on algorithms, data structures, and system design.

First pick a programming language that is easy for you and one that you are familiar with, it doesn’t matter which one from my experience most large companies let you pick whatever language you want.

Next, you will need to review important data structures and algorithms and for that, you will need a reference, Everyone will probably recommend CTCI (Cracking the Coding Interview By Gayle Mcdowell), From my experience, it is a great reference but I see it more of a study guide and I needed a more detailed reference. I will share what references I used at each step of my preparation.

Studying and Reviewing Important Topics

At this stage, I watched MIT Data Structures and Algorithms lectures and I also looked through their notes. While reviewing the lectures, I went through Cormen's Introduction to Algorithms. This was a great way to review data structures and algorithms. MIT’s course is amazing, they go through all the concepts and explain each one thoroughly, I would highly recommend that you check it out.

You don’t have to watch all the lectures or read all the references. Make a list of all the important topics and for each topic make sure you completely understand the concept. How do you know you understand it? Well, can you explain it to somebody else? If you can explain it to any of your friends then do so and get feedback from them or if you are by yourself record yourself explaining the topic, try to draw any diagrams, and write on a board or paper. This way you can make sure you fully grasp the concept.

As for topics like System Design or OOP, this will depend on your level and experience. For instance, if you are a junior, check with your recruiter if you will be asked system design questions, and try to get familiar with Object-Oriented Programming, Design Patterns, and Databases. If you are more experienced, you will need to look for more references, I used this github repository along with some youtube videos you can also Check out Ustav's video on System Design.

Solving problems

I solved questions per topic. During this stage I used Elements of Programming Interviews in Java, there are other editions in other languages I solved problems in java that is why I used this edition. This is an excellent guide, it has detailed explanations and great problems of different difficulties and it covers all the major topics. At the beginning of the book, there are also very helpful tips and tables that can help you create a timeline.

I also started solving on coding platforms, I have used leetcode and hackerrank. While solving I used to time myself and I wrote code on paper or a notepad, this is preferable so that you mimic whiteboard interviews. If you use a code editor don’t use an editor that will correct your syntax and Don’t run your code before to check if it is working. Wait till you finish and after your time is over then you can run your code. If I found myself struggling with a particular topic I went back to the previous step.

After solving problems on each topic, I started solving problems randomly, this step is also important so that you don’t expect what data structure or algorithmic approach you will need in your solution. Try to solve easy problems first once you get comfortable with them then you can go ahead and solve medium and hard problems. If you have time in your schedule, Hard problems are important to focus on because they combine several algorithms and data structures, and practicing hard problems will significantly improve your problem-solving game. There is an excellent guide to grinding leetcode problems that you can find here.

Evaluation

Now for the most important part that stepped up my problem-solving game. I started evaluating myself, for each problem that I solved, once the time was up, I used to look at my solution and ask myself some questions, what went wrong? what could have made my solution more optimal? was my code clean? was my syntax correct? and then I scored my solution. I used to score my solution based on correctness, optimality, the time taken, O(n), etc.. and then I averaged my scores. I learned this approach from Engineering with Ustav's guide to coding interviews.

This was a game-changer for me. I made a Trello board dedicated to problem-solving and I created three lists (to-do, repeat, done). In the to-do list, I added all the problems I wanted to solve from leetcode, hackerrank, or any books or references, and every time I solved a problem I scored it, if I didn’t get 5/5 I would add it to the repeat list depending on my score, if my score was high I would add it to the bottom of the list, if it was low I added it to the top of the list. You can also use a Notion, a pen, paper, or any simple to-do list to applying this method. In my Trello board, all the to-do problems were problems I never solved before, problems in the repeat list are problems I want to solve again and the problems in the done list are the problems I can solve confidently and this is the list I am most proud of. Every time I want to solve problems I would pick problems from the top of my to-do list and the top of my repeat list.

Mock Interviews

This is also an important part of your preparation. Mock interviews are where you apply everything you practiced. You need to reach a state where you are confident and calm during mock interviews. One video that gave me great tips on mock interviews was Chris Jereza's video on coding interviews. If you have a friend that is with you on your journey then do schedule time for mock interviewing one another, if not then you can schedule a mock interview on pramp, which is a platform that allows you to match with another candidate and you can interview each other. Another method is you can try to replicate your interview experience on your own and record yourself solving problems with a timer. This is also a very useful way to become more confident with interviews. You can then watch the recording and evaluate yourself. Real interviews with companies are also another way, try to schedule actual interviews and treat them as mock interviews, if you pass and get an offer yaaay! if not then this was a mock interview.

Things to keep in mind while solving problems

1. Quality over quantity.
It doesn't matter how many problems you have solved. The quality of your problems, the time taken on each problem, and the way you approach the problem are more important.

2. Explain your solution and your approach clearly before you think of how to write code.
This is the most important part of solving problems, if you have a clear approach your interviewer will know that you are capable of solving the problem and you will be able to easily translate it into code.

3. You don't have to get the most optimal solution right away.
If you are stuck, think of the most simple solution or a brute force solution, once you have that then you can look for bottlenecks or spots where you can use a data structure may be a hash map or maybe you need to use a particular algorithm. Once you have a clear correct brute force solution you can optimize it.

4. There is no such thing as failure.
Don’t get discouraged if you don’t know how to solve a problem or if you get rejected. Think of it as trial and error, try to enjoy the process as you are learning how to get it right next time. Don’t think of the future or the past and try to mindfully practice and learn for your interviews one step at a time.

5. Problem-solving is a skill you will need throughout your career.
Try to find what you like about it and look at it as a skill that you will constantly need to improve. You will always have interviews if you want to work full-time so you need to always improve your problem-solving skill.

Lessons I learned along the way

Stress and overthinking will only get in your way.
Try to be as calm as you can be, if you are not in a position to put yourself under the stress of an interview then maybe take some time off if you can afford it and think of how to improve this process for you. Think about what you want to be doing and how you want to go about it. Find out what works for you and go from there. There is no particular timeline or process, you can solve one problem everyday or 5 problems or 10, this depends on how you are able manage your time and what your goals are.

Mass applying is not effective.
Be mindful with applying for jobs, I understand how looking for a job can be a painful experience but make sure you are applying for the right companies. Before applying to a role, look at the company and the role and try to understand more about it, is it what you want to do? what kind of interview preparation is required for this role? Do you know somebody who works at the company or someone who interviewed with them? Try to gather some information that can make the process easier.

Putting a deadline for landing an offer is toxic.
Imagine putting a deadline on something you can never predict, luck and fate has a major role in you getting an offer or not. If you keep expecting to land a job by a particular date you will only get discouraged. Try to learn from the process as you go in a calm manner, employ the same evaluation strategy that you used with problem solving in your interviews, try to evaluate each interview experience and think of what could have gone better.

Conclusion

At the end of the day, career is only one aspect of your life. A job is just a way of getting an income and maintaining a well balanced life. This is all meant to improve your life, be mindful while learning and also be easy on yourself and don’t let it become a stressful or overwhelming experience that may decline your life quality or effect your mental health.

I have gone through many interviews and I have explored my way through different routes and methods so feel free to leave any questions. I wish everyone who is interviewing the best of luck.

Discussion (2)

Collapse
diballesteros profile image
Diego (Relatable Code)

Technical interviews are one of the more peculiar parts of the industry. Thanks for sharing your knowledge!

Collapse
nouranbakry profile image
Nouran Bakry Author

I hope it is beneficial.