5 things you do wrong in every technical interview

Most people who bomb technical interviews think they bombed because they didn't know the algorithm. Sometimes that's true. More often, it's not. The algorithm knowledge was there. Everything around it wasn't.

Here are the five things that actually kill your performance — and none of them are about knowing Dijkstra's.

1. You solve the problem in your head, then start typing out of nowhere

The most common thing I see: the candidate reads the problem, goes quiet for two minutes, then starts typing. When the interviewer asks "can you walk me through your approach?", they say "oh yeah so I was going to do this..." — and explain a solution they've already half-implemented.

The interviewer doesn't know what happened in those two minutes. From their side, you just started coding without a plan. Even if your solution ends up being correct, you've already lost points on communication.

2. You treat clarifying questions as optional

"The array is sorted, right?" feels like a dumb question. Ask it anyway. Clarifying questions do three things: they show you think about constraints before diving in, they can reveal information that changes your approach entirely, and they buy you time to actually think without going silent.

The best clarifying questions are specific. "What should I return if the input is empty?" is better than "Are there any edge cases I should know about?" The second one puts the work on the interviewer. The first one shows you already identified something worth asking about.

3. You try to optimize before anything works

Getting a working O(n²) solution takes ten minutes. Getting a clean O(n log n) solution takes thirty. Spending thirty minutes on an optimal solution with a bug takes the whole interview — and you end with nothing.

Interviewers almost universally prefer: working solution first, complexity discussion second, optimize if time allows. Yet candidates keep reaching for the elegant approach from the start, because they're embarrassed to present anything "naive."

4. You go silent when you're stuck

Silence when stuck is the worst thing you can do. The interviewer can't tell if you're thinking hard or completely lost. They're sitting there watching you stare at the screen, and every second of silence makes the situation worse.

Keep talking. "I'm trying to figure out how to handle this edge case... I'm thinking a stack might work here but I'm not sure... let me try a different angle." This is genuinely interesting to listen to. It also helps you think, because articulating what you're confused about often unlocks the answer.

When the interviewer gives you a hint, take it. Don't resist it or try to prove you would have gotten there. Say "right, that makes sense — so if I think about it that way..." and run with it.

5. You don't test your code

You finish writing, glance over it, say "I think that's correct" and look at the interviewer. This is a mistake almost everyone makes, and it's one of the easiest to fix.

Walk through your code with a concrete example. Out loud. "Okay so if the input is [1, 2, 3], we start at index zero, we check this condition, i is 0 so we..." Actually trace through it. You will catch bugs you missed. More importantly, you'll show the interviewer that you verify your work — which is something they're explicitly evaluating.

You don't need to trace every edge case. One happy path, one edge case. Two minutes total. It's worth it every single time.