Kyle McVeigh
Kyle McVeigh is a Software Engineer and Vice President based in New York City. From the perspective of an Software Engineer, Kyle shares 10 different styles of interviews he's undergone throughout his career.
For more of Kyle's posts, visit his website or learn about his experience on LinkedIn.
I recently went through the interview process, and it made me reflective on the types of interviews I've sat through throughout my career. I've seen hundreds of derivatives of the below 10 types of software engineering interviews.
I'm going to outline the ten types, examples of each, what the interviewer is looking for, and how to succeed in each. Interviewing is an ever-changing process, so this is not meant to be a comprehensive list, but is a great place to start. These are in no particular order:
For better or worse, this is the default interview when people talk about interviewing as a software engineer at a large tech company. These type of interviews are most common at the FAANG companies and there is a ton of literature on these. Books have been written and there are tons of websites like HackerRank, LeetCode, and GeeksforGeeks designed to help engineers practice. You can even watch software engineers crush these types of questions on twitch or youtube under the category of 'competitive programming'.
There is a lot of valid criticism on these, but ultimately these are used because it is easy to compare the results of hundreds of candidates, a requirement at companies that are interviewing thousands of people a week. The best strategy to do well on these is to practice, get a working answer, and worry about edge cases and refactoring the code secondarily. These are language agnostic, so do yourself a favor and do a high-up un-typed language, like Python.
Personally, I always make it a point to do advent of code each December in order to keep my algorithm skills sharp. Be sure to study hashes, trees, string manipulation, traversing 2D arrays, and sorting methods.
If you're interviewing for a specific language, such as Javascript for a frontend role or C for a hardware role, you can expect to get an interview that focuses on the nuances of that language.
Let's take Javascript as an example: you can expect to have questions on async/await, currying, hoisting, and binding. The interviewer is looking to ensure you have a deep understanding of this specific language, as it will be the majority of your job. Prepare for these by reading about typical interviews in that language and brush up on the more academic concepts of the language.
Very similar to language-specific interviews, framework interviews ask you specific questions about the framework that will be required for the role. If you're interviewing for a React frontend role, the interviewer might ask you to quickly spin up a working calculator or a game of connect four.
Additionally, you'll need to know about some of the newer features of the framework. Sticking to our React example, be prepared to answer questions on Hooks, Lazy loading, state, and router. Prepare by these by coding a lot in the framework and reading the documentation closely.
This type of interview is when you're assigned to pair on a problem with an employee. Some examples include:
The interviewer is seeing how you think through problems and how you go about coding production quality code. You may have the choice of a few languages, but you and the interviewer will also need to know the language. The way to succeed on these is to stay vocal and keep trying solutions and moving forward.
This is another type of interview that has a lot of literature on it. These types of interviews are mostly reserved for backend engineers and become more important as you get more senior. These typically take an hour and will be done with a whiteboard. A few examples would be:
The interviewer will typically provide a few screens that need to be constructed and the basic problem and you're tasked to provide the schema design and endpoints. You'll also quickly go into scaling and infrastructure questions, including the use of loadbalancers, leader-follower databases, and database sharding. In order to do well on these, ask a lot of questions, discuss trade-offs between technologies, and keep talking. The interviewer is looking that you're familiar building a system that scales and you understand the tradeoffs between technology choices.
These are typically a thirty minute conversation done with a person from the product team. These are non-technical but important interviews as the interviewer is determining how well you work with the product team and how you go about figuring out the acceptance criteria and delivering value to the user. One typical open-ended questions that might be:
To practice these try to think about the end-user and how you work with the product team to figure out how to help deliver value to the client.
This is another type of non-technical, common, and important interview I've gotten, typically thirty minutes long with a member of management. The conversation typically revolves around how the company makes money and the profile of the typical user, and a bit about the competition. These vary vastly with the industry and company, for example a crypto company will may ask about wallets, encryption, and decentralization while a consumer-finance company might talk about cross-selling financial products and refinancing mortgages.
The interviewer typically doesn't anticipate you to be an expert in the industry, but is looking for you to be enthusiast about the space and interested in the company. You can prepare for this by spending some time on the company's website and learning about the product. Usually the recruiter can help you with these type of interviews as well.
Sometimes you'll be assigned a larger problem as a take home assignment. A typical take home might be: host a url-shortener service with expiring links. The interviewer wants to see you make high-quality code in a not-time restrained manner. The best piece of advice on these is to be kind to yourself and time box these.
These are not formal, but have occurred a fair amount, so I feel it is necessary to make them their own type of interview. They usually are thirty minute conversations with a member of the engineering team about what you're currently working on, what technology excites you, and some hard technical problem you've had to solve recently. The interviewer wants to see you're enthusiastic about coding and you do a good job keeping up-to-date with technology.
These are very much not tech specific, but are the most common type of white-collar interview. These are usually thirty minutes long with a member of the operations team. Type of questions include:
The interviewer is ensuring you work well with a team and that you'd be a good culture fit for the role. Prepare for these by googling 'Typical personality interview questions' and have prepared answers. This will get you into the correct head-space to answer whatever they ask from you.
As a final piece of advice, try your best to ask the recruiter before the interview which type of the above types of interview you'll be having. This can ensure you prepare appropriately and don't waste your time studying the for the wrong interview type. Most recruiters are able to give this information and are happy to share that with you.
Let our team help you get where you need to be.
