Technical interviews are an integral part of the hiring process in the tech industries, but depending on your experience as an effective engineering manager, conducting a technical interview may seem daunting.
Having played the role of a technical lead for half a decade and running a handful of technical interviews for all sorts of engineering roles, I’ll summarize all that I’ve learned in this single article.
So if you’ve been recently promoted to an engineering manager role or are just nervous about how to conduct a technical interview, this might be the step-by-step reference you’re looking for.
Table of contents
Step 1: Define the Objective of the Interview
This is one of the most important steps of the process, but unfortunately, it often gets overlooked by a lot of engineering managers. Although it’s obvious that you’re interviewing developers to hire for a certain role, that’s not the bigger goal.
Depending on the role you’re hiring for and the job description, the goal for an interview session may vary from sizing up candidates to pinning them down for a certain role.
Suppose you’re hiring for an entry-level front-end developer role, and you haven’t specified any particular tech stack in the job description. In that case, you may want to test the candidates on their overall understanding of front-end application development as a whole.
But if you’ve specified a certain tech stack, such as React or Angular, you may want to test the candidate’s understanding of the specified stack and overall understanding of front-end application development in general.
If you’re hiring for a senior role, chances are you have a very clear list of requirements. For example, if you’re working on a software development project that has very high traffic, you want a high level senior software developer to build up the core of the project. You'll need someone who has excellent technical knowledge of writing optimized software over anything else.
That doesn’t mean when hiring for senior posts, you’ll neglect their understanding of other aspects of software engineering, but often you’ll have some set priorities.
Unless you’ve made up your mind about what you want to assess during the interview process and what you don’t want to, you may end up leaving out important bits of information just because you didn’t have a clear idea of what you want in the first place.
Step 2: Creating a Standard Interview Process
Assuming you’ve set your goals and made up your mind about what you want to assess during the interview session, you’ll have to design a standard interview process that you can repeat for all the candidates.
This doesn’t essentially mean that you’ll make every candidate walk through the same corridors at the same pace. Of course, you’ll approach each candidate as you see fit, but the overall process should follow the same pattern.
It’s always a great idea to start by introducing the interviewers to the interviewee, followed by some small talk. When I say small talk, I don’t mean elaborate discussion on politics, religion, or current world problems because those will turn awkward eventually.
Rather, glance at the candidate’s social media or GitHub profile and think of things they are genuinely interested in. It can be video games, shows, books, mathematics, or anything else light-hearted. It’s important to keep the conversation positive.
This small talk session will not only help you assess the candidate's presentation but also will present you as a friendly, easy-to-talk person and will give the candidate a taste of how it may feel to be in this workplace.
Step 3: Asking the Right Interview Questions
Once the ice-breaking phase has finished, you’ll need to start moving toward the real deal. One of the most common mistakes that interviewers often make in this step is trying to improvise.
What you should be doing instead is preparing a pool of technical interview questions that you want to ask during the interview process. Also, do not pick questions at random from the pool.
Instead, try to be mindful of what projects the candidate has worked on in the past and what they’ve studied. For example, suppose a candidate has React-based projects on their GitHub profile. In that case, it’d be a good idea to keep the questions centered around React and the idea of reactivity in general instead of pulling questions based on something like Angular.
Of course, there will be questions, such as questions on version control and clean code, that you should ask every candidate, and that’s totally fine. You should tailor the more specific questions to the candidate’s knowledge base.
Now, if you have a tech stack specified in your job description or if you’re hiring for a senior role that requires a certain specialization, feel free to test the candidate’s technical abilities in those particular technologies as you see fit.
One thing that you avoid doing is trying to break the candidate. Often interviewers keep asking questions until the candidate fails to answer. This is not a good idea.
If you feel the candidate may be a good fit for a senior role, ask a few relevant questions and organize another interview. Trying to break a candidate to express superiority is a terrible approach.
If you need help asking the right questions, take a look at our compilation of interview questions for software engineers.
Step 4: Evaluating the Candidate’s Skills
Evaluating a candidate’s technical skills is not just about asking technical questions. One thing that I like to do is present them with a scenario and see how they’re solving the problem at hand.
I’m not a fan of whiteboard interviews, but I often bring a few flawed projects with me and ask the candidate if they can identify and solve the flaw. These projects may range from broken front-end applications to poorly implemented database schemas or queries.
I often don’t even expect the candidate to solve the problem in its entirety. I like to see what method they’re applying to solve the problem as fast as possible. It helps me to make an idea about their problem-solving capabilities.
Live coding challenges are good, but make sure you’re giving candidates relatable problems instead of abstract ones. When I find a candidate mentioning Project Euler, I give them one or two problems from the archived section to solve for the coding interview.
I’m not a big fan of whiteboard interviews since I’ve never felt any connection to them in the past. But if done right, whiteboard interviews can bring out a lot from a candidate. Again be mindful of the candidate’s capabilities and your priorities.
Finding a balance is important. Bombarding candidates with hard-to-solve problems is never a good way to evaluate them. After all, you can not expect humans to fly and camels to swim.
Adeva takes great care in the selection and screening process of its tech talent to ensure that they possess exceptional technical and communication skills. This rigorous screening process involves a triple-vetting system that evaluates the candidate's technical proficiency, soft skills, and work experience.
As a result of this thorough screening process, you can be confident the talent you hire through Adeva is of the highest quality. Our tech talent possesses the technical skills needed to complete any project successfully and the soft skills required to communicate and collaborate effectively with your in-house team. This translates to a reduced risk of missed deadlines and project derailment.
Step 5: Balancing Objectivity and Bias
Balancing objectivity and bias is extremely important during an interview. You may feel biased towards a candidate because of your similarities.
For example, I’ve had candidates who prefer using the same tools and utilities as I do and have a similar way of seeing things like me. But then I had to put someone who was using something that I wouldn’t touch until absolutely needed.
Interviewing is all about finding a candidate who fulfills the requirements of the job at hand. Knowing someone from university, or in my case, I’ve had a candidate who has been reading my books for a long time.
There are also cases when you may become empathetic toward someone’s circumstances. In my case, I had a candidate who traveled 12 hours to attend the interview but did very poorly. Although I felt terrible about her circumstances, I had to pick someone right for the job.
I’ve also been in situations where a candidate has been picked and called for negotiation. The moment the candidate started feeling that we needed a good developer and that they were the best of the bunch, the candidate began to take advantage of our necessities.
In such cases, even though the candidate was the best one for the job, I had to pick the second best and shape him or her according to our needs.
Interviewing and picking someone is a very humane process, but staying objective is crucial. Otherwise, you may have to suffer the consequences of bad hiring decisions for a long time.
Step 6: Following Up After the Interview
Following up after the interview is important. Keeping in touch with selected ones is important, but it’s also vital to send regretful messages to the ones who were cut off.
In the past, I’ve received regret messages from companies that only stated that I wasn’t selected. While that’s enough, as an interviewer, I always preferred to state the reason.
During the interview process, you should take notes on individual candidates separately. You can use these notes to send detailed regret messages about why you had to leave them behind, as well as a concise list of resources and suggestions to improve themselves.
Keeping the resumes of the candidates who almost made it is an excellent practice too. You’ll be able to address them if they decide to show up in a later interview. This will make them feel noticed and may give them a confidence boost for the second round.
Following up with the selected candidates is often done by the human resource department, but if there is a necessity for some technical reevaluation or something along the line, one of the interviewers who were present during the session should arrange an online or in-person meeting.
This will keep a sense of continuity and will not alienate the candidate. Otherwise, there will be unnecessary time wasted during the ice-breaking phase.
Conclusion
The key takeaways are as follows:
- Make sure you’re clear about what you want from this interview as one of the interviewers.
- Create a standard, repeatable interview process to avoid getting messy.
- Prepare the questionnaire beforehand and avoid improvising.
- Be mindful of the candidate’s capabilities and priorities.
- Evaluate the candidate in more than one method to make sure you’re right about them.
- Keep a balance between objectivity and bias.
- Finally, make the post-interview phase as smooth and transparent as possible.
Conducting a successful technical interview session is still a tough job, and you’ll get better as you go. Keep this article as a reference source that you can return to whenever needed.
