Five Tips on How to Game Plan for a Coding Interview

Who actually likes interviewing? Not this guy. Thankfully, I haven’t had to change jobs in a while so I have spent the better part of this decade conducting interviews.  Along the way, I’ve also had the opportunity to join and even chair hiring committees, giving me insights into some of the less obvious considerations that go into hiring decisions. My goal here is not tell you whether you should go with LeetCode or HackerRank and how much time to spend on them every day. Or it's not to share some new perspective that will magically make interviewing so much more enjoyable. I simply want to draw attention to some of the softer skills that interviewees often overlook but can be deciding factors in hiring decisions.  Of course, none of this is exact science, but I can confidently say that doing these things is more likely to leave your interviewer and the hiring committee with a better impression of you.

Solid introduction: Every interview starts with one and you should make sure you don’t show up planning to wing it.  A good rule of thumb is to keep it under two minutes and focus on the two most important things: who are you and why are you here today?   Make no mistake. You are here to sell yourself to the interviewer so be sure to tee things off with a strong elevator pitch. Ideally, learn a little more about the company and work that into your story so it's clear to everyone why you are interviewing. A strong introduction projects confidence and sets the right tone early, putting you on solid footing with the interviewer.

Clarifying questions:  Ok, that is an interesting interview question.  Interviewees often don’t realize this, but a lot of interview questions are left purposely vague to mimic real life problems. If you jump into solving the problem without asking for clarifications where needed, it sends a very strong signal that you are impulsive and don’t think problems through.  More than just about anything else, I’ve seen this sink many otherwise promising interviews during hiring committee deliberations. Most engineering leaders simply don’t have any tolerance for engineers who shoot first and ask questions later so be sure to ask first.  

Think out loud: Now that you have all the clarifications you need, you can finally jump into the implementation. Wrong! You have only addressed one part of the equation so far; well, the problem itself is finally clear.  Now you have to address the solution or ideally solutions by walking your interviewer through your thought process.  This is very important for two reasons: First, it shows off your ability to explain your thoughts clearly absent any code which is a very important skill for any engineer.  Secondly, it gives you the opportunity to get early feedback from your interviewer on the approaches you are considering so you don’t have to waste the better part of the interview digging yourself into a hole.  The interviewer is a valuable resource so use them at all times to make sure that you are headed in the right direction.

Code out loud:  We are now finally ready to start coding. Well, this is going to sound familiar but be sure to continue explaining your steps as you go through the interview so the interviewer can both follow what you are doing and give you that valuable feedback, especially if things go off the rails. If you just put your head down and code away, at best you are coming across as someone who does not collaborate well and at worst, you are shutting the door on a much needed life line from a valuable resource. Stay in contact with the interviewer every step of the way and force them to either endorse your work or stop and give you hints where needed.

Take a hint:  What can possibly be worse than stumbling during an interview?  I am sure there are a few things but one that comes to mind is stumbling AND failing to effectively use hints.  This goes hand in hand with the last two tips because you have now put yourself in a position where the interviewer is trying to guide you to the right solution by giving you hints. In a lot of cases, making a mistake is not a deal breaker and you could even turn it into a point of strength if you can demonstrate that you can effectively take feedback and make good course corrections.   That is indicative of your ability to collaborate well so listen closely to what the interviewer is saying and be sure to use every hint to your best advantage. Needless to say, one of the worst things you can do is simply refuse to use the hints because that will most likely leave your interviewer with the impression that you don't take feedback well. Let's try not to do that.

I don’t expect interviewees to be mistake free.  But I do expect them to be effective communicators that can collaborate well and work through what are sometimes vaguely defined problems.  I hope that these tips offer helpful insights into some of the less obvious albeit important qualities we are looking for when evaluating talent. Solving the problems is already hard enough so please use these simple tips to go in with a more polished game plan...and assuming you have done enough coding prep, everything else will hopefully work out.  Best of luck with your interview!