This is part of a series on my experiences and learnings after conducting 750+ interviews and reviewing 10,000+ more over the course of five years. From both the candidate and interviewer sides of the table.
When preparing for an interview we tend to focus on our technical skills. The data structures and algorithms textbooks from college get dusted off, practice programming websites are visited, and we remind ourselves the finer details of long forgotten dynamic programming concepts. This is only half of the battle though. Our soft skills are just as important if not more important, but these are often overlooked. Let’s consider what some of these are in order to be prepared in that arena on your next interview.
Before the interview starts you need to be getting yourself prepared. If you have a phone screen either over the phone or through a video call there are some basics to nail down in order to get the interview off on the right foot.
It’s always surprising to me how many candidates are late to their interview. The saying that you only get one chance to make a first impression is true. If you can’t remember to show up to your interview on time (an important event) what does that leave me to infer about your level of organization and dedication? Create a reminder for yourself, set an alarm, put a post-it note on your screen, whatever you need to do in order to show up on time.
Going along with this is read the instructions you were sent well ahead of time. I’ve had candidates miss interviews entirely because they were waiting for a phone call when the email sent to them had a link to join a video call at the scheduled time. Depending on the video calling system used you might have to install software. Five minutes before the interview is not the time to find out that you have a 500mb software package to download and install.
Test your AV Setup
Yeah, so webcams and microphones still suck in 2020. For whatever reason, we still have not figured out how to make them consistently work. That means it’s your responsibility to test them ahead of time. Not just in general, but with whatever video calling system you’re going to be using. Joining the interview and immediately having to spend 10 minutes getting your microphone to work gets sets the interview off on a bad foot and typically uses up some of your time.
When it comes to AV setups, the quickest way to annoy your interviewer is microphone feedback. Fortunately, there’s a simple solution to this:
Likewise, make sure your laptop is charged or plugged in. The last ten minutes of the interview when you’re frantically debugging code is not the time to worry about wondering where your laptop charger is. Same goes for your phone if doing a phone call.
Believe it or not, I’ve interviewed candidates doing the interview from their cars, coffee shops, and even bars with live music playing in the background. Aside from how unprofessional this is, it’s straight up annoying to have to listen to background noise for the entire interview. Find a quiet location before joining your call. Even if you think there’s only a slim possibility the person in the apartment/dorm next door will start their Friday night rager, find a location you know will be undisturbed for the duration of the interview.
It’s totally normal to be nervous about an interview. Especially for college students who are new to technical interviews and trying to land their first internship it can be a nerve-wracking and intimidating experience. The goal of everything above is to be prepared for what you can control so your mental focus is entirely on the substance of the interview. The less distracted you are the more you can focus on the technical aspects of the interview. Making sure to block off some time before your interview to get mentally prepared is just as important as any other type of prep you’ll do. You know what works for you, give yourself the time allotment to do it.
Lastly, you’re going to be talking a lot. Have a glass of water nearby.
IDEs & Development Environments
As much as I wish it weren’t the case, interviewers will often expect you to write code in a substandard environment. You probably won’t have your familiar IDE with auto-competition and syntax help. You may not even be able to execute and test your code. You’ll probably have some syntax highlighting at best. The trends are changing on this for the better, but every company is different so you likely won’t know what type of an environment you’ll be dealing with until you’re in the interview. On the other hand, if you do have the ability to access the environment ahead of time, part of your prep should be getting used to that environment.
As an interviewer, it gets old really quickly to hear candidates make excuses about their performance because the environment is not what they’re used to. Any seasoned interviewer will understand that and account for it. But it also doesn’t excuse lacking basic skills like not being able to understand compiler output. You need to know your language and how to effectively work with it. If you’re dependent on Visual Studio or IntelliJ correcting your syntax for you and providing auto-completion then spend time writing code without those. Open a basic text editor and practice writing code, compiling it from the command line, and running it. The same goes for debugging. You’ll most likely not have access to a debugger. You should be able to work through bugs in your code without that assistance.
All interviewers look for different characteristics in their candidates based on what they think is important to hire for. The better interviewers will tell you that explicitly, but most of the time it’s not revealed in the hopes that you’ll stumble across it. For example, some interviewers might want to see you find the optimal solution to a problem. Others will want to see you write solid, production-like code. And others want to see you write a comprehensive set of tests for your solution.
Once presented with a programming question, it can be well worth your time to simply ask your interview what to focus on.
Asking “what do you want me to optimize for” can greatly affect the outcome of the interview.
Once you know that you can manage your time effectively for it. If the interviewer says they don’t care about how optimal your code is so long as it works you know it’s not worth spending time thinking through what the optimal approach might be. On the other hand, if they’re looking for well written code you might spend more time organizing your code and following the idiomatic design patterns for your language of choice. The way we manage our time in the interview has a huge effect on how well the interview perceives our performance.
Verbal & Interpersonal Skills
The interview is your opportunity to show off what you know. You’re eager to prove that you’d be a great fit for the position and want to demonstrate that to the best of your ability. That’s great! However, this can often manifest itself in the long winded candidate that gives 10 minute answers to every question. For most questions, you want to strike a balance between being descriptive yet concise. For questions about your background or projects, a high level overview is best. Don’t launch off into your life story or explaining a project you worked on line by line. Practice your elevator pitch; have it rehearsed and make it to the point. As an interviewer, that’s all I need. If there’s something I’m unclear on, let me ask about it. At the end of the day, interviewers will go through countless numbers of candidates and they all blend together. Frankly, we probably don’t care about the nitty-gritty details of how you implemented the backend of a CRUD form on a website. Give the overview and maybe what the major challenges were and let the interviewer drive the conversation from there.
For technical questions, the same communication style typically applies. An interviewer has probably asked the questions you’re being asked more times than they remember. They’ve heard every possible answer and seen every solution. They don’t need to know an exhaustive description of how eventually consistency databases are implemented. Give an overview to let the interviewer know you know about and understand the concept and leave it at that. There’s a bit of skill in reading the interviewer to know if they are satisfied with your answer. If they aren’t add more info or ask for clarifications. If they are, stop explaining and move onto the next question. Your goal should be to show that your knowledge is both a mile wide and a mile deep.
It should go without saying, but don’t be a jerk to your interviewer. Don’t interrupt or talk over them. If you don’t agree with the validity of a question don’t question or argue about it. To an interviewer, there’s nothing more frustrating than having a candidate try to explain why the question at hand is not a good interview question. Even if you’re entirely correct, there is nothing to gain from trying to convince the interviewer otherwise during the interview. In fact, it’s probably a sign that the team might not be the right place for you. That’s perfectly okay. Roll with the punches to get through the interview. You may be asked for constructive feedback afterward at some point in the process. That would be the appropriate time to give that type of feedback.
The last section of the interview is typically an open-ended discussion if you have any questions for them about the company/team. For me, this is the part of the interview were most of my decisions about a candidate are made, excluding exceptionally good or poor performance up to that point. Especially for smaller companies, your interviewer wants to see you interested in the company, the product, and the mission. Showing interest in those areas is a great way to stand out. If you don’t show interest I start to worry about cultural fit. The worst thing you can do here is say you don’t have any questions and end the interview. For most hiring managers passion can overcome small technical shortcomings. Demonstrate that you’re excited at the opportunity to be part of the team and help solve the company’s problems.
This is by no means an exhaustive list of all of the soft skills needed to interview well. Even worse, the only way to learn most of this is to do it for real in interviews. There’s no definitive guide or objectively correct answers that will apply in all situations. If possible, try to find mock interviews to participate in. We rarely, if ever, get actual feedback from our interviews. Having an opportunity to get the raw, unfiltered feedback in a mock interview can be a great opportunity to see exactly how you’re doing on those communication skills and where you need to improve.
The truth is that most interview loops and hiring processes are not well developed. Unless a team has put a considerable amount of thought into them the status quo in our industry is an interview that is subjective, unequal, and biased. If you end up being rejected try not to feel too bad about it. It’s often a result of a poorly designed hiring process, but you can help stack the odds in your favor by nailing the soft skills.