Hiring an Engineer: 7 Different Types of Engineering Interviews

After conducting hundreds of engineering candidate interviews on behalf of Stripe and LogicLoop - and having interviewed at 30+ tech companies ranging from less than 10 people startups to giants like Facebook, Palantir, and Google - least to say, I’ve seen quite the gamut of engineering interviews. If you’re an engineering leader thinking about how to design your interview program, or a candidate wondering what types of interviews are out there, let’s dive into the most common interview question types and pros and cons of each.

First, let’s get the elephant out of the room. No engineering interview process is perfect and all interviews are at best a narrow snapshot of how well a candidate may do at your company. There are candidates who bomb interviews end up being very strong engineers, but also candidates who do well in interviews but end up struggling on the job. That being said, while imperfect, interviews do give some signals that can be indicative of how well the candidate may fit into your company.

1. The take-home coding interview

The first is the take-home coding interview. Typically this is a longer coding exercise that can take anywhere from a few hours to a day to complete. Since there’s less time pressure and candidates are able to use resources available to them on the internet, the take-home interview typically involves completing a small project end-to-end.

Pros

• There’s less time pressure and candidates get to work in a comfortable environment where they can iterate on their code until it’s satisfactory to them.
• For longer take-home exercises, some companies even compensate candidates for their time.

Cons

• You get less signal on the candidate’s thought process and how they interact with others.
• It’s easier to cheat or directly look up the answer on the internet.
• For people will busy lives, take-homes can be time-consuming, especially if the candidate is interviewing at multiple places.

2. The algorithms interview

The algorithms interview is the most classic engineering interview that companies like Google, Facebook, and Palantir like to implement. Typically this will involve concepts like dynamic programming, recursion, sorting, binary trees, etc. Candidates will also need to be familiar with common data structures like arrays, dictionaries, trees, etc.

Pros

• These types are interviews are extremely common among large top tech companies and many candidates know how to prepare for them via e.g. leetcode.
• Algorithms typically take some amount of rigorous thinking to get right and require you to think through edge cases, so there’s some correlation there with general intelligence and the ability to think through complex problems.

Cons

• Since many of these algorithms are not used on a day-to-day basis in software engineering, many senior candidates may not have these concepts top of mind vs a junior candidate who learned these algorithms recently in their Computer Science course in college.
• Non-traditional programs such as programming boot camps don’t teach advanced algorithms so you may eliminate folks with non-traditional backgrounds.

In recent years, there’s been more controversy over whether companies should ask algorithms interview or not, given they are not directly related to the day-to-day job.

3. The bug squash

In an effort to mirror more day-to-day working environments, some companies have introduced the bug squash interview. In this interview, a candidate will be given access to some pre-existing codebase with a bug and it’s the candidate’s job is to find and fix the bug.

Pros

• These interviews can give you signal into how the candidate navigates a large, pre-existing codebase, which some of the other types of interviews don’t test for since other interview formats typically ask the candidate to write a small program from scratch.
• They say it takes a smarter person to debug a piece of code than to write that piece of code, so if a candidate can pull this off, it’s a good sign.

Cons

• Some candidates will go down unfortunate rabbit holes and not be able to find the bug within the allotted interview time slot. Sometimes it just so happens that a candidate misses a section of documentation during the interview that would have clued them into the bug. Due to the limited time constraint, candidates won’t have time to comprehensively read through all docs, so some will do a skim, and if that skim results in skipping over the relevant parts, it might just not be their lucky day. This doesn’t necessarily mean that they wouldn’t do well if given more time.
• It’s difficult to understand a large codebase within a short amount of time.

4. The systems design

The systems design interview typically asks a candidate to describe how they would set up the infrastructure to support a scalable system. This can be a whiteboarding exercise where the candidate describes the boxes, queues, etc. they would set up to create a scalable system e.g. a webhooks delivery system, a metrics recording system, etc.

Pros

• The systems design interview is a great non-coding interview to see if the candidate is able to set up a system and think about scalability, reliability, and operability at the infrastructure level.
• Usually, this involves a lot of back and forth conversation with the interviewer and question asking, so you get a sense of how to collaborate with the candidate.

Cons

• People who have more experience with infrastructure will tend to do well in these interviews whereas new grads and more junior candidates may simply not have the experience to answer this question well.

5. The code review

While this interview format is uncommon, some companies have started employing the code review interview where the interviewer will either ask the candidate to review a piece of code, or the candidate will submit a piece of code to be reviewed by the interviewer, and incorporate the feedback given.

Pros

• Since code reviews are a code part of an engineer’s job, this provides good insight into how they may actually do a code review on the job.
• This exercise can also test for soft skills. Did they take feedback with grace and correct their mistakes? Are they able to give feedback in a constructive manner?

Cons

• It can be difficult to review a piece of code in isolation without more context on the wider codebase.

6. The integrations interview

Another “practical” code question that has become popular over the years is the integration interview. It’s no denying that in the age of APIs, many software engineers have had to integrate some external system as part of their jobs. The integrations interview simply asks the candidate to demonstrate that they can write a program that integrates with some third-party API, such as Stripe or Twilio.

Pros

• Since integrating APIs and reading documentation are a common part of an engineer’s job, this provides good insight into how they may actually hook up an integration on the job.

Cons

• For an engineer with a lot of industry experience, this should not be a difficult task to do at all, so arguably this is an “easy” interview.

7. The soft skills/culture fit/manager interview

Finally, most companies include a soft skills interview, typically with the manager of the team. The interview gives hiring managers the opportunity to ask about projects candidates have worked on in the past as well as their strengths and weaknesses. It also gives candidates the chance to ask questions about the company and team.

Pros

• Soft skills are an important part of an engineer’s job and it’s important for a hiring manager to meet with the candidate to get a sense of whether they’d work well together.

Cons

• How well a candidate does on this interview can be very subjective.

  
  

If you’re a hiring manager, I hope this gives you a few options to brainstorm as you’re thinking about setting up your interview program. At LogicLoop, we do a combination of the interview types listed above, although we tend to go lighter on the algorithms questions and instead focus on the practical coding exercises.