Common Types of Interviews

Before heading into a job interview, you might feel nervous/anxious about what’s to come. This might be especially true if this is your first job interview ever or if it’s your first job interview in a while.

When applying for Computer Science/Software Development related jobs, you’re going to find different types of interviews. Some of them are similar in format; however, they can have other names depending on the company.

And of course, different companies, and in some cases, teams inside the same company, have a different set of interviews that they want to cover before considering extending you an offer.

There is plenty of debate about what type of interview is best, depending on each case. However, there is no standard across the board. So it’s important to understand the interview pipeline and types of interviews of the companies to make the best of your interview preparation.

Whatever the case, mock interviews provide a way to practice different types of interviews and get feedback about areas you might need to focus on during your interview preparation.

Types of Interviews

These are some types of interviews for Software Engineering/Software Development roles that you might encounter. This is by no means an exhaustive list.

1. Technical/CS Fundamentals Interviews:

In this type of interview, the interviewer is trying to determine if you have a clear understanding of programming fundamentals. From an interviewer’s point of view, they’re trying to establish if you can design, write and test code, but also how you approach a problem and see how you break down the problem into smaller pieces.

However, a good technical interview can help uncover more than that. It can also be a place to check:

• How do you work with others?
• How open are you to receiving feedback?
• Identify what other aspects outside of the task at hand do you bring to the table (for example, are you concerned about scalability/input validation/among others).

There are different types of interviews in this area covered in the link below.

Read More >

2. Behavioral Interviews

The idea of this type of interview is to understand how you would act in specific job-related/employment-related situations, using past experiences as a reference/predictor of future performance in similar situations.

The questions asked can vary depending on the role you’re applying to. For example, if it’s a Tech Lead role or Management role, the situations might be more focused on management/leadership topics than for individual contributor roles.

Examples of behavioral type questions include:

• Tell me about a time where you made a mistake in a previous project/job.
• Describe a situation where you had to complete a task/goal, and you could achieve it.
• Give me an example of a time when you disagreed with a manager/tech lead.
• Tell me about a time when you had to provide constructive feedback to a team member.

For this type of question, it is good to practice the STAR model/format.

In general, they are between 45-60 mins long.

3. Past Experience / CV Review

In a “CV Review” type of interview, the interviewer will ask you questions to understand in more detail what you’ve done in previous jobs. If you’re starting your career, you might be asked about University projects, so be prepared to come with examples.

Usually, the interviewer will want to delve into specific topics about your previous experience. For example, if you claim in your CV that you worked in a particular type of system, they’d like to find out if you can explain how that system worked, how it was designed, and how it could have been improved.

This type of interview can go into technical details, management questions and sometimes move into a behavioral type interview. It all depends on the role you’re applying to, the interviewer and the interview pipeline.

CV reviews are seldom a type of interview that is performed on its own; they tend to be used as one portion of an interview and then mixed with one or more of the other types of interview we’re discussing in this blog post. However, as you gain more seniority and more experience, there might be enough topics to discuss for this to be a full interview.

For example, when mixed with other types of interviews, an interviewer might ask about your CV/past experience during the introductory part of the interview (usually 5-10 minutes) and then move, for example, into a technical problem solving interview.

4. Assessment centers

Assessment centers vary by company and are in general used for graduate/entry-level jobs.

They tend to involve various tests during a simulated day of work. There will be multiple candidates being evaluated at the same time as you. There will be specific tests done during the day (for example, programming tests for Software Developer roles are to be expected).

Once you arrive at an assessment center, the organizers will provide you with the specific schedule for the day and give a presentation with the general details of the day.

There will be company employees with assigned roles during the day; for example, there might be one person assigned to help resolve doubts that you might have about the tests. And another person checking how they see candidates performing during the simulated day of work.

In general, they can last 4-8 hours; however, some can last more than one workday.

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).