In-depth Technical Interview | Deep Dive Interview

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

In most cases, this part of the interview usually takes place “inside” another interview, or isn’t done so thoroughly, but in two processes specifically, the whole hour was dedicated to this interview.

In this post, we’ll explore what this interview is about.

1 - What the in-depth technical interview is about

Many people, as was my case until very recently, haven’t had these types of interviews. At least not as a standalone section within a selection process. Usually, some technical questions about the projects you’re currently working on and their technologies come up during one of the interviews. Since it’s part of a broader interview, most technologies are barely touched upon and that’s it.

In this case, the interview is the same but focused exclusively on a single real project for a whole hour. This interview usually takes place for relatively high-level development positions like Staff, Principal, or Distinguished Engineer in top companies like FAANG or similar. A small company whose main product isn’t software is not going to host such an exhaustive interview.

This means you need to know all the details of your application very well, since you’ll have to analyze in detail an application or system you’ve worked on recently.

It’s very important that the project you showcase is complex. Careful, I don’t mean it should be over-engineered, but the process itself shouldn’t just be a simple CRUD to a database with four events, it should have more substance. If the process is too simple, you could fail the interview, which isn’t entirely fair, since it’s not under your control.

Another important point is that the more impact the project has on customers, the better. As we’ll see later, this is a key element of the process.

Technically, you could show a hobby project you’ve worked on recently, but personally I don’t recommend it, since this interview will include very technical questions and will dig into technical problems that a hobby project may not have exposed you to in depth.

2 - Preparing for an in-depth technical interview

The key to passing the deep dive interview is having everything prepared in advance, and by this I mean having a document about the project you want to highlight. This step is useful both for the deep dive and for other processes where deep questions won’t be asked but you’ll still need to showcase your work.

My recommendation here is to generate a file for every project you work on at your company. Personally, it’s something I had never thought about, but having all this information in one file can also help you in the future, in 5 or 6 or even 10 years, to remember what you’ve worked on and to keep it well documented.

The file, which will be between 2 and 4 pages long, should cover the following:

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

Here is where you should describe the non-technical problems you faced.

You can write a small paragraph explaining what your company does and how this project fits into the current system.

This section focuses more on the product than the technical side, since companies ultimately sell a product and, as part of the company, it’s important to understand that product.

Technical implementation.

Now it’s time to explain the problem on a technical level. You should detail your role and how you were part of the process. Which parts of the system you worked on, this is important since in many cases a large system will involve several teams and perhaps you don’t have visibility over what those teams do. Mentioning this helps avoid being asked about parts you’re unfamiliar with, and if you are asked and don’t know exactly, it shouldn’t count against you.

For example, imagine you’ve worked on a notification system within your company, similar to what we covered in the system design course.

The best thing in this scenario is to mention you worked on that part of the process, and if you led it, highlight that too. You might be asked how it works, for example, the part of the system that sends emails, in our case, it was a third-party application, but it could also be another in-house team. Having a basic understanding of how these systems work is important.

I recommend having a picture or diagram of the system as it really helps refresh your memory.

During this part of the interview, you’ll mention the process and why it’s important to the company, but also what trade-offs you had to make and why.

In this specific diagram, there are several, for example, why our system uses events as the entry point instead of an HTTP call. That is a question you’ll very likely be asked.

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

What interviewers are trying to find out in this section is what technical challenges you faced in the process. So ideally, have all challenges and decisions documented, and why you made those choices.

Another example could be the use of a specific cloud technology, why did we choose it over another, how do we scale, what are our options, and what are our future plans?

Launch

When we build applications, we need to make them available to our customers, so we must have a launch plan. You need to know what that plan is.

From my personal experience, there are several options.

Build the MVP and deploy that to customers, iterating with improvements, or release a fully complete system from the beginning.

Returning to the earlier notification system example, you might have an MVP that only sends emails or a complete application that delivers 10 types of notifications.

Another common option is to roll out functionality, be it the MVP or full version, to a small group of users, and then gradually increase availability once you know and can guarantee it works as expected. And of course, explain how you technically implemented this option.

Normally, this decision has nothing to do with the technical side, but as team members we have to understand why we chose our go-live approach. And, of course, our future plans. But be mindful that some places require an NDA or similar, so don’t say anything sensitive, but that’s usually not the case.

Results

We need to mention how we measure whether the system is a success or not. Normally this will depend on its usage, here, mention the metrics that indicate whether your system is a success. For a notification system, it could be as simple as usage, but every system within a company will have different metrics.

Having a list of metrics to evaluate, along with explanations for why each metric matters, is generally enough in these cases.

We should mention the impact on the organization or the customers. For example, is it a new product? Has it generated sales? That results in a direct positive outcome for the organization. Maybe adding this system to an existing product enabled you to win X number of clients who were with a competitor.

Lessons learned

We need to talk about what we learned, both personally and as a company, what decisions were made initially and later changed, and why.

Has any part of the company’s process changed because of this project? For example, how releases are done or even how projects are planned. Maybe things used to be waterfall, and because of this project, the company now operates in a more agile way.

Did you personally learn something? Maybe in this project you had to work with 4 or 5 different teams for the first time in your career, and that brought new learnings.

This learning experience can also be technical, did you have to learn and implement technologies you didn’t know? How did you realize you needed them, how did you learn them, and what has their impact been?

Of course, if you learned something in terms of end-user impact, mention if user feedback made you change any part of the process.

For these types of interviews, you need to remember to focus on the company, yourself, and the customer, each point is equally important.