6 Ways Even an Experienced Developer Can Fail a Coding Interview

Common mistakes and winning tactics for your next job interview

Published in

Better Programming

7 min readOct 19, 2021

I’m interviewing software engineers every week. Too many of them make the same mistakes at the coding interview and fail to demonstrate their skills at the expected level. As a result, they don’t get a job offer.

That’s sad because any software developer, regardless of their experience, can avoid those mistakes. Here are the ones I see most often:

Jumping straight into writing code
Not taking interviewers’ hints
Overcomplicating things
Picking the wrong programming language
Giving up on solving the problem
Coming to the interview unprepared

Let’s see how these mistakes lead to failing an interview and what you can do instead to pass the interview successfully.

1. Jumping Straight Into Writing Code

Often candidates start coding the moment they get the task. I’ve rarely seen that approach lead to a working solution.

Some developers believe this will impress the interviewers. However, it is far from the truth. Others come up with an idea; often, the wrong one. They don’t see the need to explain it and go ahead with the implementation.

There are three issues here:

It’s easy to miss the key details of the task and pick the wrong approach because of stress.
The interviewers may conclude that the candidate doesn’t realise the importance of sharing ideas and getting early feedback. In other words, the candidate demonstrates poor communication and collaboration skills.
The candidate may appear over-confident or prone to making rushed decisions.

The best approach is:

First, pause for a few minutes to think of a potential solution. Take time to capture all aspects of the problem before proposing a solution.
Then talk your interviewers through the idea to get feedback. You’ll demonstrate good communication skills and a thoughtful approach to problem-solving. In addition, you’ll confirm your idea is viable.

Most interviewers expect you to ask clarifying questions and discuss your approach before writing code.

2. Not Taking Interviewers’ Hints

Your interviewers have seen others doing the same task. They may be aware of one or two solutions and typical mistakes. They may give the candidate a hint to save time by dropping an idea that won’t produce the right outcome. They also may notice the candidate is already on the right track and decide to speed up the process.

When a candidate isn’t taking their hints, interviewers may assume that:

The candidate is too attached to their ideas in general and won’t consider alternatives proposed by others. Such a character trait will make it hard to work with that candidate on a team.
The candidate doesn’t have the right communication skills: not listening well, not taking instructions, and not asking clarifying questions.

When an interviewer is giving you a hint — take it:

If you don’t understand it — ask to clarify the idea so you can see the benefits.
If you disagree, explain your view. There is a chance they misunderstood you. Still, it is best to try what interviewers are proposing if they insist.

Remember that interviewers are usually on your side. They want to hire you as long as they confirm you meet their expectations. Hence, they may be giving you hints and asking guiding questions.

3. Overcomplicating Things

Some candidates seem to think that simple things are not “good enough”. They try to boil the ocean and overcomplicate their solution to impress interviewers with their knowledge.

At one of my interviews, the candidate set up a test suite for their solution. That took a while. The candidate then had to rush to code the implementation in the remaining time. A faster option would be to hard-code the test data in the solution code or pass it using the command line interface. The solution code was just a single function anyway.

When candidates overcomplicate their implementation:

They spend the interview time on something that doesn’t help to solve the task.
They increase the risk of something going wrong and make it harder to debug even trivial issues due to uncertainty whether the problem is in the code or the setup.
They make interviewers think the candidate will be tinkering with tooling and configs in their new role instead of solving business problems.

Here is what to do instead:

Apply the KISS principle in your implementation, avoid distractions, focus on solving the coding problem.
Start with a straightforward and safe step. If you come up with a naive but suboptimal solution — you can refine it later. Feel free to explain that to your interviewers.

4. Picking the Wrong Programming Language

Sometimes, candidates can choose the programming language to solve the problem. In some cases, they select an unfamiliar language or a language that requires too much boilerplate code.

At one of the interviews, the candidate picked Typescript and had to spend too much time defining types and fixing cryptic compiler errors instead of writing actual code. Eventually, we ran out of time. Good old Javascript could have been a safer alternative.

When a candidate chooses a language to impress interviewers rather than to solve the problem efficiently:

They risk spending too much time wrestling with language constructs instead of implementing a solution. That doesn’t help to show their best performance.
They struggle to debug their code.
Interviewers may be unable to tell if the candidate is struggling because of unfamiliarity with the language or inability to code.

The best strategy is:

If you can, pick your most familiar programming language — ideally, the one you use every day. There is no need to increase the risk of failure.
If you are fluent in several programming languages, choose the “simplest” one. For example, if you use C# and Javascript — choose Javascript. If you use Java and Python — choose Python.

5. Giving Up on Solving the Problem

Never give up on solving a coding challenge at an interview. When a candidate does that, interviewers may decide they will be giving up on challenging tasks at work as well. What is more, it is hard to justify making an offer to a candidate who threw in the towel at an interview.

If you get stuck:

Go back to square one and start talking your interviewers through your approach again. You may have a eureka moment.
Ask interviewers to give you a hint.

It’s okay to admit you hit a wall and ask for help as long as you keep searching for a solution.

Please note, sometimes the coding problem allows interviewers to add requirements along the way as the candidate implements their solution. They use this technique to see how far a candidate can get. Asking for a hint in this situation may be expected. If you admit you need help — you may get bonus points for your transparency and openness.

6. Coming to the Interview Unprepared

Some candidates believe they can solve a coding problem without preparation. They write code every day, after all! However, typical coding interview challenges are different from routine software development tasks.

For example, many organisations expect candidates to be familiar with basic data structures, sorting and search algorithms, recursion, etc., to solve the problem.

The issues with coming to the interview unprepared are:

Interviewers may interpret lack of preparation as low interest in the role and won’t recommend hiring the candidate.
Interviewers may be unable to tell whether the candidate is rusty on specific skills (TDD, use of data structures, search algorithms, estimating O(n) complexity, etc.) or unfamiliar with them. They will most likely assume the latter.

To prepare for a coding interview, try this:

Ask your recruiter what to expect and prepare for that. For instance, consider practising with a friend if the recruiter says the interview will include pairing on an existing codebase. If they tell you it will focus on problem-solving — find a website to practice solving coding challenges online.
It never hurts to brush up on basic data structures and algorithms and practice estimating the O(n) complexity of algorithms.

Takeaways

To increase your chance to pass the coding interview:

Spend some time on preparation by solving coding problems and revising on basic Comp Sci in your memory.
At the interview, don’t rush to write code. Think first and then talk the interviewers through your idea.
Never make things over complicated for yourself. Don’t spend time on setting up frameworks, libraries, writing boilerplate code. If you can choose the programming language, pick the most comfortable one for you.
Never ignore hints from your interviewers. Take them on board. If you don’t understand them, ask to clarify.
Never give up on solving the problem. Take a few steps back if you’ve taken the wrong turn or admit you are stuck and ask for help. Pause to think if you feel you need that at any time.

Best of luck at your next coding interview!

More tips for software engineers on how to succeed at the job interview: