How to conduct a technical interview

At the same time, choosing the wrong one can be disastrous. However, the good hiring process is not only about being able to differentiate between the good and bad candidates – it also speaks a lot about your company and some of its values. A poorly handled technical interview or not knowing how to conduct a technical interview can really hurt your chances of finding the right fit for your team, or even be the reason for someone to not consider the position at all. And let’s not forget that a poor selection process leads to a possible bad developer onboarding, which can impact the entire team. 

With that being said, let’s now discuss the important aspects of knowing how to conduct a technical interview.

Presenting a project/position

One of the first things you will do during the interview is describe the position the candidate is applying for. This also includes the project(s) he/she will be working on with as many details as possible. This is extremely important, because this is where your future employee will spend most of their time and giving them enough information will greatly help them in deciding should they join your company or not (as well as lead to some interesting topics for discussion). However, in my personal experience, this step was something that many companies failed to do properly. Keep in mind that this does not mean that companies are generally bad at this – I am simply describing what I have experienced throughout my career. In most cases, too little information was given and sometimes some very important things (that should have been disclosed) were left out. You, as the hiring manager, are fully responsible for presenting the project and the requirements of the position – and you should do your best to provide a good overview.

So, what information do you need to share?

Well, the list is not short – for most of the points below, I provided brief explanations or questions that you will need to answer in order to provide a sufficient level of detail to your candidate.

Introduce yourself

State your current role and what are your main responsibilities. Describe how you and the candidate work together. Share some interesting facts about yourself.

Provide a brief overview of the project

Or maybe share a bit about the company history and some interesting facts (if possible). Let the other person know how the project fits into what the company is doing, how it will be used and who’s using it. It’s always nice to know that the product you are working on has an active user base.

Tech stack and overall architecture

This involves a lot of stuff – and this is one of the areas where you will probably spend the most time during a technical interview. You need to provide all relevant information about tools, frameworks and libraries that your team is using on a daily basis. Are your applications containerised? Are you using technologies like Kubernetes? Do you use AWS, Google Cloud, Azure or something else? Do you apply some specific architectural principles when developing your applications?

The process/how an average working day looks like

How do you write your stories and tasks, or do you write them at all? Are you using some of the methodologies like Scrum or Kanban? What are the necessary steps so one feature can reach the production? Are you doing code reviews?

Deployments and releases

How often do you release? Do you have planned outages because of releases or system upgrades? How long does the release take? Are releases generally problematic and involve many people across multiple teams?

Organisation and structure of the teams

How many people are in your team? Who does the team report to? Do you have T-shaped teams? Is there a lead developer? Are teams self-sufficient when it comes to development and maintenance of the project? Are there any other teams that you interact with on a regular basis?

Duties and main area of work

This one is self-explanatory.

Opportunities for growth

If I can name one topic that is rarely discussed, then this is it. One of the important aspects of the position (that needs to be evaluated when making a decision) is the potential for future growth. Is there any position to which the candidate can transition at some point? If there are multiple options – what are those options? Even more interesting, can people move from engineering to product or the other way around? 

However, describing the project or position during a technical interview would not be complete without mentioning some of the technical challenges that you are dealing with (or expecting to deal with) or the most common production issues that you are facing. This is important to mention, because facing those challenges might be one of the most important aspects of the project – and every project has its own set of challenges. Some of the examples could be:

• dealing with many 3rd party integrations,
• scaling the system so it can serve millions of customers at any point in time,
• facing huge traffic spikes on a regular basis.

Lastly, mention any topics that might be very specific for your project or the team and could potentially have an impact on the candidate’s final decision (for example, having a set on-call management procedure).

This may look like a lot of work (and it probably is), but the main reason to do this properly is to give the candidate the insight not only into his future role, but also into how you as a team (or company) are doing things. It’s not only about you being impressed by the candidate – this needs to go both ways.

Assessing previous experience

An integral part of knowing how to conduct a technical interview is taking a good look at the candidate’s CV, LinkedIn profile, GitHub profile, personal blog – or whatever resource the candidate submitted that can be used to assess their previous experience. Look for work experience that is relevant for the position. Pay close attention to things like:

• Similarities in role and responsibilities
• Technologies used: besides just the direct fit (meaning choosing Java developer for a Java project), look for similar technologies. For example, candidates that have experience with C# might be able to quickly familiarise themselves with Java. Also, candidates who used multiple programming languages and changed tech stacks during their career might be an interesting choice, because it could mean they can learn new languages quickly.
• Specific challenges that the candidate faced

What else can you assess?

In the case of candidates who have many years of experience, look for the willingness to learn new things during your technical interview, especially later in the career. Learning new things is one of the main parts of this job, as well as keeping your skills relatively up to date – good engineers know that and learning new things is probably second nature to them.

One more thing you should look for are the situations where the candidate willingly did something out of his comfort zone (out of curiosity or because of some other motivational factor).

However, you should keep in mind that there are also some seemingly unrelated details in a candidate’s CV that might uncover some interesting skills or can translate into some of the requirements for the position. For example, being a captain of a sports team might mean having some leadership potential. Organising meetups, tech talks or writing blog posts can be very useful for someone whose responsibilities might involve developer advocacy. That’s why it is always good to look for such things during a technical interview – because you can discover someone with a hidden talent.

Preparing for a technical interview

A good starting point on knowing how to conduct a technical interview would be to prepare a few important conversation topics in advance, based on the candidate’s experience.

However, you also need to prepare a set of questions which are relevant for the position or the project. Every job requires a specific mix of skills and knowledge. But you need to set a baseline and decide which skills and knowledge are absolutely necessary and which are nice-to-have. Your questions should reflect that, but keep in mind that the seniority level of the candidate and the requirements of the position will dictate how (and where) you set the bar. For example, let’s say that you are building and maintaining multiple java Microservices based on Spring Boot, that use REST APIs for interaction. Knowledge of microservice architecture, HTTP protocol and various Java-related concepts are probably a must-have in this case. Depending on how and where you deploy your services, your questions might include knowledge about CI/CD pipelines, containers, and technologies like Kubernetes. The list of potential questions can grow very quickly but try to stick to a few that cover the most critical areas.

Analyse depth of knowledge

Sometimes, you might want to assess the candidate’s depth of knowledge in the specific area. So make sure to have a couple of questions ready for something like that. For example, if a candidate seems to be very knowledgeable about designing REST APIs, you can try to discuss the concepts of Roy Fielding’s dissertation. These questions probably should not be a deciding factor when assessing the candidate’s knowledge, but there are cases where you want someone who can go deep on a specific subject.

Create your own interview strategy

Don’t just blindly copy how other companies are assessing the knowledge of candidates during an interview. If another company does something, it does not mean that you should. That is some other company working on a different project, so their process might look cool, but it reflects their needs, not yours. You should look for good ideas – but don’t just do something because XYZ is doing it. I cannot stress this enough, so I’ll repeat again: the questions you will ask during a technical interview must be relevant for the position and/or the project. Also, while It’s ok to sometimes “go wide” in your discussion with the candidate, avoid asking questions that are in no way related with what the candidate will be doing on the job. The same is true for bringing a huge list with dozens of questions and then randomly choosing a few of them – that will only show that you have no idea what you are looking for, nor what are the requirements of the position. Don’t do it.

Conclusion

In our next article, we will focus on topics like conversational style, coding assignments, and knowing when to stop the interview. Some of these topics are a bit controversial because there are many differing views on the subject. We will try to cover them in depth, so stay tuned!

---

Author

Miroslav Lazovic is an experienced software engineer from Belgrade. Over the past 15 years, he worked on many different projects of every size – from small applications to mission-critical services that are used by hundreds of thousands of users on a daily basis, both as a consultant or part of the development team.

Since 2016, he is focused on building and managing high-performing teams and helping people do their best work. He likes discussing various important engineering and management topics – and that’s the main reason for this blog. Besides that, Miroslav has quite a few war-stories to tell and probably far too many books and hobbies. There are also rumours of him being a proficient illustrator, but the origin of these rumours remains a mystery.

– Backend TL@Neon and Dev. Advocate @Holycode