Coding Interviews: Things I learned to make the most out of a broken system
About a year ago, I was stupid enough to think that it was a good idea to apply to thirty or so companies for my first full-time software engineer job. So I did.
That was probably not the best idea I’ve ever had. In fact, I endured through about 25 interviews in a month and missed five out of ten weeks of fall quarter for onsites. Even though my life kinda sucked during this time, I learned some very valuable things about interviewing that helped me through this process, and I’d like to share what I’ve learned with you.
Don’t get me wrong; I really, really hate how coding interviews are conducted. I honestly think that whiteboard interviews and the canonical “detect the cycle in the linked list” problems are by far not the best ways to judge the technical abilities of a candidate. If I could transform the system right now, I would. But since I can’t, the most I can do is teach you how to make the most of a broken system. So without further ado, here’s my list:
Always bring a pen and paper to your phone interviews.
Phone interviews can be nerve-wracking. It’s a common mistake to go into these interviews with nothing but your phone and laptop, and then to go straight into coding the second the question is asked, only to blank out minutes later when your initial instinct goes awry.
SLOW. DOWN. ALWAYS TAKE OUT A PAPER AND PEN AND DRAW OUT A SOLUTION BEFORE YOU CODE. Since your interviewer probably won’t be able to see your diagrams, explain your thinking as you draw. Not only does this force you to think logically (a surprisingly hard thing to do when you’re under pressure), but it’s also quite calming and helps alleviate some anxiety.
Use a comfortable set of headphones with a good microphone.
Speaking of phone interviews, one of the things that trips me off when I’m in a phone interview is when I’m trying to solve a problem, but I’m too distracted by my ear buds slowly slipping out of my ears. Or when I have my cell on speaker phone, and half of the time is spent asking my interviewer “Sorry, can you say that again?”
Nevertheless, you’d be surprised at how much more pleasant a phone interview is when you use quality ear gear. I personally use Sennheiser 429s, but you can use whatever your heart desires as long as your headphones are comfy and has a usable mic.
It’s such a simple way to improve your interview experience, but trust me — it’s absolutely worth it.
It’s just a conversation between two engineers.
If you have an interview in a couple hours, this is probably the most important thing to remember: You’re not in an interview. There’s another engineer out there who called you for help on a problem, and you both try to solve it together for an hour before your engineer friend has to go. It’s just a conversation.
Seriously, having this kind of mentality when going into an interview helps so, so much in being relaxed, and having a little fun too!
So in your next interview, remember that you’re not really in an interview. It’s just two engineers trying to solve a problem together.
Have interview anxiety? Do so many of them that the anxiety fixes itself.
If you’re like me and suffer from interview anxiety, this is probably the most valuable advice in this entire article. You could study your little heart out and know everything there is to know about trees and tries, but it’ll all be a waste if you’re so nervous that you mentally collapse in an interview.
Solution? Do so many of them that you become desensitized to the pressure. Apply to every company you’re interested in, doesn’t matter if you think you’re not qualified (but for the love of God please don’t apply to thirty companies).
I bombed my first couple technical interviews out of anxiety, but since then I became more used to the feeling of being interrogated on a coding problem.
Being fearless in an interview isn’t something you’re born with, it is learned. And quite frankly, it’s very quick to learn.
After about three or four consecutive days of interviewing, I stopped getting nervous. I stopped getting anxious. It’s a truly glorious feeling.
Prepare for your interview by getting in the habit of coding every day and practicing interview questions.
You can be the most confident and fearless programmer on Earth, but you won’t get far in interviews unless you know your shit.
Where to get preparation material
My instant go-to resources for practice questions are Cracking the Coding Interview (CtCI) and LeetCode.com. When working through problems, if you’re stuck, don’t look at the solutions until you’ve worked on the same problem for an hour. Then look. Once you think you understand the solution, close it up and try to replicate it without looking at it.
Grab a friend to practice with you
Self-studying interview problems is great, but in real interviews, someone else is picking and asking you questions. So, study with a friend! Take turns asking each other problems from CtCI and LeetCode (or whatever other sources suit your fancy), and bring a paper and pen too so each of you can practice writing code on paper. Bonus points if you do your mock sessions in a small, quiet room, similar to the environment you’d most likely be in during a real interview.
Have a deep understanding of the most common questions
There are some classic interview questions that get asked over and over again. And it’s incredibly easy to prepare for them.
Here’s the list: http://www.programcreek.com/2012/11/top-10-algorithms-for-coding-interview/
I’ve personally been asked the Linked List Cycle problem at least three times during my time interviewing. Questions like these easily weed out those who don’t prepare (which is most people, actually). So just do them and you’ll already have the upper hand.
Keep track of the problems you do
Throughout your studies to become a master at interviews, you’ll encounter lots of problems. You don’t want to forget these problems after you’ve solved them. So keep track of all the problems you do in a folder (I separate my questions by type, such as Linked List, Stack and Queues, Dynamic Programming, etc.). You’ll accumulate lots of problems over time, and it’s always good to look back at problems you’ve seen before to make sure you still know how to solve them a month later.
But don’t neglect low-level Operating System questions.
I really should have paid attention in my Operating Systems class. Once final grades were out, I just shrugged off my mediocre “C” and figured I’d never need to know about process scheduling or deadlock prevention unless I end up working with low-level programming as a career (which I never, ever will). Well… I regret thinking that. I didn’t get a whole lot trivia questions on OS, but I got enough of them and half-assed them enough to realize that these concepts are important to know for a technical interview.
So, don’t be me. Pay attention in OS. Brush up of this stuff before an interview.
Sometimes your interviewer sucks.
There are so many things we can control that affect whether or not you do well in an interview. Unfortunately, who we have as an interviewer is not one of those things.
Don’t get me wrong — most of the interviewers I’ve had have been fairly good at communicating the problems and nudging me in the right direction when I’m stuck without giving away the answer.
But I’ve also had interviewers who just… aren’t great interviewers. These are the people that, after they ask you a question, pretty much put their speaker on mute or — for in-person interviews — sit there quietly on their phones. They don’t give you any feedback when you’re solving the problem, and they seem to just judge you silently as you struggle to find a solution.
I try to make situations like these a little easier on me by making sure it’s rarely silent. I think out loud, periodically asking the interviewer if I’m on the right track to force them to pay attention to me. I don’t think there really is any other way to ease up the tension and silence except by doing that.
Conclusion
Whew, you made it through! Give yourself a pat on the back. The technical interview system may be broken, but that doesn’t mean all hope is lost. However, it’s not enough to just read this article and you’re magically an interview wizard. You want to be calm and collective and know what you’re doing at interviews? Go out there and do them.
