Top 10 Mistakes Made During the Coding Interview and Preparation

There’s a misconception among software engineers and developers that you’re supposed to write perfect code in technical interviews.

This belief creates a lot of pressure and makes people feel anxious about technical interviews. But in reality, no one expects you to write completely correct, let alone perfect code on your first attempt.

Still, keep in mind that there are different types of mistakes you can make — some acceptable, some, well, not so much.

Mistake #1: Coding on a Computer

The first mistake is practicing the code on a computer because you feel comfortable. In a coding interview, most of the time you won’t have a computer. You will have a whiteboard or even a piece of paper. So practicing in an environment similar to the actual environment is a good preparation tactic.

You should not practice too much on the computer. As you start writing you may find that your handwriting is slow, writing variable names, method signatures and so on will take a lot of time.


Use a pen and paper to practice coding problems.

Mistake #2: Not Rehearsing Behavioral Questions

The second mistake is not rehearsing for behavioral questions. It is important to make a good first impression within the first five minutes. The first impression matters a lot. You must be able to tell your story in a compelling and interesting way.

Prepare three to five stories that you can talk about to demonstrate your leadership and technical skills. Regardless of what questions they ask lead them into your stories. Prepare for questions such as:

  • Tell me about a technically challenging situation that you faced and how you resolved it.
  • Tell me about a situation where there was conflict in your team and how you dealt with the situation.
  • How do you handle a difficult co-worker?

It takes time to come up with a good story. Your story must have takeaways that demonstrate your strengths. So come prepared with good stories.

It is about the cultural-fit in which traits like initiative, collaboration, willingness to accept feedback, conflict management, consensus building, learning from failure, growth mindset, a get-it-done attitude are highly valued.

Don’t underestimate this portion. It is not technical, but it can swing your interview. The key is that many candidates pass the white boarding portion to some degree, but your behavior can swing the interview your way.

  • Are you a go-getter?
  • Do you have initiative and eagerness?
  • Are you able to manage conflict and collaborate with cross-functional teams?

Preparing a number of stories that addresses these points to ensure you pass this area with flying colors. The story consists of 3 points. The challenge, what you did and the result.


Do not go into the interview and wing it, because it will take time for you to come up with a truly inspiring story.

Mistake #3: Not Taking Any Mock Interviews

The third mistake is not taking any mock interviews. It’s important to take mock interviews. Because, you have to communicate well. This requires practicing how to communicate while you’re coding in an interview setting.


You might be nervous during the interview, but if you've practiced it several times you'll get good at it.

Mistake #4: Memorizing the Problems and the Solutions

The fourth mistake is trying to memorize the problems and its solution. This is an impossible task because there are thousands of questions that can be asked in the interview.

Study as many different algorithms as you can so that none of them will throw you off guard. When you see something about a tree traversal using hashmaps or iterative tree traversal, it should not throw you off guard. You should say: “Oh yeah, I’ve seen something like this before”.

Instead of analyzing the problem to solve it, if you are trying to remember the memorized answer, it can be harmful. Because you’re not applying your problem solving skills to solve the problem.

Your ability to analyze the problem is very important. If you can give a good analysis on time, space, data structure usage and right alternatives, even if you didn’t complete solving the whole problem it may still be good enough.


It's about the thought process and not necessarily about whether you can solve the whole problem.

Mistake #5: Being Silent While Solving the Problem

The fifth mistake is not solving problems out loud. Before you start writing the code, you can take time to think and then communicate your thoughts to the interviewers.

They care about your thought process, you will be checking off one of the evaluation criteria of the interview performance. They can guide you in the right direction, if you’re going in the wrong direction. So it pays you to think out loud.


Lack of communication means lack of analysis. You must talk about tradeoffs, time-space complexity, alternatives you are considering such as recursive vs iterative solution and so on.

Mistake #6: Rushing into Coding

The sixth mistake is rushing into the coding part too soon. You’re a few minutes into the interview. You’re talking about the problem with your interviewer, batting around some ideas for how to get started.

Suddenly you have this sinking feeling that a lot of time has gone by and the whiteboard is still blank. You decide it’s time to get moving. Even though you don’t know yet what your code is even going to do, you start writing it anyway.

