Why do so many tech professionals fail technical interviews despite their background and experience? Contrary to popular belief, it’s not a lack of technical knowledge that is hurting their chances, but their propensity to commit unforced errors.

It turns out that what you don't say or do often matters more than coming up with the right solution when solving coding problems on a whiteboard or a shared screen during technical interviews.

To help you avoid a similar fate, we went straight to the source: We asked three engineering leaders to describe the most common mistakes they see developers and engineers make during technical interviews. Here’s what they said.

Going Radio Silent

The most common mistake candidates make is working through the solution to a coding, systems design or algorithm problem in their heads, noted Zach Newburgh, head of engineering at a startup.

Someone’s thought process is critical because it is indicative of how they work and whether their process is repeatable, Newburgh explained. “In fact, their answer doesn’t even need to be correct.”

Some candidates commit another faux pas by taking their silence a step further. “It may seem like a small thing, but when some candidates stop writing code, they just stand at the board,” noted senior engineering manager Inbar Gazit. “It seems like they are waiting for a prompt from me, which makes me question their confidence.”

Up your chances of success by vocalizing the options you are considering and the approach you plan to take as you work through a problem during a technical evaluation. Also, make sure to let the evaluator know when you’re done coding and ready to discuss your solution.

Making Assumptions

You know what they say about making assumptions, right? Yet some candidates don’t ask clarifying questions or confirm the variables before choosing a programming language, arriving at a solution and writing out the actual code.

You need a clear picture of the problem you’re trying to solve (including the needs of the end user or customer) to design an optimal solution. However, those things aren’t always clear in the initial problem. In fact, some evaluators admit that they intentionally ask vague or tricky questions just to see what the candidate will do.

When given a coding interview question, candidates should start by asking clarifying questions and discussing a few possible approaches with the evaluator before writing code.

Not Building Rapport

Some candidates don’t ask questions or try to build rapport with the evaluator, even when given the chance. Not researching the company beforehand infers that you think all technical environments are the same. Worse, tech pros who lack passion for their work or their organization often jump ship when another job comes along.

For instance, a pair programming assessment gives you the ability to connect and learn from your partner. Seize that opportunity to ask about the nature of the task, the function of the app or feature you’re working on, and how the team normally approaches this type of problem, advised Adrien Fabre, senior software engineer at Dashlane.

“I’m evaluating the entire candidate, including their ability to communicate and build rapport, not just their technical skills,” Fabre added.

From the interviewer’s point of view, your level of engagement reveals how interested you are in the position, the company, and the type of projects you’ll be working on.

Not Asking for Help

Getting stuck won’t hurt your chances; it’s what you do next that counts. Some candidates won’t ask for help when they don’t know the solution to a problem, or they’ll try to fake their way through it.

“I don’t want to work with someone who won’t admit that they don’t know something,” Fabre said.

In fact, research shows that asking for help actually makes you appear more competent to other people and creates better social interactions.

Going Overboard

Trying to impress engineering managers by making your answer or design more complicated than it needs to be can backfire.

For instance, some candidates try to demonstrate how clever they are by introducing an abstraction layer when it’s premature and just adds complexity, Newburg said. Your best bet is to offer a basic solution first, then potentially share some additional ways to optimize.

Not Testing Your Code

Don’t wait for the evaluator to prompt you; start testing and optimizing your code as soon as it’s written. Ninety-five percent of candidates can produce code that works, so that’s not a differentiator, Gazit explained: “The real test is can you make it better, especially the first time around.”

From the perspective of the interviewer, the attention you pay to code quality, readability and performance during a technical interview is indicative of how you will perform on the job.

Displaying a Bad Attitude

Yes, it's a tight hiring market. But no matter how talented you are, you won’t get an offer if you come across as arrogant or difficult to work with.

While its certainly okay to express your honest opinion or preference about a tool or development process during an interview, don’t criticize the questions you’re asked or argue with the evaluator. The bottom line is that most managers and team members would rather work with someone who is willing to learn and has a good attitude than a technical genius with a bad attitude.