How I Started Conducting Technical Interviews in 30 Minutes

Task

Over the past few years, I have significantly changed my approach to technical interviews. If once (7 years ago) I could cheerfully and provocatively interview Javist for two hours, then in my current position I don’t have that much time for each candidate. With 4 open positions and a performance of 10% (about 10% of candidates are interviewed and ready to accept the offer), it turns out that I need to conduct about 40 interviews. If you spend at least an hour on an interview, then this is an additional 40 working hours that you have to find somewhere. Plus throw 10 minutes to switch between tasks, it turns out another 400 minutes (~ 6.5 hours).

Therefore, I thought about the issue of improving the effectiveness of interviews.

For myself, I formulated it as follows: how to organize interviews so that you can make a hiring decision within 30 minutes.

The time limit is quite strong, but it makes it more interesting to analyze your experience and look for ways to reduce the time it takes to make a hiring decision. To reiterate the key point: in order to conduct a technical interview in 30 minutes, I need to learn how to make a hiring decision in those 30 minutes. Then, with a moderate workload, I can increase the duration of the interview to 50 or 60 minutes in order to get to know the candidate better. And with a significant workload, I can spend 40 minutes on an interview. Yes, you need to be honest: 5 minutes to enter the interview mode (reading the resume, entering the call), 30 minutes of the interview itself, 5 minutes to write a review for HR and exit the interview mode. As you can imagine, this is the perfect timing.

After analyzing my previous interviews, I formulated for myself several requirements and used several prerequisites in order to reduce the time of one interview without losing too much in performance.

Restrictions and prerequisites

To understand how to solve a problem, you need to understand or formulate the constraints:

1. I can’t effectively do more than 2 interviews a day, or just 7 a week. Better than 1 interview per day. Otherwise, I lose the ability to understand and feel the candidate.

2. The duration of the interview should not exceed 1 hour in the most extreme case. This is an artificial limitation. Its meaning is simple: if I didn’t understand in an hour whether I want to work with this person, then I Don’t want work with him.

3. To optimize something, you need to have sufficient empirical and theoretical experience. Those. Setting yourself the task of “quick” interviews at the beginning of the project is not very reasonable. Setting yourself such a task in a year and after 20-30 interviews is quite realistic.

4. The most important thing is that after the interview you can only have 2 answers: “take” or “not take”. No “maybe”, “if there are no others”, “we will decide later” and so on. Conducted an interview – made a decision.

Prerequisites for a scheduled technical interview:

1. Primary screening is carried out by an HR specialist. Only an interested candidate who is satisfied with our working conditions should get to the technical interview. Someone from the HR department can handle this perfectly.

2. The candidate must be approved by me. After the initial screening, I look at the resume and give the go-ahead for an interview.

Prerequisites for optimizing interviews

What can reduce the time to make a decision? What questions do you need to answer to yourself in order to understand: how to make a hiring decision within 30 minutes?

Understanding candidate requirements

The first question to be answered is: how well do I understand the requirements for the candidate?

I separate the candidate requirements into two different questions:

At the beginning of a project, especially if there has been a change in the technology stack for you, answering the first question is not easy. This means that you need to return to it regularly, look at those who work well, and especially those who do not work very well. Look at your notes about their answers in interviews and how it is correlates with their current success at work.

In my career, I have been able to clearly articulate these requirements for back-end javaists (8 years of leading web application development) and data engineers. (2 years of developing a data processing platform).

Understanding the requirements for a candidate leads to the next important question –

Possibility to formulate a test task

A good test task allows you to answer at least 4 questions:

• how the candidate understands the task, which correlates with how he will understand the requirements in the future

• as a candidate writes codewhich allows you to understand how he thinks and what will then be in the version control system.

• whether the candidate can complete the task to the end

• how the candidate relates to the requirements, whether he tries to comprehend them, whether he asks clarifying questions

Now I prefer live coding for 10-15 minutes. The most valuable 15 minutes of the interview. More than once I came across candidates who perfectly answer theoretical questions, but writing an SQL query for the position of a data engineer can be very difficult. A normal specialist will write my two test requests in 5-7 minutes without errors and misses. And this test task is perfectly correlated with how people then work. Just magically on all 4 points above.

