I have this recurring dream where I’m in a play and I’m on stage having never learned the lines or ever practiced. I would imagine that this is a fairly common dream. For me, I think that it stems from my acting class sophomore year of college where I forgot all the words to the part I was playing. I’m over it, but the dreams still persist.
In my case, my issue was forgetting my lines, but lines aren’t all you have to remember when you’re in a play. You have to remember your cues and stage directions. If it’s a musical, you have to remember the lyrics and melodies for the songs. Although the lines may seem like the most critical part to get down, you can’t get away without practicing all aspects of your role, even if your lines are firmly committed to memory.
In the same way that acting isn’t all about memorization of your lines, acing your coding interview is not all about how much you have studied. A coding interview is a performance, and you have to practice all of the parts. This article discusses the five things that you might not think about when studying, but are as critical to your interview success as pure knowledge of algorithms and data structures.
1. Practice on a whiteboard
Have you ever written code by hand before? If you did, was it a good indicator of your coding ability? Unless you do this all the time, I’m guessing it’s not. There are a lot of things we take for granted when typing code into an IDE. There’s syntax highlighting, automatic spacing, error checking, and more, and that’s not even counting the fact that you don’t need to have good handwriting. If you don’t have experience writing code by hand, it’s sort of like the perfect storm, with all these complications arising at once: You spend all of your time remembering whether you need a static
or what the proper syntax for a do-while
loop is rather than showing off your ability to write complex algorithms.
In our interviews, we really want to be able to show off our coding abilities and not get bogged down in the minutia. At the same time, we can’t ignore the minutia since we want our code to be complete and correct, so that leaves us with the option of practicing until writing code by hand becomes as easy to us as writing on a computer. When you do practice questions, try writing them on a piece of paper. If you have a whiteboard, that’s even better, since your interview will most likely involve writing on a whiteboard. Once you’ve solved the problem you can then type it into your computer and compile it to see if you made any mistakes. The more you practice, the easier it’s going to be when interview time comes, and the more you can focus on showing off your skills.
2. Practice debugging by hand
Your code can be as beautiful as sunsets and rainbows, but if it doesn’t work, it doesn’t work. A big component of any interview is showing your interviewer that you’re careful with your work and check yourself. It’s not your interviewer’s job to point out if there are bugs in your code, so you shouldn’t expect them to do it. Interviewers want to see you check your code to make sure that it’s correct, because they don’t want you coming to work for them and then committing buggy code.
Your code can be as beautiful as sunsets and rainbows, but if it doesn’t work, it doesn’t work. Click To TweetIn every interview, no matter how simple the code is, you should go through it manually and check that it’s correct. You don’t need to go through a lot of examples, and you don’t want to take up too much valuable time, but verifying that the result is correct is important, as well as showing the interviewer that you’re careful and cognizant of edge cases. Testing your code is pretty straightforward, but is also a good thing to practice and get used to. Simply walk through the code line by line as if you were the computer and “execute” it. Say what the variables are equal to on each line, follow the control statements, and finally see that the output at the end is what you expect it to be.
This may seem trivial, but it’s a really good thing to practice. Particularly with more complex code or code involving recursion, it can get complicated very quickly, and the more second-nature hand-testing your code is by the time you show up for your interview, the better.
3. Talk through your code as you go
Your interviewer isn’t a mind reader. I know, shocker, right? This is important to remember though. What your interviewer is really looking for during the interview is how you solve problems, and if you don’t talk to them, there’s no way that they can know what you’re doing or the way your mind works. Remember those math tests in grade school where you lost points if you didn’t show your work? Well this is exactly the same thing. For all they know, if you don’t explain your thinking you just memorized the solution to the problem beforehand.
The way to get around this is to not only talk about what you’re going to do, but talk while you do it. As you’re writing your code on the whiteboard, explain what you’re writing. This isn’t easy, though. Talking and writing at the same time is difficult no matter what the circumstances, and the pressure of an interview doesn’t make this sort of thing any easier, so be sure to talk out loud and explain what you’re doing as you’re solving practice interview problems. You can even do the problem for someone else and see if they can follow along.
4. Write clear, concise code
The subtitle of this section can be “think about what you write before you write it” or “you can’t ‘insert new line above’ on a whiteboard.” Really just have a plan for what your code is going to look like before you start writing it. Think about what variables you are going to need, because while it isn’t the end of the world if you have to add a line later, it clutters up the whiteboard and makes it harder to read.
On a more general level, just write good code. You want to show that you think about what you’re doing and don’t just ‘code-vomit’ onto the board. Try to choose good variable names and proper conventions for whatever language you’re using. Spacing should make your code as legible as possible, and be consistent about whatever style you choose. If you want to open your curly braces on a new line I won’t stop you, but if you insist on doing that, at least do it everywhere.
Finally, write legibly. My handwriting is a mixed bag. I can make it look neat if I have to, but usually it’s kind of a mess. Even if you have the worst handwriting in the world, though, your interviewer still needs to be able to read your code. If you have to write more slowly, then so be it, but at least make sure what you write is legible to people other than you.
5. Do practice interviews
There’s a lot of pressure when you go into an interview. Going into an interview without practicing would be like being on stage without knowing your lines. Maybe you’d do fine (I usually seem to do okay in my dreams), but why not stack the cards in your favor?
The best way to stack the deck is by doing practice interviews. There are several ways you can do this. If you have a friend also looking for jobs, you could take turns interviewing each other. There’s a lot you can learn just by taking other people through interview questions. There are online services like Pramp although I can’t say I have any experience with those, personally. A lot of CS programs at schools will do practice interview sessions as well, so it’s worth checking out if your school offers anything like that.
Finally, I also offer one-on-one tutoring and practice interviews, if that’s something you want. If you want to learn more about the tutoring that I offer, you can head over to the Tutoring page on this site!
In the end, how you do in your interview is all about how you prepare, but simply studying theory isn’t all that matters, just like knowing your lines in isolation doesn’t make you an actor. You have to be able to communicate your thoughts in a clear way and demonstrate in less than an hour that you’re a great software engineer and would be a valuable addition to their team. If you take the time to practice all of these non-technical parts of your interview, it’ll give you the best fighting chance to show off your skills. Rather than Hayden Christensen, you’ll be Meryl Streep.
So today, I want you to pick at least one of these techniques and apply it to your interview practice. In the comments below, let me know how it goes for you. Which tip was the most helpful? What was the hardest one for you to actually do? Comment below and let me know!