Ah, the dreaded whiteboard coding interview. Where you’re thrown in front of a whiteboard, stripped of your usual code editor and hotkeys, and asked to solve a complicated data structures and algorithms question on the spot. Yikes. It’s enough to make anyone a little nervous — even the most seasoned engineers.
Lucky for you, you stumbled onto this post about the four most common coding interview mistakes I’ve seen hundreds of candidates make. Let their mistakes be your unfair advantage!
1. Not knowing data structures and algorithms.
Nothing stops a coding interview dead in its tracks like a candidate saying, “I… don’t really know how big O notation works.” If you have any weaknesses here, this should be priority number one. Make sure you’re 100 percent solid on big O notation. Make a habit of thinking about the big O time and space costs of all the code you write. And definitely get comfortable with logarithms — they come up more than you might think, and they take too many candidates completely by surprise.
Before your next interview, take some time to read up on all the core computer science data structures. Know the strengths and weaknesses of each one. Focus on knowing when you should use each one.
2. Pretending to understand something that you don’t.
It’s a very easy mistake to make. You’re chugging away at a problem, and your interviewer interrupts you to point something out. “Okay, I see we’re doing a post-order traversal of the tree.” And you have no idea what that means. But your first instinct is to just… hope it’s not important. Or hope you can get away with pretending to know what that means. Or something. So you just say, “…Right.” At first, it looks like you’ve gotten away with it. But it comes up again later. “So, why did you choose to do a post-order traversal?” “Uh...”
You’re busted. Not only do you not know what the heck post-order means… but now you look dishonest. Because saying “I don’t know what that means” at this point means also saying “….I, uh, sort of pretended to know what that meant earlier.” Best to nip this kind of problem in the bud before you end up in that situation.
When your interviewer says something you don’t understand, point it out immediately. Lean right in. Because letting them think you understand is only going to make things messy later. Try to be as specific as possible about what you don’t understand. It makes your thinking sound much more organized. Huge difference between “Huh?” and “What does post-order mean in this context?”
3. Writing code before you know what the code will do.
I see this all the time. 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.
The function’s gotta have a name, right? So you write out a function declaration with a name and some arguments. That’s safe — we’ll definitely need that. Maybe a closing brace at the bottom of the board. And… there’s going to be a loop in here, right? So let’s throw a loop in there. I guess it’ll loop through that first argument? So you kinda sketch out a loop. Maybe you call a subroutine in there that handles some tricky part you’re not sure yet how to handle. “I’ll write out that function later,” you say.
And then you realize you’re sort of back to the drawing board, because you still have to figure out what your code is actually going to do — but now you have all this half-baked code on the board, which might already have bugs, or might already be pointing you in the wrong direction. That instinct to “get moving” and start writing code actually ended up hurting you. Because now another 10 minutes has passed, you’re no closer to an algorithm, and you have messy, half-baked code scrawled all over the whiteboard.
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. Lean into the moment. 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!
4. Rushing through the debugging at the end.
After 45 long minutes, you’ve finished writing your code. Whew. You just want to turn your brain off and relax. You look at your interviewer expectantly — you’re just waiting for them to say, “Perfect! It’s perfect.” But they don’t. Instead, they say “can you find any bugs in your code?” You hope it’s a trick question, but you begrudgingly look back at your code. You step through each line, but you’re not really debugging. You’re just sort of explaining the intention of each line. You’re so hoping that your code is right that you’re only seeing what you want to see. You’re not seeing the bugs. So, of course, you miss the bugs. And of course, your interviewer sees them.
Here’s how you actually debug whiteboard code. Write out a sample input. Something short enough that you’ll be able to get through the whole thing, but long enough that it’s not an edge case. Then walk through your code line by line. As it changes the input, actually change it on the board. If it makes new variables, write those on the board as well. That’s right — you’re using your brain as the computer processor and the whiteboard as your computer memory. It’s tedious, but that’s the only way to debug code on the whiteboard. Oh, and once you’re done, do the same thing with all the common edge cases. Empty arrays, single-element arrays, negative numbers, disconnected graphs, etc.
Those are some of the most common coding interview mistakes. If you can avoid them, you’ll be bounds ahead of most other candidates. Now go run some practice problems!
Parker Phinney is the CEO of Interview Cake, which makes free guides and online courses on how to pass coding interviews.