Acing the Technical Interview
Technical interviews are the most variable part of the job/internship recruitment process in my opinion. Everything about your tech interview depends on the questions you’re asked, the person (or people) who interview you and your individual coding style. There’s a range of different companies that all claim they have the “perfect” way of knowing who will make a good engineer. A lot of times that means they will make you jump through all sorts of hoops to prove you are knowledgeable enough to be a part of their team.
Related | How to Prepare for a Technical Interview
For everyone who is wondering how to ace a technical interview the most important thing to remember is that your performance in a technical interview does not automatically correlate with your ability as an engineer. I’ve met some of the smartest coders who just bomb tech interviews. Similarly, I know coders who don’t know anything but have had a combination of really lucky interviews and are great at BSing do very well. I view technical interview performance like standardized test performance: it doesn’t measure anything but it’s a hurdle you’ll most likely need to face when getting a job in tech. Technical interviews are a great opportunity to show-off what you know. If nothing else, here are ways to improve your technical interview feedback by applying the following tips and strategies.
Not all technical interviews are created equal. You can have a phone screen, Skype interview, or an in-person interview. A lot of these strategies apply to all three but I’ll also spend some time discussing phone and Skype interviews specifically.
An over-the-phone or Skype technical interview is a little trickier. One of the best things you can do to prepare is to find a pair of earphones with a mic built-in and then make some calls using it. Make sure whoever you’re calling can hear you clearly and that you can hear them. This will allow you to free up your hands so that you can code using the online IDE that your interviewer will most likely send you a link to. The first time I did an over-the-phone technical interview, I had my phone on speakerphone which caused horrible feedback and I had to awkwardly lean down to talk into the mic while trying to code which was incredibly stressful! I do NOT recommend that! Wearing earphones also eliminates outside distractions so that you can focus on the interview. (If it’s via Skype, make sure you test your sound and video quality beforehand as well as your internet. It’s a good time to say hello to parents or grandparents).
// Pro-tip: For a Skype interview (regardless of it being behavioral or technical) a good thing to do is to put a sticker or a picture of a person next to your webcam. It’ll give you something to look at so you’ll be looking at the camera when speaking with your interviewer. Instead, if you stare at their face on your screen (which is a few inches below your webcam) it will seem like you’re looking down the whole time to your interviewer. Another thing you should always do is minimize the little video preview of yourself! Don’t worry about your hair or what you look like, just keep smiling at the mini picture of Ryan Reynolds or whoever else you stick up there and go kick ass!
Now for the juicy part - what to do during the interview itself. It may seem obvious, but as someone who has conducted a few interviews I know that the number one thing you need to do is explain what’s going on in your head (within reason though because you definitely shouldn’t be talking about your excitement to get to happy hour). If you have a thought along the lines of “this seems like a good direction to go but there’s also this other possibility” say it out loud and explain why. A lot of times your interviewer will save you time by nudging you in the right direction but if you don’t say it, they will never know what you were thinking!
Another thing to be thinking about is the language you use when explaining your thoughts. My number one pet peeve in an interview is the use of filler words. This includes but is not limited to “like”, “um”, “uh”, “actually”, and “literally”. The overuse of these words makes it seem like you need more time to think or are unsure of what you are saying. There was one time I was interviewing someone and it was so bad that I stopped paying attention to what they were saying and just started counting the number of times they said the word ‘like’ in my head. The answer is 84. In the 10 minutes I was counting. Don’t be that person! If you feel that you are someone who uses these words a lot, record yourself answering common interview questions and listen to yourself speak. Just by being aware of the fact will help you trim down on the excess and help you be more concise during crunch time.
If you need time to think about a problem or your approach, let your interviewer know! All you have to say is something along the lines of “can I have a second to think about it?” Otherwise they will most likely think you’re stuck and try to give you hints. Long silences in a tech interview can be super awkward if you don’t give a reason for it. Take a few minutes to think, and then like I said before - start walking them through your thought process even if you’re super stuck and have no clue what to do. You might be closer than you think and your interviewer is there to help you along.
I have mentioned this before but it’s worth saying again: you should use the interview as an opportunity to show off your knowledge. You shouldn’t answer only the question the interviewer has given you - you should use this as a chance to answer the questions that they haven’t even asked yet! This will impress them and make you come across as a thorough person with good communication skills and initiative (which obviously you are!). Address edge cases, talk about your reasoning behind why you choose a particular data structure, and address efficiency - these are all common follow-up questions that interviewers will ask but you’ll score bonus points for answering them up front. Even if you pick a data structure/algorithm that isn’t the optimal one - if they hear your “why” it won’t necessarily count against you.
I like to think of technical interviews as standardized testing. There’s a general outline for answering technical questions which has worked well for me. If you apply the same process to answering each question you’ll start to realize there’s a formula for how to approach each problem.
Start with pseudocode of the most obvious approach to the solution EVEN if it’s not the most efficient
Get your first draft of a solution down
Start refactoring code to improve efficiency and eliminate redundancy
Address test cases. (It’s always a good idea to test edge cases since these are tricky and can help you win extra bonus points for listing them even if you can’t figure out how to incorporate them into a solution.)
You’re not trying to show them that you know how to solve problems in 0.2 seconds you’re really demonstrating your skills as an engineer. That’s why this process looks so similar to how we code in real life! Let’s be real, none of us have memorized the solution to the problems we encounter as we code so you shouldn’t have to do that for a technical interview either. It’s ok to be a real person and not know the answer right away. What you do want to demonstrate is how you work through problems from start to finish. Which brings me to the next point - if you’ve already encountered a specific interview question make sure you tell your interviewer! Like I said earlier, you’re in the interview to demonstrate your abilities as an engineer not to show them you know how to solve every single problem. If you’ve seen a problem before, it’s likely that you won’t struggle with it meaning they won’t be able to see your ninja problem solving skills in action. Telling your interviewer “I just solved this problem the other day” or something along those lines will come across as honest and upfront in addition to saving everyone’s time.
At the end of the day when I interview people the question I always ask myself before submitting feedback is: “Would I pick this person to work on a group project with me?” You really want the person interviewing you to say HELL YES to that question when they’re writing your feedback. Using this to shape your interview will help immensely because it really boils down the whole technical interview to one question. We obviously want to work with people who are knowledgeable, have good communication skills, and seem like generally good people. By highlighting these qualities you’re more likely to get that “Congratulations” email afterwards.
For more career related tips, follow me on Instagram, Facebook, and Twitter!
See more: How To Prepare for a Technical Interview
