Interviewing for a software engineering position isn’t like interviewing for most other jobs. Companies usually ask you to write code at a whiteboard, on the spot, while your interviewer watches. It’s hard. Even excellent engineers often struggle to perform.
But you can learn how to beat the coding interview. How? Well, you could spend hours and hours practicing, making lots of mistakes, and slowly learning strategies for fixing those mistakes . . . or someone could just tell you the mistakes you’re going to make and how to fix them.
Let’s do that. Here are the four most common coding interview mistakes, and how to fix them.
1. WRITING CODE BEFORE FULLY FORMULATING YOUR ALGORITHM
So there you are, talking with your interviewer about the function she’s just asked you to write. Things are going fine. You don’t have an answer yet, but you’re throwing out some ideas and seem to be making progress…
You take a glance at the whiteboard and notice it’s empty. You check the clock—it’s already been 10 minutes! Suddenly you feel like you’ve made no progress at all. Panic sets in.
So you start writing some code, even though you don’t know yet what that code is going to do. Maybe you write the method name, add a few arguments . . . perhaps you throw in a loop, because you’ll probably need a loop, right?
Now you have two problems:
- You have some half-baked code that probably already has bugs.
- You still don’t have an algorithm!
You’re worse off than you were when you noticed the empty whiteboard.
How to fix this: Finish designing your algorithm before you start writing code.
If 10 minutes pass and you’re feeling stressed that you haven’t written any code yet … relax. Understand that algorithm design takes time. Your interviewer might expect you to spend 10, 15, 20 minutes designing your strategy before you start coding.
If the empty whiteboard is stressing you out, put it to use by diagramming your thought process! Which leads us to our next common mistake . . .
2. DOING THINGS IN YOUR HEAD INSTEAD OF ON THE BOARD
Candidates like to do this thing where they recede into their minds. Their eyes wander up and to the left and they move their lips silently while shuffling around invisible data points with their fingers. They’re drawing diagrams in their heads.
It’s a natural thing to do. But it’s so easy to get lost when the diagrams are jumbled up in your head.
How to fix this: Do your diagramming on the whiteboard.
It’ll feel like you’re taking longer, but overall you’ll actually save time. That’s because you’ll spend less time losing your place and getting confused. Trust me.
As a bonus, it’ll be easier for your interviewer to follow your thought process.
3. GETTING LOST IN THE DETAILS AND LOSING YOUR PLACE
How many times has this happened to you? You’re coding up a long procedure. You add an “if” statement. You realize you’re not sure if you want a “<” or a “<=”. So you dig in. You try running your code with some test inputs. You tweak a few things. Finally, you’re confident that the right answer is “<”.
Then you have that moment. “What was I doing again? What was the next step?” Uh-oh. You’ve lost the forest for the trees. This happens all the time in coding interviews
How to fix this: Get your whole algorithm down first, then debug it.
As you’re writing, when you come across a spot where there could be a bug (e.g. “Should this be a ‘<’ or a ‘<=’?”), just put a checkmark in the margin and keep going. Come back to it later.
This is kinda like the advice I gave for mistake #1: finish designing your algorithm before writing code. Putting these together, you end up with 3 distinct steps:
- design your algorithm
- write your code
- debug your code
Don’t move on to the next step before finishing the last!
4. USING NON-DESCRIPTIVE VARIABLE NAMES
People do this for the same reason they draw pictures in their heads—it feels like it’ll be faster.
But it’s not. If all your variables have useless names, you’re going to end up spending more time un-confusing yourself (and/or your interviewer).
How to fix this: Invest time in coming up with really descriptive variable names.
How do you come up with descriptive variable names? Think of it this way: variable names articulate helpful information that isn’t already obvious in the code. This is easiest to see with an example.
Suppose we had this line:
difference = price1 – price2
These are poor choices for these variable names. Look at difference. That variable name expresses the fact that the variable represents the result of a subtraction—something that’s already obvious in the code itself. We’ve squandered the opportunity to express some additional information with that variable name.
Additionally, it’s not clear what’s different about price1 and price2. This is important, because we’re taking price1 – price2, and not the other way around! This is one of those spots where in the heat of a coding interview, you’d have to ask yourself, “hmm, is it price1 – price2, or price2 – price1? Let me look back up the code and try to remember which one’s which . . .” Yikes.
Instead, we could say:
profit = sell_price – buy_price
Now we know why we’re taking a difference: because it represents our profit. And it’s obvious which direction our subtraction goes: for a positive profit, we’ll sell for more than we bought for. So it’s sell_price – buy_price.
There you have it. The four most common programming interview mistakes you’ll probably make even though I told you not to.
You could read a million articles like this, but at some point you’re only going to get better with practice. So grab a set of practice problems, a whiteboard, and a buddy . . . and start practicing!
 (1).png)
