I've conducted many interviews. There are many reasons why I reject people, but there are recurring themes. I want to give a list of the most common problems. A few of these things I once thought were obvious, while others are perhaps less so.

Don't know the basics of coding

This one troubles me a lot.

It should not be a challenge to create lists, split them, and iterate over them. Functions, classes, variables, the basic structures of a language should be no trouble at all for you. Stumbling on these is the quickest way to earn my rejection.

I have zero expectation that you know the entire language, and it's standard library by heart. However, I'm talking about the basics. There's no reason you should be looking up loop syntax during an interview. I've also found that the more somebody knows, the faster they code. Being fluent in a language reduces stress, freeing your brain to think about the problem rather than the syntax.

Perhaps you work with a lot of languages, and many technologies. I understand this. I do as well, and I often forget how to do something in a particular language. It's not an excuse though. If you're picking the language for the interview, you need to review the basics before starting. I know the basics are harder in C++ than Python, but I expect you to know the language you chose.

When I do live coding, I create a cheat sheet for the language. A quick reference of all the things I may need -- I don't want to stumble on a for-loop in front of viewers! You can do the same thing, and then memorize it before the interview. As long as you know the language in advance, there is no excuse. None.

Don't speak, speak poorly, or be disinterested

Interviews are about talking, and it should be no surprise that how you talk is vital.

If I ask an open-ended question, it's because I want more than a few words as an answer. Take the opportunity to talk. Provide short pauses in between some sentences; it gives me time to understand and interrupt if I want.

While you're coding, I expect you to talk about what you're doing. I don't want to read the code on the screen. Tell me about why you've chosen that code, or what your current goal is. If I don't know what you're thinking, I can't help you. I have no desire to sit there and watch you struggle. If you speak up, I can help you focus, and guide you to the right answer. If you don't say anything, you risk wasting time on something irrelevant, or on a misunderstanding of the problem.

Learn how to speak well. I've had some people that said "hmm" and "ah" so often that I had a hard time understanding them. Nobody is expecting world class oration, but clean speech is easier on the listener. You want the interviewer thinking about the meaning of your words, not trying to decipher what you're saying. Practice is your friend here. It doesn't take much effort to make noticeable improvements.

Closely related to speaking poorly is sounding disinterested. It's an absolute turn-off to hear somebody who's dead inside and their job is like a prison. It can also be taken as disrespectful. I'm taking the time to interview you, and I expect you to show some modicum of interest in the process.

Speak clearly and with interest.

Overthink and complicate the question

Interviews aren't long, and all the work you need to do should fit comfortably inside the allocated time. If you have an hour-long coding interview, you'll likely only have 35-40 minutes of coding time. We need time to talk, not only code.

I'm not going to give you a problem that takes too long. Indeed, the initial question I give only requires 10-20 minutes of coding time. I prefer to ask followup questions rather than one big question. However, even when you've been given one substantial question, you have to assume it's solvable in the short interview.

Complicating the problem, asking too many what-ifs, and going off on tangents, will all eat up your precious time. Focus on the problem at hand. Don't look for hidden trickery, nor try to design the perfect system. That is also why vocalizing your thoughts is essential. It gives the interviewer a chance to keep you on track.

Solve the problem as it's given.

Know nothing about your last job

I always ask about previous work experience. Not only general history, but I want to hear about your specific role. I want to hear that you know how you fit into the team. I'll judge your level of interest by how well you can describe the product and the processes involved in developing it.

I'm listening for specific technologies. Great, you were a full-stack developer, but what does that mean? Did you use NodeJS and Angular? How did you communicate with the server? Which database did you use? Moreover, which parts did you actually work on? I want to understand your level of involvement.

If you can't provide specifics, I'll assume it's because you're either inflating your position, or you weren't vested in the project. Either way, it reflects negatively on you.

I also use this information to guide the rest of the interview. If you come across as a top developer, I'll hold back on helpful prompts, giving you more space to work on your own. If you're a newcomer, I'll be more liberal with my help to avoid unnecessary stress.

Write sloppy code

It's an interview. I'm not expecting you to achieve perfectly clean code. However, there's a big difference between acceptable code and sloppy code.

My biggest gripe is poor variable names. Why are you calling the variable n? You're in a live interview and trying to communicate with me. Clear names help me understand your code.

If this is an online interview, or I've given you the equipment, I tend to be forgiving of some formatting issues. Some interviewing editors make it challenging to indent correctly or fix things. But I do see consistency issues, like where the braces and semicolons are.

Rarely have I failed somebody solely due to sloppiness. However, on numerous occasions, I've seen lousy code slow down the interview: either the candidate struggles to understand their code, or I have to ask what's going on.

Insult something or somebody

Just don't do it!

Regardless of your opinion or experience, don't say anything negative about anything. You have absolutely no idea about me, the interviewer, or my background. You don't know what concepts I think are good or bad. You don't know whom I've worked with, or whom I regularly talk to.

Negative points that contradict the interviewer's world view immediately hurt their impression of you. Even if I agree with the point you make, it's not the right time to make it. I'm an open-minded person, but the mere fact you've chosen this time to complain about something reflects negatively on you. I don't want to work with negative people. You're here to promote yourself, not disparage others.

What if you're asked to talk about something bad? These questions can come up, directly as "what's wrong with X," or the silly "What's your worst experience?" This is when you swallow your pride and talk about learning experiences, differences, and group struggles. You talk humbly and focus on the positives. I love when people can spin lousy situations into a positive story. These are people I like working with.

Conclusion: Lots of soft skills

A coding interview is an interactive session. You need to work together with the interviewer. This is true even if your interviewer isn't good. Even interviewers without training will tend to speak and try to help you. Plus, as many criteria on the list are standard social skills, everybody is judging them. It's perhaps even worse for people not trained in interviewing, as they may be less likely to overlook interview stress.

If you've read my book, you'll know that I place a great deal of value on people skills. You can see how many of these failures relate to soft skills. But, if you wish to pass the interview, you still need to have code that solves the problem.

Everything in this article works towards getting a good solution. By ensuring the interview is smooth, you make the most of your time. You get helpful feedback and can focus on writing the right code. I know some interviews will be rocky regardless of what you do. But still, try your best, and definitely, don't make them any worse.

If you happen to be making one of these mistakes? Fix it. These are all skills that can be practiced and improved.

Read my book What is Programming? and learn what it takes to be a great programmer. I look at the People, the reason software exists, the code at the heart of that software, and you, the person behind the keyboard.