How to Prepare for Your Coding Interview
A friend who was anticipating her first technical interview asked me how to prepare for one. This led to me barraging her with the following wall of text – which I’m told was quite useful. Now that I have this blog, I figured I could share my advice with others.
As a disclaimer: 1) Every company, interviewer, and individual interview is going to be different. 2) This is simply my personal advice – as a current undergraduate student – based on what I’ve learned from my experiences, seminars, and talking to recruiters. So take what you read here with a healthy dose of skepticism.
Without further ado, this is what I have to say for someone preparing for their coding interview:
Hey, good luck on your interview! Some essential tips that come to my mind would be:
1) First off, it’s often easy to feel like your interviewer will be constantly examining you and to get nervous about making small mistakes. However, in my opinion interviewers can be quite understanding, they don’t expect you to be perfect. The interview is a two-way conversation, not a lecture you’re giving, and so they’ll likely give you hints or ask leading questions. Just treat them (respectfully) like a peer / co-worker that you’re solving a problem together with, because that’s essentially what they’re looking for.
2) At the start of the interview, I would check with the interviewer to see if they’re expecting completely correctly-syntaxed compiling code or simply pseudocode (usually somewhere in the middle, but depends on the interviewer, I’ve had a range of these).
3) Make sure when you’re first told the problem, before you dive in, ask clarifying questions to ensure you fully understand what’s being asked, e.g. what format the input/outputs are in, any obvious edge cases, etc. Interviewers have said this is something they check for.
4) Then I like to visualize the problem – see if you can draw it on a whiteboard, and think how you could maybe solve a simple case by hand. Check that you know how to get the expected output for a test case they gave.
5) Now think about what a naive solution to the problem would look like, telling them “I know this would be inefficient but to start off I think…” so you have something to work off of.
6) Throughout the whole process make sure you’re talking them through your thinking process. It’s okay if you feel like you’re rambling and some sentences don’t make sense, but you want to convey to them what you’re thinking about. You can pause to think quietly for a moment at the beginning if you need to, but after that don’t try to think through everything quietly, because then they’re not getting any “signals” (their lingo) from you.
7) After having a naive solution in mind (I wouldn’t write it down at this point to save time, but you’ll have it as a backup) try to think about how you can optimize it. Make sure you bring up what the Big-O of your current algorithm and any alternatives would be.
8) Keep in mind that hashmaps/dictionaries often come in handy for their constant time lookup when you’re trying to optimize an algorithm.
9) After you think of your algorithm and write down the code, you should trace through it with a couple test cases, definitely try to cover edge cases too if you can, and see if it works. It’s common to miss an edge case, and you’ll think your code works, but then the interviewer may say “are you sure…?” at which point you should double down on checking those edge cases because they’re telling you that you’ve missed something.
10) Going off of #6, doing whiteboard interviews and talking through your thinking isn’t something most people are used to, so it’s very highly recommended to practice it, maybe alone or preferrably with a friend who simply listens as you explain the coding problem to them.
11) You can watch videos online to get an idea of what good technical interviews can look like. Some companies like Google and Facebook also have their own online resources and tutorials to help you prepare for their interviews.
12) To get better at the types of coding questions you’ll see, it’s a good idea to do some practice – the most commonly recommended resources are Leetcode (website) and Cracking the Coding Interview (book). Going through the book would probably take too much time right now, so keep that one in mind for the future.
Hope this helps!