4 Common Coding Interview Mistakes (And How to Avoid Them)

4 Common Coding Interview Mistakes (And How to Avoid Them)4 Common Coding Interview Mistakes (And How to Avoid Them) Ah, the dreaded whiteboard coding einstellungsgesprch . Where youre 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. Its 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 Ive seen hundreds of candidates make. Let their mistakes be your unfair advantageNothing stops a coding interview dead in its tracks like a candidate saying, I dont really know how big O notation works. If you have any weaknesses here, this should be priority number one. Make sure youre 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 ge t 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.Its a very easy mistake to make. Youre chugging away at a problem, and your interviewer interrupts you to point something out. Okay, I see were doing a post-order traversal of the tree. And you have no idea what that means. But your first instinct is to just hope its 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 youve gotten away with it. But it comes up again later. So, why did you choose to do a post-order traversal? Uh Youre busted. Not only do you not know what the heck post-order means but now you look dishonest . Because saying I dont 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 dont understand, point it out immediately. texas tea 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 dont understand. It makes your thinking sound much more organized. Huge difference between Huh? and What does post-order mean in this context?I see this all the time. Youre a few minutes into the interview. Youre 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 its time to get moving . Even though you dont know yet what your code is even going to do, you start writing it anyway.The fun ctions gotta have a name , right? So you write out a function declaration with a name and some arguments. Thats safe - well definitely need that. Maybe a closing brace at the bottom of the board. And theres going to be a loop in here, right? So lets throw a loop in there. I guess itll loop through that first argument? So you kinda sketch out a loop. Maybe you call a subroutine in there that handles some tricky part youre not sure yet how to handle. Ill write out that function later, you say.And then you realize youre 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, youre 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 isnt going to make you move faster. Lean into the moment. You could even say out loud , Im starting to feel like I should start writing code soon, but I know its no use to start writing code before I know what its 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 youre not supposed to know the answer right away thats what makes it a good coding interview problemAfter 45 long minutes, youve finished writing your code. Whew. You just want to turn your brain off and relax. You look at your interviewer expectantly - youre just waiting for them to say, Perfect Its perfect. But they dont. Instead, they say can you find any bugs in your code? You hope its a trick question, but you begr udgingly look back at your code. You step through each line, but youre not really debugging . Youre just sort of explaining the ansinnen of each line. Youre so hoping that your code is right that youre only seeing what you want to see. Youre not seeing the bugs. So, of course, you miss the bugs. And of course, your interviewer sees them.Heres how you actually debug whiteboard code. Write out a sample input. Something short enough that youll be able to get through the whole thing, but long enough that its 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. Thats right - youre using your brain as the computer processor and the whiteboard as your computer memory. Its tedious, but thats the only way to debug code on the whiteboard. Oh, and once youre done, do the same thing with all the common edge cases. Empty arrays, single-element arrays, ne gative numbers, disconnected graphs, etc.Those are some of the most common coding interview mistakes. If you can avoid them, youll be bounds ahead of most other candidates. Now go groe nachfrage some practice problemsParker Phinney is the CEO of Interview Cake , which makes free guides and online courses on how to pass coding interviews.