Preparing for Software Engineering Interviews
Late last year I decided to start interviewing for new jobs. It had been over two years since I had last interviewed, and although I had been working and performing interviews for my employers this doesn’t directly translate into keeping up your interview skills(although it does help). So in order to prepare for and perform well during my interviews I did a few things before my interviews which I will outline in this post and hopefully help some other engineers through their interview process. I definitely don’t think I am a technical interview master like some of the people you see on youtube and on blog posts, but these methods definitely helped me to perform better and feel less anxious before, during, and after interviews.
Sidenote: How to Find Jobs You Like
First I just wanted to briefly touch on some of the things I did to find potential employers I was interested in, since I believe that a lot of engineers(and other professionals) may want to start looking for a new job but have no idea where to apply. I believe it is important to always keep up with other companies and be looking for companies you are interested in even if you are happy at your current job. I did not apply to any companies for over two years, but I made sure to keep up with what was happening in my industry. This allowed me to keep a running list of companies and industries in my head that I would be interested in working for when the time came to look. I believe an important part of job searching is finding companies that interest you, so that if you get the offer it’s an easy decision to accept. I try my best to stay up to date in the tech world by reading blog articles and tech news articles, and I believe this among other things helped set me up for a quick and focused job search that led me to a job I was happy and excited for.
However, even if you don’t have a running list of companies and industries you find interesting, I think it’s important to spend some time at the beginning of your job search to define what you value in your next role. What size company do you want to work for, what type of work or product is interesting to you, is there upward mobility, what industry or industries are you interested in, what would you like to get out of your next job, and what type of team would you like to work with are some questions you could ask yourself. By answering some questions about what you are looking for in your next job you can simplify your search and find companies that fulfill all or as many of your answers as possible.
Equipped with a list of companies and specific industries, I was able to quickly apply and start the process with companies I knew I would want to work for. Because of this I was able to apply directly to companies and reach out to recruiters which I believe can help speed up the process. Also if you use hiring marketplaces like Hired and Vettery, you can set your job search characteristics and get more companies you are interested in to reach out to you. A lot of times people apply to any jobs they see and this can lead to you starting the interview process with a lot of companies at the same time, many of which you don’t really want to work for. Interviewing is an incredibly time consuming task, so I believe it is important to make sure you have a focused search that allows you to spend your time wisely and prepare well for interviews you want to do well in. By being better prepared for applying, I was able to keep my initial company search list short and move quickly through the interview process with a few companies I thought I would be happy to work for and therefore accept the jobs right away.
Something to note is that if you have a friend or acquaintance at a company you want to work for I highly recommend getting a referral because this can help speed up the time to initial phone screening and getting your resume seen. Even if you don’t know someone at a company sometimes people are willing to help out potential candidates so feel free to reach out to someone at a company you like on LinkedIn and see if they are willing to tell you about the company and potentially refer you.
Although I do believe there are things you should do before, during, and after interviews to maximize your performance, prepping is most likely the most important because if you prep correctly then you will perform to your best ability during the interview. And if you perform to the best of your ability that’s all you can ask for out of an interview. Here are some of the things I did to prepare for interviews.
For anyone who doesn’t know about Cracking the Coding Interview it is basically a holy book when it comes to Software Engineering/Coding interviews. I originally read it back in college during my initial job search but it had been a while since I looked through it. It basically lays out a bunch of the fundamentals of performing well in technical interviews as well as has a bunch of practice questions across technical categories. I highly recommend owning a copy of this book even if you aren’t actively looking for a job because I believe every software engineer should go through it at least once. It can also help you on the other side of the interview table to better ask questions and get ideas for questions. I recommend looking through the chapters and finding the most relevant ones for you or ones you need to improve the most in, since you may not need every type of question for certain positions. I don’t want to give too much away because I think this is an important book that should be read on it’s own, but there are a couple of chapters that talk about what to do before the interview and behavioral questions that I will focus on for this post. I recommend reading these especially since these will help you prepare and perform well in nontechnical interviews, which will help you get to the technical interview. Also if you make it to the on site you are more than likely going to have a round of behavioral questions as well.
Outline and Answer Behavioral Questions
I think it’s important to not only prep for technical questions but also make sure you have answers to some basic behavioral questions. Before I had any HR screening calls, I made an interview prep document where first I outlined a simple answer to the “tell me about yourself” question. In this outline I followed a simple approach. Start off by saying your current role and company, including a brief description of what that company does(just a few words). Next I moved to a brief(1-2 sentences) description of what originally got me into software engineering and what I studied in college. This may not be necessary for everyone and I did not always say this part, but since I am still fairly early on in my career I felt it was relevant to include. After that I would talk about my past roles and what I did at those companies, spending more time on my current role. Lastly if I felt it was needed, I would talk a little bit about my interests outside of work and how I became interested in or found the company I was talking too.
Next based on the behavioral question chapter in Cracking the Coding Interview, I setup a matrix with a few potential behavioral topics for three different projects I worked on. I don’t want to completely give this away since the book outlines this, but I will go over the concept. There are a few different types of behavioral questions you may encounter that are based on past experiences and how you handled them. If you can outline answers to these topics of questions across multiple different projects you can then use this as a study guide before behavioral interviews. I would recommend making sure these examples are as concrete as possible and clear. If you have any friends who work as software engineers or recruiters, try bouncing these answers off of them and seeing if they think they are clear. You want to make sure you are completely answering the question with specific examples. A good sign you haven’t completely answered the question is if the interviewer continues to probe you on the question or asks you for another example. You should use other interviews to tweak or change your answers if need be.
Lastly I would also recommend laying out answers to any questions you think they may ask you. Some questions are “why are you leaving your current job?” or “what are you looking to get out of your next job?”. Another especially important question you could have answers for is what are some of your weaknesses. All too often people don’t have strong answers to this question and it shows they haven’t thought deeply about what they could do to improve themselves. I believe it is important for someone to always be looking for ways to get better, and having the self-awareness to know where you could improve is important for this. Try to create answers to as many possible questions so that you are better prepared. Put on your interviewer hat and think about what questions you might ask a potential candidate. Also I would come up with a list of possible questions to ask your interviewer. Interviewers will always leave time for you to ask questions, and you should use this time to the best of your ability. Come up with smart and thoughtful questions that give you more insight into the company and whether or not you would be happy there. Make sure the company matches what you are looking for in your next role.
Come up with a game plan for technical questions
During my prep I came up with a simple 7 step approach to solving all technical questions. This may not work completely for every person, but I think it is important for you to come up with your own game plan for solving technical questions. This way when you get stuck or feel uncertain, just stick to the game plan to keep moving forward and unblock yourself. Make sure your game plan has methods to unblock yourself. It’s important to always keep moving during technical interviews because you only have so much time. In some interviews if you can clearly show your ability to programmatically work through a problem, even if you don’t finish it, you can still pass. Feel free to use mine or adapt it. I will go over these 7 steps in my next post about Tips for Software Engineering Interviews.
Do your research
Do your research on the company, it’s interview process, and technical interview processes in general. Make sure you understand what the company does, what products they have launched recently, the role in general, any blog posts they have posted(or if they even have a blog), etc. It is important that you are able to clearly outline reasons why you want to work for the company and that you have done your research because this shows interest to your potential future employer. They want people excited and engaged in their company.
It is also important to do your research on the interview process at each company you interview with. Make sure to look at glassdoor interview reviews and see what other people are saying. Although you should take glassdoor reviews with a grain of salt because it generally is where applicants who had bad experiences will go to, it is important to still recognize that these candidates had those experiences and there may be some problems at the company. However if this is a concern this is something you can bring up with during the HR portions of the process and see how they are addressing these concerns. I think the more reliable part of glassdoor is to look at past questions that candidates have been asked and make sure you practice these questions. Some companies will continue to ask the same questions for a little while, and you may also see a question on one company’s profile that another company will ask you (this happened to me). However glassdoor isn’t the only place to find interview questions anymore, so do some googling on the company’s interview process and see if you can find other resources as well.
Lastly I think an incredibly important part of prep is to do research on interview processes in general and different types of questions. I watched loads of youtube videos about interview processes, questions, and methodologies for solving questions. As well as read dozens of blog posts on performing well in interviews. In today’s world there are more and more resources popping up every day in multiple different mediums(video, written, spoken) for one topic or another including technical interviews(meta: including this post). Use these to your benefit and make sure you see what other people are saying about the process you are currently in. This led me to my 7 step algorithm, and definitely made me a better and more informed interviewer.
Practice (yes we are talking about practice, sorry Allen Iverson)
I think this should be pretty self explanatory that the best way to get better at technical interviews is to practice as many technical questions as possible. However, it is important that you practice in real life situations. Act like each practice question is being asked to you by a real person and you have a set time to solve it. Use your game plan you came up with to solve each practice question. If you practice like it’s the real thing you will perform better when the interview comes. This is the same for any practice and reminds me of a quote by Vince Lombardi that “Practice doesn’t make perfect, perfect practice makes perfect.” Make sure you aren’t just going through the motions when practicing, but make sure you are actually trying to solve the question to the best of your ability. It can also help you to perform better when practicing. When I didn’t follow my game plan for solving practice questions I would perform worse and have a harder time coming to a solution then when I followed the game plan like it was the real thing. Lastly just to touch on some resources for finding interview questions, you can use Cracking the Coding Interview, Leetcode (I recommend only easy and medium questions because you will rarely ever get a hard level question in an interview), and youtube videos. These were the three main sources that I used, but there are definitely more out there you could use.
There was also a video(s) on youtube which outlined 10 important coding topics to understand and you could use to answer almost any technical coding interview question. And I say almost because I don’t believe you necessarily need to use one or more of these topics for every type of interview question, but they can help with most. You can find the videos that discuss these topics here and here.
- Depth First Search
- Breadth First Search
- The matching parenthesis problem
- Using hash tables
- Pointer manipulations
- Reversing a linked list
- Sorting fundamentals
- Custom data structures (object oriented programming)
- Binary Search
Practice System Design Interviews
Before this round of interviewing, I had never gone through a system design interview either as an interviewer or interviewee. The last time I had interviewed I had been in college and most companies don’t require new grads to go through system design interviews since they generally lack this real world experience. So this was a new type of interview for me and something I spent pretty much all of my time working on once I had gone through a couple of technical phone screens and moved to onsites. I will say I think the best preparation for system design interviews is actually building real world systems. Therefore make sure in your current role you take every opportunity to build new systems. However, realistically this isn’t something that everyone can always do in their current role. Nevertheless, spend as much time as you can understanding your companies current systems such as how they work, where they are limited, what are some incremental improvements that could be made, ask questions to senior engineers and tech leads about the systems, etc. Another thing you can do is to read blogs and tech posts about other companies’ systems and what they are doing. Look at industry leaders and see how they are building systems, why, and what for, because more likely than not they are going to be doing it correctly.
Nevertheless, these passive learning experiences don’t completely prepare you for what to expect in a system design interview. Another big problem is that different companies have to build different systems based on their needs and you probably aren’t going to be exposed to every type of system at your day job. You can constantly learn about real world systems and build great ones, but still fail a system design interview if you don’t prepare correctly and know what to expect. In order to prepare for the system design interview I personally did a few things. First I read through the chapter in Cracking the Coding Interview about system design interviews and attempted the practice problems outlined there as well as went through their solutions. The other main thing I did was google common system design interviews and watch youtube videos where they went through common system design questions. These were incredibly helpful to quickly see a bunch of new and different systems you wouldn’t normally be exposed to at one single company. The biggest take away I got from all my preparation is that you need to be comfortable coming up with multiple possible solutions to a part of a system and discuss the trade offs. Know the differences and know how different things scale. A lot of people will also never build systems that need to scale to hundreds of thousands or millions of concurrent users, and sometimes these are questions that can come up in a system design interview.
I hope that someone comes along and finds this interesting. I get incredibly anxious and stressed when it comes to technical interviews, which is a weird thing for me because I almost never felt that way in school. So before I started this interview process I tried my best to remove as much stress and anxiety as possible. I will say my first technical interview gave me a lot of anxiety but after I did one I felt less anxious because I could see my game plan work in action. By sticking to my gameplan, I was able to get to onsites with every company I interviewed with. Look for my follow up post on Technical Software Interview Tips where I go into detail on my game plan I used for coding challenges.