I used to give javaists an offline task for 30-40 minutes, so that there would be something to discuss later at the interview. Experience and approach was immediately visible. And if a candidate sent in a code that didn’t work, how could I rely on such a candidate at work? Constantly monitor for errors? No thanks.

A respected reader may say that the candidate will not have enough time to do all the test items from all companies. Here my answer will be simple: if the candidate is not ready to do a test task for 40 minutes, then wait for him to refuse to do the work that seems uninteresting to him. Let this candidate be an excellent specialist, but I understand that –

Hiring mistakes are the norm

If someone was not mistaken in hiring, then let me be the first to refuse me at the interview.

Allowing the possibility of error is vital. When hiring, two mistakes can be made:

Obviously, with a flood of candidates, missing out on a good one isn’t as bad as hiring the wrong one. Even in the absence of a flow of candidates, it is better not to take the wrong one.

I am not afraid to refuse a good candidate according to my own formal criteria. Or because of personal antipathy, because I still have to work and work with him. So we come to the conclusion that –

Empathy and emotional intelligence decide

In order to make quick decisions, it is often necessary to rely on intuition. In the case of interviews, flair helps emotional intelligence. Or the feeling of how you work with a person. Sometimes it is impossible to work with some very cool specialist due to his character. So why do you need it? The candidate must fit into the team and team. And since you are making a decision, then on your shoulders, on the one hand, the opportunity to refuse unpleasant candidates, and on the other hand, the burden of responsibility to find someone who will fit in.

It turns out that you can use liking and disliking quite legally, especially considering that the mistake of “rejecting a good candidate” is acceptable.

Okay, given yourself permission to rely on emotions (“emotions as data”), what else can help you make decisions faster?

Dual purpose issues

In addition to the test task, I ask candidates a few questions about how they would solve some problems. It is important that the list of questions is constant. This allows you to minimize the comparison of candidates among themselves. And not only candidates, but also current good developers with candidates.

Also, these questions allow you to understand the approach to problem solving, previous experience, and stress resistance. Usually my questions are related to real problems, the solution of which was achieved with sweat and blood. Having a ready-made answer will perfectly describe the rich experience of the candidate, but the ability to quickly throw out 5-7 hypotheses on how to solve an unfamiliar problem will be even more valuable.

Try to formulate 2 questions for yourself that will allow you to understand whether the candidate will “survive” in this position or will constantly “slow down”.

All together and at once

In my practice, I try to combine all the points above and evaluate the candidate both as a technical specialist and as a living person. I understand who I need as a techie, I feel with whom I will be pleased to work, and I am not afraid to make mistakes.

I think that everyone can add a few more prerequisites, but the above has become a fairly formal justification for me that I can make a hiring decision in 30 minutes. If we take directly the exact timing, then it will be as follows:

• 5 minutes I talk about the project and why it is important for me to give test tasks

• 12 minutes – test tasks

• 5 minutes the candidate talks about himself

• 8 minutes – theoretical questions

  • After 30 minutes, I definitely have to decide for myself “yes” or “no”.

  • If my answer to the candidate is “yes”, then you can continue the interview and get to know each other better.

You can swap the candidate’s story about himself and test tasks, but it’s more important for me to see how a person writes code than what he can tell himself. Experience will show itself even in the simplest request, and a sane candidate will not be offended that I did not listen to his beautiful story about himself.

“Quick” interviews are not a myth, but a large amount of work on oneself and on the analysis of the project and the team.

Good candidates and interesting interviews!

I want to recommend to you free webinar from OTUS, where we will talk about the importance of presenting your achievements and building a personal brand in the work environment. If you are a specialist who believes that it is enough to work well for a successful career and everyone will know about it themselves, then our open lesson is for you. We will learn how to properly talk about your achievements with colleagues, management and in what format to get the most out of it. Let’s talk about how to help your subordinates learn to talk about their achievements. We will learn how to highlight our achievements and talk about why it is important to do it regularly. We will learn how to plan achievements and achieve your professional goals.