What Not to Do When Preparing for Technical Interviews

Mistakes I’ve made preparing for technical interviews

Photo by ThisisEngineering RAEng on Unsplash

Technical interviews can be super challenging. Very few people enjoy getting in front of a whiteboard to solve a tough coding question. That said, many companies use technical interviews in their hiring process for software engineers. Throughout college, I’ve spent a lot of time preparing for technical interviews and I want to go over some of the main mistakes that I made so that you can hopefully avoid them in your preparation.

The most detrimental mistakes I made are:

1. Typing my solutions directly into LeetCode
2. Looking at a problem’s solution too soon
3. Not taking the time to deeply understand a solution and underlying pattern
4. Creating unrealistic plans and goals

LeetCode is a great resource for anyone that wants to prepare for technical interviews. They have over one thousand questions on the platform and are constantly determining what the most frequently asked questions are at various tech companies. LeetCode is an awesome platform, but it enables a user to type solutions in directly. I did this for the vast majority of my technical interview preparation and deeply regret it. Typing into their platform doesn’t prepare you for a whiteboard interview. In preparation, you want to simulate conditions to the best of your ability. When solving a problem on LeetCode, write your code out on paper or on a whiteboard and then enter the code directly into the platform and see if it runs as you intended it to. More recently, I’ve started doing this and it’s already paying off. Typing directly into the platform is similar to what we do when we’re actually coding, but it doesn’t mimic a whiteboard interview. Also, writing the code out first and then typing it all up allows you to track the mistakes that you commonly make. While writing code out first takes more effort, at the end of the day, it’ll make you a better technical interviewee.

Often, when solving problems on LeetCode, I would give up and look at the solution way too early. You should take at least 30 minutes to work on a problem before you check the solution. If you’re completely roadblocked at 30 minutes (or longer), then you can check the solution and try to understand it. Looking at the solutions too soon does you no good. I regret having done this so much in my early days of preparation. It relieves the tension that we feel when we don’t know how to solve a problem, but it doesn’t teach us anything. Sit with the problem and struggle with it and eventually, look at the answer if you need to. Don’t check the solution too soon just to make yourself feel better.

Early on, I didn’t take the time to deeply understand a problem’s solution and the underlying patterns involved. For many of these problems, there are common patterns. The details of the solution itself matter less than your ability to detect what pattern should be used when solving the problem. When looking at a solution, don’t just copy and paste into your code editor and check to see that all the tests pass. Read the code line by line and understand what each line is doing. YouTube has so many great explanation videos for almost every problem on LeetCode. My favorite channel is Back To Back SWE. On the channel, Benyam offers some great, in-depth explanations of LeetCode problems. He focuses on helping the viewers understand the underlying patterns rather than just the solution to the individual problem being discussed.

The last mistake that I made revolved around creating unrealistic plans and goals. With so many practice problems out there, it’s easy to think that you can just do them all if you spend enough time preparing. This isn’t as possible as you’d think. Solving each problem takes time, effort, and energy. To succeed, you’re likely going to have to prioritize. If you’re interviewing at a specific company, try to go through the list of that company’s questions. LeetCode’s most common questions list is also a great place to start. If you master the most commonly asked questions, you should be able to identify patterns when you see questions that you haven’t seen before. When creating plans and goals, I’d often overestimate how much time I could devote to preparing for tech interviews or underestimate how much time it takes to solve a problem. Don’t do this. Create a realistic goal for yourself and stick to it. Solving 10 questions a day for a week and then burning out won’t improve your skills as much as solving 2 or 3 questions a day consistently for months. Determine for yourself how much time you can commit to preparing for technical interviews, create a plan, and stick to it.