Deep Dive Interview

I recently went through a job search, and some of the hiring processes included a section called the in-depth technical interview (or deep dive interview).

In the vast majority of cases, this part of the interview is usually "inside" another interview, or it’s not as thorough, but in two specific cases, the entire hour was dedicated to this interview.

In this post, we’ll look at what this type of interview is all about.

1 - What is the in-depth technical interview about

Many, as was my case until recently, may not have experienced this kind of interview. At least not as a standalone step in a hiring process; instead, you might have just been asked questions about projects you’re currently working on and the technologies involved during other interviews. Since it's only part of a bigger interview, most technologies are glossed over and that’s it.

In this case, the interview is the same, but focused exclusively on one real project for an entire hour. This interview is usually reserved for relatively senior development roles, such as Staff, Principal, or Distinguished positions at top companies like FAANG or similar levels. A small company or one whose core product isn’t software generally won’t give you such a thorough interview.

This means you need to know every aspect of your application very well because you’ll need to analyze a real application or system you’ve worked on in detail.

Something very important for this interview is that the project you’re presenting should be complex. Now, I don’t mean over-engineered—just that it’s not a simple CRUD to a database with a few events, but instead that it has more substance. If the process is too simple, you’ll likely fail the interview, which doesn’t seem completely fair as it’s something external to us.

Another crucial point is that the greater the impact on clients, the better. As we’ll see later, this is a key part of the process.

Technically, you could showcase a hobby project you’ve done recently, but I don’t recommend it. You’re going to face very technical and in-depth questions that you might not have encountered (or explored deeply) if it’s a side project.   

2 - Preparing for an in-depth technical interview

The key to passing the deep dive interview is having everything prepared in advance, by which I mean having a document ready with the project you want to highlight. This step is helpful both for a deep dive interview and for situations where only a part of another interview is dedicated to this format, but you don’t get asked in-depth questions outside of a deep dive.

My recommendation here is to generate a file for each project you complete at your company, and personally, I had never thought of this before. But having all the information in a file can serve you even years down the line—5, 6, or even 10 years—to remember what you worked on and to keep it documented.

The file, which should be 2–4 pages, should cover the following topics:

Describe the system and what made it important within the company.

This is where you describe the non-technical problems you faced.

You can also write a short paragraph on what your company does and how this project fits into the current system.

This section focuses more on the product than the technical side; after all, companies sell products, and understanding this is important as part of the company.

Technical implementation.

Now it’s time to explain the problem from a technical perspective. You should include what your role was and how you contributed. Clarify which parts of the system you were responsible for. This is important because, in many cases, a large system involves several teams, and you might not have visibility into what other teams do. Setting this expectation also means that if you’re asked about parts you don’t know, it shouldn’t be taken negatively.

For example, let’s imagine we worked on a notification system at our company, similar to what we saw in the system design course.

Ideally, in this scenario you should mention which part of the process you worked on, and if you led it, definitely say so. You might be asked, for instance, how it works—the system that sends emails, for example, is a third-party app in our case, but it could be another internal team. Having a basic idea of how such systems work is important.

I recommend including a diagram of the system since it’s always a great memory refresher.

During this section of the interview, highlight the process and why it’s important in the company, but also the trade-offs you had to make and why.

In this particular diagram, there are several trade-offs. For example, why does our system use events as the entry point instead of an HTTP call? That’s a question you’ll very likely be asked.

Why did we choose to separate into multiple queues instead of using just one or even calling the third-party service directly from the consumer?

What the interviewer wants to see here is what technical challenges you faced during the process. The best approach is to have all challenges and decisions documented—what was chosen and why.

Another example might be the use of a specific cloud technology—why did we choose it, how do we scale, what options we have, and what are the future plans?

Launch

When we create applications, we need to make them available to our clients, which requires a launch plan. You need to know what that plan is.

From my personal experience, there are several options.

Build an MVP and deploy it to clients, iterating improvements, or launch a 100% complete system from the start.

To return to our earlier example of the notification system, we might have an MVP that only sends emails, or a full application that sends 10 different types of notifications.

Another common option is to release the feature—whether as an MVP or completed—to a group of users and gradually increase its availability as you ensure it works as expected. And of course, explain how you implemented this from a technical standpoint.

Usually, this decision isn’t technical, but as a team member you should know why you chose your release strategy. And, of course, what the future plans are. NOTE: Some places will have an NDA or similar—never share sensitive information, but this usually isn’t the case.

Results

You should mention how you measure whether the system is a success or not. This usually depends on its usage, so here, talk about the metrics that define or indicate your system’s success. For a notification system, it could be as straightforward as usage, but every system in a company will have different metrics.

It’s usually enough to have a list of metrics to be evaluated and an explanation of why each one matters.

You should consider and mention the impact on the organization or customers. For instance: is it a new product? Did it generate sales? That’s a positive result for the company. Maybe including this system in an existing product helped win X number of clients from a competitor.

Lessons learned

You should mention what you learned—both you personally and at the company level—what decisions were made initially that later changed, and why.

Has any aspect of your company’s process changed as a result of this project? For example, the way launches are done, or even how projects are planned. Maybe you used to do waterfall development and with this project you became more agile.

Did you learn anything yourself? Maybe this was the first time you had to work with four or five different teams, so you’ve certainly learned something from that!

This learning also includes technical skills: Did you have to learn and implement technologies you weren’t familiar with? How did you realize you needed them, how did you learn them, and what impact did they have?

Of course, if there were any lessons involving end users—for example, if user feedback made you change part of the process—that’s important to mention too.

For this type of interview, you need to keep the company, yourself, and the client in mind—all aspects are equally important.