And then you realize you’re sort of back to the drawing board. Because you still have to figure out what your code is going to do. But now you have all this half-baked code on the board, which might already be pointing you in the wrong direction.

Instead, when that instinct kicks in, just pause. Take a moment. Breathe. Know that worrying about time isn’t going to make you move faster. You could even say out loud, “I’m starting to feel like I should start writing code soon, but I know it’s no use to start writing code before I know what it’s going to do.”

Just get back to the problem at hand and keep batting around ideas for how to solve the problem. Play around with a sample input on the whiteboard. Draw a picture of the data structure. Brainstorm. Trust that you’re not supposed to know the answer right away. That’s what makes it a good coding interview problem.

When a new problem is presented, make sure you communicate your solution and get a clear go ahead from your interviewer before you hastily attempt to code.

If you don’t plan your approach, you will most likely get stuck at some point. Getting stuck is fine, but you don’t want to realize later on that you wasted valuable time coding something that doesn’t solve the problem.


Make sure you plan your algorithm before you start coding. Discuss the solution with the interviewer and get a clear go ahead to write code.

Mistake #7: Sloppy Code

The seventh mistake is sloppy code. This is related to rushing to code. Sloppy code implies confusing variable names and syntax mistakes. You want something that’s beautifully written, cohesive and concise which is easier for your interviewer to understand.

Often time’s interviewers will take a picture of your solution. It gets transcribed into a document so that it can go to the hiring committee who can review your code.

Take some time to clean up the code. If at the very end, you have an algorithm and you think that it’s pretty good and you kind of have the interviewers’ approval on that, then, take a minute or two to cleanup.


Take a little bit of time to clean up and make sure that the code looks good. It only takes a minute to clean up the method signatures and check the input and output parameters. If you don’t, they will think that is the best you can do.

Mistake #8: Not Revising Your Code

The eighth mistake is not revising your code. Often times, after finishing coding you may still have syntax errors. Correct any errors that you find. It may sound nitpicky, but it’s still important.


Fixing any syntax errors shows that you are detail oriented to the interviewer.

Mistake #9: Fixing Mistakes Carelessly

The ninth mistake is fixing mistakes carelessly. Often times this is related to sloppy coding or rushing into coding. You start coding and then you realize there are some edge cases missing. You add an if statement to fix that edge case.

There’s nothing worse than when you fix one error and then the interviewer asks you about another case. You fix that and then they ask you about another case. You don’t want too much help like that because then the interviewer will think you’re sloppy and careless. Too many careless errors will sink you.

So, when you see a mistake, fix it, take a step back, take another quick look. This is about knowing what you’re doing and being able to comprehend your code and being quick at it.

Fix anything else that needs to be fixed and then you can say, “Okay, I think this pretty much does what we’re looking for here”. This is the general gist of the algorithm. You’re not guaranteeing that the whole thing is perfect.


Fixing mistakes the right way demands the ability to view the big picture of the solution. You must be able to see the forest instead of focusing on the trees.

Mistake #10: Giving Up Easily

The last mistake is giving up too easily. When you are given a problem in the interview, you say: “Oh, I don’t know how to do this. I give up, I can’t do this”. Part of the interview is about getting signal from you.

So you’re supposed to struggle a little bit. Any positive self talk that keeps you working through the problem is a good tactic. If you don’t worry about the result and consider this as an opportunity to learn as much as you can in the interview, you will be in a better position to tackle the problem.

So, take a deep breath, relax and just do your best. At first you may panic, if you start analyzing the problem, the interviewer sometimes might give you hints. Sometimes you might get an epiphany. You can gain momentum and confidence as you work through the problem. So, don’t give up that easily.

Usually in the first few moments when you hear the question, there’s a bit of fear about whether you know this one. As your brain is trying to figure out, what could this be? The more you get into it, the more you start to realize, okay, you should have this one.

Most of the questions are not supposed to be very complicated. It’s not going to use some crazy algorithm and crazy data structure that you’ve never heard of before.

Whatever the question, you should be able to accomplish using what you know with stacks queues, hashmaps, tree traversals, arrays and so on. You just put these basic building blocks together.


The interviewer may give you a harder question to see how you struggle with it and how you learn than if they give you a question that you know already.


Leave a comment

Please note, comments must be approved before they are published