Technical interviews can be daunting, whether you’re early in your career or a seasoned engineer. While the most important piece of these interviews is, of course, your technical skills, there are a number of things you can do to prepare beforehand, ensuring that you have a clear mind going in and allowing these skills to shine through.
Know your story
No matter how technical a role you’re going for, companies want to hire people who work well with others—and the ability to communicate clearly and concisely is a key skill in working with teams. Interviewers will be evaluating your communication skills when they ask less technical questions, so be prepared to speak about your past work experience and education coherently, based on what is on your resume. Try practicing this pitch alone or to a friend beforehand to make sure it sounds the same out loud as it does in your head.
Further, being able to describe the specific projects you’ve worked on in detail is crucial, particularly if you have a bit of work experience under your belt. Describing how you’ve solved difficult problems in the past, especially if they are similar to problems that the hiring organization might be facing, can give you a huge leg up in a technical interview.
Study your data structures and algorithms
Like it or not, classic data structures and algorithms interview questions—often assessed on a whiteboard—are here to stay. Linked lists, arrays, queues, binary trees, graphs, and even slightly more obscure data structures like tries and bloom filters are worth knowing inside and out. Make sure to know the running times associated with common operations on each data structure, and scenarios in which they are likely to be used.
With your data structures knowledge in hand, take some time to understand the most commonly used algorithms. Techniques such as divide and conquer, graph traversal, and even dynamic programming are must-know material if you want to ensure top performance in a technical interview.
Practice example problems
While having the concepts in your head is a great start, there is no replacement for practice. There are a plethora of practice problems available on sites like HackerRank, Quora, and HackerNews. Working through these problems will develop your ability to understand problems quickly as well as to apply the techniques studied in your data structures and algorithms review to construct efficient solutions.
The phone screen is a good opportunity to get a better grasp on the types of questions that might come up in your onsite, so be sure to ask questions—particularly related to the projects the team is working on and where you might be expected to add value—early on in the interview process. The more specific you can be about which types of problems to practice, the better prepared you’ll be in the actual onsite.
On the flip side, remember that you’re interviewing the company just as much as they’re interviewing you, so getting an idea of what you’ll be doing (and practicing example problems that might mirror the actual work) can help you evaluate whether you’ll be happy in the role. According to our latest Brand Health Report, technical workers considering a new job are most concerned with the products and projects they might work on, so it’s beneficial to both parties for you to have a good sense of what the role will entail—and your ability to deliver on said projects.
Know your interviewer(s)
Figuring out some details about who your interviewer(s) will be can help you better prepare for your onsite, both in terms of predicting the types of questions that will be asked and knowing how to frame your answers. Some recruiters or hiring managers will be explicit about your interviewer panel. If not, there’s no shame in asking—or do some digging online and take your best guess at who will be on the other side of the table.
Once you have an idea of who your interviewer(s) will be, look at their accounts on GitHub, LinkedIn, etc. to get a sense of projects they’ve worked on, their interests, and their past roles. Make a note of specific skills they might help you learn (joining any team should be mutually beneficial!), as well as gaps in their expertise where you might be able to add to the team.
Make yourself comfortable
Stay hydrated and have a snack or a coffee if you need during the interview, as there’s no reason to add physical stress to a mentally exhausting exercise. If the interview involves coding on a computer, make sure to take your time assessing and checking out the environment on the test machine before diving into the task at hand.
Ask questions and think out loud
Make sure to understand each question fully—specifically, the types of any inputs and limits on their size or complexity—before getting to work on your solution. For example, if asked to search for an item in array, it is important to know whether or not that array is already sorted.
Don’t be afraid to ask your interviewer questions. Having made it to the technical onsite, the company is investing time and resources into interviewing you, so it’s in their best interest to help you perform well—and interviewers are therefore generally happy to provide clarification.
Once you do get to solving the problem, make sure to communicate your thinking at each step to the interviewer. Not only does this help them assess your thinking, which is the whole point of the exercise (even more so than getting the right answer!), but it can help them steer you back on the right track if there is any misunderstanding. If you operate with the wrong assumptions in your head for too long, you can waste a lot of time, so talk your interviewer through your thought process to increase your chances of success.
Be specific about the problem, not the tools
Your interviewers generally aren’t concerned if you remember the exact Java API to split a string, so don’t be afraid to ask, or to default to pseudo-code if you can’t remember.
Similarly, if you need to perform a trivial operation, like converting from miles to kilometers, just calling a helper function without implementing it is probably fine—you can always implement those smaller details once the broader solution is fully fleshed out.
Once you’ve finished your onsite, there’s a tricky balance between letting go of mistakes you made while also learning to improve. On the one hand, don’t berate yourself over what you didn’t know. If there’s a critical gap in what you know and what the job requires, then maybe it wasn’t the right role in the first place. And if it’s silly mistakes you’re concerned about, remember that interviewers are human—and they know you are too.
At the same time, however, use each interview as a learning experience. If there’s a problem that stumped you, work it out on your own time after the interview, figure out what about it was difficult, and file those conclusions away for use in the future. In addition, once a hiring decision has been made, it’s fair to ask for feedback on your technical evaluation, which can help you better understand where you went wrong—and where you shined.
Lastly, take a few minutes to send personalized follow-up thank you emails to your interviewers. It can feel like a bit of a formality, but will never hurt your chances—though thank yous generally won’t make or break the decision of whether to move forward with extending an offer. Don’t expect your interviewer to respond (though they might!), but rest assured knowing you’ve checked that box in each interviewer’s mental list of the impression you’ve left.