Types of Technical Interviews

Note: This article is a more in-depth view of some types of technical interviews from what is mentioned in the Mock Interviews article.

When preparing for technical interviews for software engineering/development roles, it is important to understand what types of interviews you might face. The preparation for each of them is different, and you might need to focus on different topics.

Some companies are very open about the types of interviews you will encounter in your process.

Others might not be upfront about it; however, it is usually not on purpose that they’re not sharing this information. The chances are that no one has asked them before, so feel free to ask about the interview format(s) you’ll be facing during your interview process.

a) Knowledge test:

In general, they might feel like a quiz about a specific topic or a couple of topics. They are sometimes used as the first technical phone screening interview to establish if you know the basics about the role or the required tech stack.

For example, if you’re applying to a Java Developer role, you might be asked questions like:

• What’s the difference between a List and a Set in Java?
• Assume you have a list of User objects in your system, and you need to sort them by their username. What approach would you use?
• What are the different uses of the final keyword in Java?

The expected outcome of this depends on the seniority of the role. For example, an interviewer might expect a Senior Java Developer to know/understand topics about concurrency in Java that they might not require for a Junior Java Developer.

In general, they can be 30-45 mins long.

b) Problem-Solving / Whiteboard coding:

In this type of interview, the interviewer will present you with a problem, and you’re expected to provide a solution during the interview. The setup of this interview varies by company. Some companies allow you to use an IDE/web tool and external resources (e.g., StackOverflow). Some companies don’t; for example, you will need to code in a Google Doc document instead of an IDE.

Usually, the programming language you choose is open. Or at least open to top industry-used languages (e.g., Java/C/C++/C#/Go/Python/…).

For example:

• Given a String of characters, provide a method to reverse the String (without using libraries/existent methods).

The difficulty of these problems can vary considerably. You can find and practice this type of problem on different sites, like HackerRank, TopCoder, and others.

For this type of interview, it is essential to brush up on CS fundamentals and data structures. It’s not uncommon to find problems where the optimal data structure is not provided by the API’s/libraries of the programming language you choose to use. For example, you might need to use a Trie to solve a specific problem optimally.

In general, they can be 45-60 mins long. Top-tech companies can ask you to complete more than one problem-solving interview.

c) Take-home test:

Take-home tests are becoming more popular in some companies. The company will provide you with a programming challenge, usually with a specific set of requirements presented to you in a Google Doc/PDF document. You’ll be given a couple of days to complete the challenge and send your solution back to the company.

What happens after that can vary per company, but usually, you might expect the following:

• The company will review your code internally, and an initial go/no-go decision will be taken based on your solution.
• If the decision is to proceed, you might be called for a code review interview where you’ll be asked to share details about your solution, answer questions about specific parts of your code. The interviewers might ask you about specific design decisions (that’s normal, don’t worry 😀 ).

In general, companies will give you 2-4 days to solve the test and send back a solution. If a code review interview is scheduled, they tend to be 45-60 mins long.

d) Pair Programming

Pair programming interviews are, to some extent, similar to a take-home test. The main difference is that the interviewer is your pair programmer, and you’re coding live (either onsite or via a video call sharing your screen).

The interviewer will provide you with a programming challenge, usually a shorter set of requirements than a take-home test. In contrast with the take-home test, you can bounce ideas and ask questions with your interviewer. In general, you should treat this as a real-life working setup, where you’re developing code with a colleague, so communicating and listening to feedback and hints from the interviewer is a must.

Some companies will allow you to bring your own device, and some will even ask you to do some preparation beforehand (e.g., install a database server). Others will provide you with a device, and others will use an online tool.

In general, it is okay to use online resources during this type of interview; however, it’s best to confirm with your interviewer and check the constraints beforehand.

Pair programming interviews can go from 1 – 4+ hours, depending on the company.

e) Systems design:

In these, usually, there is no actual coding required. The intention here is to see how you would design a system, what things you consider, and how you break down the problem.

The high-level/general format is the following:

• The interviewer will open up with a very broad system requirement, for example: “Design a URL shortener.”
• The interviewee needs to start asking questions to narrow down and get more details about the system that needs to be designed.
• The interviewee begins presenting proposals about the system’s design, gathering feedback from the interviewer to change the system’s design or help validate design decisions.

In general, there is no correct answer for these interviews. You can think about it as a design session with a work colleague that has some answers that you need to start uncovering. Different interviewers might want to focus on some aspects of the system a bit more than others, and that’s perfectly natural for this type of interview.

In general, they are between 45-60 mins long. They’re usually performed with only a whiteboard (or, e.g., with a Google Drawings/Diagrams.net document if done online).