5 Coding Interview Mistakes You Need to Stop Making

Coding interviews are challenging. Candidates dedicate weeks to studying fundamentals, rehearsing behavioral questions, and practicing popular coding interview problems.

But even with such thorough preparation, avoiding these five common mistakes can be difficult. I've made these mistakes countless times, and chances are, you have too.

I had to learn the hard way, it took dozens of interviews to finally overcome these mistakes. These mistakes are predominantly centered around the coding portion of the interview.

However, if followed correctly, I'm confident you will see an improvement in your overall coding interview performance.

Mistake #1: Not Understanding The Problem

One common mistake I often see among software engineers is not taking the time to fully understand the problem.

Here’s the thing, interviewers are intentionally vague. They want to see how you handle ambiguity.

When I say understand the problem, I mean digging into every detail. It's about asking questions that test your understanding and push the limits of the problem.

A practical way to start is by rephrasing the question in your own words. This makes you engage with the question more deeply. If your understanding is off, no worries – the interviewer will correct you.

Afterward, ask more follow-up questions. This is where you get more specific about the problem, and ask about expected inputs and outputs, edge cases, etc.

There are so many types of problems that I can’t give a blanket response for everyone; instead, you should take each problem on a case-by-case basis and try to “break” it. Essentially, what would happen if you gave a really large input, an empty input, or a negative input? You need to think in this way, by poking at the problem from different angles you’ll start to see edge cases that you need to account for.

By approaching problems like this you can solidify your understanding a lot quicker.

Now this might seem like a lot of upfront work, and it is, but it’s worth it. In the words of Albert Einstein, “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.”

Having a solid understanding of the problem is like laying a strong foundation, once you do this then the rest of the problem becomes a lot easier.

Consider asking the following questions to clarify the scope and intention of the problem:

• What’s the size of the input? The range of values?
• What kind of values are there? Negative numbers? Floating points? Empty or invalid inputs?
• Are there any time and space complexities constraints?
• Do I need to handle duplicates?
• How is the input stored?

Mistake #2: Not Thinking Out Loud

Now that you’ve clarified any ambiguity, you should have a better idea of how to approach the problem. But hold on — resist the temptation to dive into coding just yet!

By asking the right clarifying questions, you can start explaining your thought process out loud. This is where you begin brainstorming a brute-force solution and communicating any lingering assumptions you may have about the problem.

The key phrase here is "brute force." Your initial solution won't be pretty, but it’s still worth discussing potential tradeoffs between different approaches. By doing this, you and your interviewer should be able to agree on an approach before you start coding.

The best way to look at it is to picture yourself as the driver of a vehicle, with the interviewer as your passenger. You're sharing the same car, but you're the one in control, steering the conversation. In coding interviews, adopt this perspective — leverage the interviewer to enhance your understanding of the problem and guide you in the right direction.

Remember, it's not necessarily about getting the right solution, but rather showing the interviewer how you think. That's why it’s better to begin with brute force and then iterate on it to reach your final, optimal solution.

By communicating your ideas like this, you give the interviewer insight into your thought process, which is an important criterion they will be looking for.

One last thing to mention for this section: everybody gets stumped, even senior engineers. If you are completely clueless, don't be afraid to ask for help. The worst thing you can do is fake it and act like you know when you don’t; interviewers will notice immediately. If you don’t know or understand a concept, just say so. It's not the end of the world.

Mistake #3: Over-Complicating The Solution

I understand wanting to put your best foot forward during a coding interview. But don’t fall for a common trap I see a lot of engineers fall into and that is over-complicating a solution.

In general, I would advise steering clear of anything too "flashy" or complex—think along the lines of red-black trees, skip lists, or heap sorting. Stick to the basics and rely on foundational knowledge, such as common data structures like arrays, linked lists, hash tables, trees, and graphs.

Writing a complex solution can backfire, especially if you’re not 100% sure if it’ll work or not. In order to avoid any issues, it’s best to keep things simple.

Here are the benefits of simple solutions:

• Communication Challenges: Overly complex solutions can make it challenging to effectively communicate your thought process. If the interviewer finds it hard to follow your logic, it might create a barrier between you and a successful interview.
• Risk of Errors: Complex solutions increase the likelihood of errors, both in the initial implementation and during subsequent iterations. Keeping your solution simple reduces the chances of introducing bugs and makes your code more reliable.
• Time Management: Coding interviews are often time-constrained. Spending excessive time on an intricate solution may leave you with insufficient time to address other aspects of the problem or to optimize your code.

Mistake #4: Ignoring Testing

Now, let's talk about testing—something we do in the real world and, surprise, should definitely do in a coding interview.

Once you have your solution written, don't rush past the testing phase. You can take a few approaches here—try out custom inputs, walk through your solution verbally, or do a quick spot-check to ensure your code behaves as expected.

Consider scenarios like an input comprised solely of negative numbers, an empty input, and many other cases. Remember, think of how to “break” your code. Systematically examine your code, line by line, testing its responses to different inputs. This approach helps you identify and address any issues in your solution.

Interviewers will be watching you to see if you test your solutions. By dedicating time to test your code, you not only showcase your problem-solving ability but also set yourself apart from the competition.

Mistake #5: Poor Communication

Communication is one of the most important skills a software engineer can learn, I would argue that it’s just as important as coding skills.

In the real world, software engineers work on teams, working with various people with different backgrounds and roles. In order to work effectively you have to know how to communicate properly with your colleagues.

Which is why interviewers will be looking to see how you communicate your ideas during the interview. The worst thing you can do is stay silent and code your solution. Even if you get the right answer the interviewer doesn’t have any insight into your thought process.

Always ask questions if you’re unsure about something, and voice your thoughts out loud to keep the interviewer on the same page.

Bonus points if you can compare multiple solutions and explain why you’re choosing a particular one.

For example, lets say one solution is faster but introduces more space complexity, make this known to the interviewer. Even if you don’t go with that solution just the fact that you’re aware of it will go a long way.

Your goal should be to keep the interviewer on the same page as you at all times.

Closing Thoughts (Plus Bonus Tip!)

Now that you know the top 5 mistakes commonly made during coding interviews, you have the knowledge to avoid these mistakes. But it’s easier said than done, it takes practice.

So, here's a bonus tip: practice how you'll interview. What does that mean exactly? Well, it goes beyond just solving coding problems. It means putting these tips into action—speaking your thoughts out loud, asking clarifying questions, rigorously testing your code—really immersing yourself in the process.

I know it might feel weird to talk to yourself but you need to get into the proper headspace so when it comes time to do an actual interview it’ll be like second nature.

Don’t forget to time yourself too, I recommend 30 minutes to an hour to solve a coding problem (depending on the difficulty). Remember to start by working out a brute force solution, then focus on optimizing the brute force into your final solution.

Again, you need to mimic real-world coding interview scenarios. Which is why mock interviews can also help. There are various free and paid services online that can help you with mock interviewing, or you can even just ask colleagues at work or school to mock interview you (make sure to return the favor if you do).

By focusing on fixing these 5 mistakes, I guarantee your overall coding interview performance will improve significantly.