How we completely changed the interviews
My name is Sasha, and I am managing backend-development at Tutu.ru. Today I will tell you why and how we completely changed the process of interviewing candidates for the past 2018.
Honestly, the selection was slow. Looking ahead, I’ll say that by the end of the year we increased the speed of recruiting 4 times, without losing as candidates. I hope I interested you. Reader, if you are a very harsh techie and want to read only about the technical interview, then you are at stage 2 :)
Our selection consisted of three stages:
In principle, this is a fairly standard scheme for the market. This is probably the only thing that survived the transformation process. Let's specifically consider each stage separately.
As they say, smart bigwigs of business: if you want to increase the sales funnel, increase the number of people who get into it. At the beginning of the year we were pretty bored with this: we posted vacancies on hh.ru, to which almost no one responded. HR-manager was looking for a resume and sent to review the head.
We saw two problems:
What to do?
Rewritten more fashionable youth. But product development taught us to check everything on data. We decided to check with two AV tests:
Both of the AV tests showed 0. “Just” did not work to solve the problem, we need to solve it systematically. We love that too. What hypotheses we put forward from this experiment: it seems that the text of a vacancy has little effect on the desire of people to work with us (it means you need to download the HR brand) and that people want to read something else.
We decided to start small and, it seems, did not lose. We did not invent mega-reports or put up stands at a huge conference, but decided to hold our meetings. But here’s the problem: there are only Symfoniacs from living php communities in Moscow, and we’re somehow not at all about Symfony. We decided to make our own: we looked for speakers, drew badges, drove reports 7 times. And yet it happened, and it happened twice: one , two . There will be a third, and more.
As time goes by, we can say for sure: mitts do not give an instant effect (dozens of resumes will not be sent to you at once), but they noticeably increase recognition. I hear more often: “Oh, and I have been with you.”
Everyone knows that the developer market right now is the job market. Good specialists almost every day receive job offers or invitations for an interview. And now let's try to imagine how much you need to go to face-to-face meetings (and even to each company several times). Looking for a dream job can turn into “Oh, God, that's enough already.” How can we, as a potential employer, help with this candidate?
For example:
So we introduced “one day offer” and “preliminary technical interview”. If the “offer in one day” is clear: we can hold all three interviews at a time, saving the applicant time for the trip, then I would like to dwell on the “preliminary technical interview”. Technicians are often good at software development, but not in resume writing. Well-designed resume, of which it is clear what the candidate did at the previous job, I would say that no more than 30 percent in the market. But it is interesting to learn not only what, but also how and why. To do this, I often want to talk, but (again) to go to the office for a long, expensive and insulting, if the interview ended quickly. (We believe that people want to constantly evolve and, if not interviewed today, may come back tomorrow with much deeper knowledge. Therefore, it is important to leave a good impression on all candidates).
As a result, we introduced a “preliminary technical interview”, but it is not that you are asked by phone “how to get out of vim”, but they will talk about what you did at your previous place of work, ask questions relevant to your qualifications . And most importantly: the developer will do this.
At this stage, we found two problems:
What was our technical interview a year ago: you get into a conversation for 1-1.5 hours with one of those. leads, solve puzzles for php, OOP, mysql. Then everything is at the discretion of each individual interviewer. Agree: if you are senior, it is strange to answer the question “how is the difference between isset and empty?”. And we are even stranger on the basis of these issues to decide that the candidate will be able to perform our tasks and do it coolly.
We thought: “But what does a candidate really need to know in order to do our tasks and develop?”. There were several answers:
It turns out that we do not need to purposefully ask anything about knowing the language, and this is interesting. But that's not all! We want to check in fact two things: does the candidate have the hard-skills that we need and check whether he has the potential for further development. So, you need to understand his career path as best as possible: what situations the candidate has already encountered in his projects and how he solved them. Therefore, first of all, we will find out what the candidate has done at previous jobs. After the interviewer gives tasks from our real subject area and checks how the candidate will cope with them. As a result, we have a formalized technical interview scenario, where the interviewer should answer certain questions. Interestingly, the time for interviewing new tasks has hardly changed - we still spend an average of 1.
In the course of the research of feedback, it turned out that today the candidate from the technical specialist who is interviewing him is no longer waiting for a simple “task-answer” dialogue and talks only on technical topics. The market is changing: candidates are interested in knowing exactly what tasks they will be solving, in which team, which technologies and approaches are used in related fields. Now we have each interviewer must know what business problems are solved in different teams, rough plans and the current state of technology, not only the backend, but all the other team roles.
I decided to make this point separately, because it is in almost any article about the interview, but still most of the companies sin with non-compliance. We now do not force to write code on a piece of paper. Each interviewer should bring a laptop with them, then the choice for the candidate.
Here the change was only one, but significant. Now, at each final meeting, in addition to the manager, a business representative from the team to which we want to take a candidate also goes. We want to establish a direct dialogue about the direction plans and the tasks to be solved.
It would seem: well, here, the employee is already in the company, why further steam? We have, since the founding of the company, a mentoring institution: each new employee receives a mentor in his team. But there was something to improve. Different teams have a different level of complexity of the subject area, and there is a temptation to send an employee to multi-day training before he starts performing his first task. As our practice has shown, after such training, a person usually remembers almost nothing, is sad, and time is wasted. Therefore, we introduced a rule: “An employee on the third day must take the task from the sprint.” The rule works perfectly in conjunction with the training system, where a beginner can learn the necessary knowledge at the exact moment when he needs it.
We also standardized the feedback process: every month we have a checklist for each employee. Feedback results are sure to come (both good and bad). As a result, by the end of the probationary period, we have a full-fledged employee who is able to solve problems and is integrated into the team
What do we have at the exit? The results are as follows:
So, the disposition at the beginning of the year
- We are growing rapidly - we need to recruit new employees
- The developer community thinks about us about "Well, this is a site with a schedule of electric trains - there probably are 3 people working in the basement." In fact, we now have 7 business lines and two dozen teams that work on them.By the way, a little about the trainsBy the way, there are 7 developers in the Electrics team, and there are also high-loaded microservices that we started to rewrite to go
- At the interview, we set logical tasks, php, OOP and database syntax tasks.
Honestly, the selection was slow. Looking ahead, I’ll say that by the end of the year we increased the speed of recruiting 4 times, without losing as candidates. I hope I interested you. Reader, if you are a very harsh techie and want to read only about the technical interview, then you are at stage 2 :)
Our selection consisted of three stages:
- interview with HR;
- technical interview;
- interview with the head of the department (me).
In principle, this is a fairly standard scheme for the market. This is probably the only thing that survived the transformation process. Let's specifically consider each stage separately.
Stage 0: recruiting
As they say, smart bigwigs of business: if you want to increase the sales funnel, increase the number of people who get into it. At the beginning of the year we were pretty bored with this: we posted vacancies on hh.ru, to which almost no one responded. HR-manager was looking for a resume and sent to review the head.
We saw two problems:
- very few people know about us as a tech company (the number of responses is close to zero);
- the vacancy is written "about like everyone else."
What to do?
And let's rewrite the job
Rewritten more fashionable youth. But product development taught us to check everything on data. We decided to check with two AV tests:
- created two identical vacancies on hh.ru, first with a different job title;
- put in these vacancies also a different text.
Both of the AV tests showed 0. “Just” did not work to solve the problem, we need to solve it systematically. We love that too. What hypotheses we put forward from this experiment: it seems that the text of a vacancy has little effect on the desire of people to work with us (it means you need to download the HR brand) and that people want to read something else.
Raise awareness
We decided to start small and, it seems, did not lose. We did not invent mega-reports or put up stands at a huge conference, but decided to hold our meetings. But here’s the problem: there are only Symfoniacs from living php communities in Moscow, and we’re somehow not at all about Symfony. We decided to make our own: we looked for speakers, drew badges, drove reports 7 times. And yet it happened, and it happened twice: one , two . There will be a third, and more.
As time goes by, we can say for sure: mitts do not give an instant effect (dozens of resumes will not be sent to you at once), but they noticeably increase recognition. I hear more often: “Oh, and I have been with you.”
Save time candidate
Everyone knows that the developer market right now is the job market. Good specialists almost every day receive job offers or invitations for an interview. And now let's try to imagine how much you need to go to face-to-face meetings (and even to each company several times). Looking for a dream job can turn into “Oh, God, that's enough already.” How can we, as a potential employer, help with this candidate?
For example:
- reasonably reduce the time spent on communication;
- try to find out something about candidates remotely.
So we introduced “one day offer” and “preliminary technical interview”. If the “offer in one day” is clear: we can hold all three interviews at a time, saving the applicant time for the trip, then I would like to dwell on the “preliminary technical interview”. Technicians are often good at software development, but not in resume writing. Well-designed resume, of which it is clear what the candidate did at the previous job, I would say that no more than 30 percent in the market. But it is interesting to learn not only what, but also how and why. To do this, I often want to talk, but (again) to go to the office for a long, expensive and insulting, if the interview ended quickly. (We believe that people want to constantly evolve and, if not interviewed today, may come back tomorrow with much deeper knowledge. Therefore, it is important to leave a good impression on all candidates).
As a result, we introduced a “preliminary technical interview”, but it is not that you are asked by phone “how to get out of vim”, but they will talk about what you did at your previous place of work, ask questions relevant to your qualifications . And most importantly: the developer will do this.
Stage 1: HR
At this stage, we found two problems:
- We had logical puzzles divorced from reality (hello to the balloons in the plane and sewer manholes), which, as practice shows, can not always reveal the potential of the candidate, but create negative quite often. Worse, it happened that the candidate went home just because he did not solve the problem - this creates a bad reputation. In general, we no longer have any logical tasks from the textbook at the interview: we check system thinking and the ability to think outside the box at a technical interview with tasks arising in real life.
- We did not collect the candidate’s feedback about the interview with us at all. Now we collect, build metrics and work so that the candidate experience is good.
Stage 2: Technical Interview
Tasks
What was our technical interview a year ago: you get into a conversation for 1-1.5 hours with one of those. leads, solve puzzles for php, OOP, mysql. Then everything is at the discretion of each individual interviewer. Agree: if you are senior, it is strange to answer the question “how is the difference between isset and empty?”. And we are even stranger on the basis of these issues to decide that the candidate will be able to perform our tasks and do it coolly.
We thought: “But what does a candidate really need to know in order to do our tasks and develop?”. There were several answers:
- To just do the tasks:
- OOP and refactoring (We support beautiful solutions, and we still have a monolith)
- Designing an API (The same monolith needs to be beaten on microservices, we only solve new tasks on microservices. Designing a good API in today's world is the most important skill of a backend developer)
- To be able to work with an external API (We have many different partners with different levels of API quality)
- Must understand in the database in a broad sense (SQL and various NoSQL solutions)
- It would be nice if I knew something about unit tests (if we teach anything) and use the right tools for developing
- To cool to do their job and develop:
- Have deep theoretical knowledge in their field
- Be able to effectively apply the theory in practice
It turns out that we do not need to purposefully ask anything about knowing the language, and this is interesting. But that's not all! We want to check in fact two things: does the candidate have the hard-skills that we need and check whether he has the potential for further development. So, you need to understand his career path as best as possible: what situations the candidate has already encountered in his projects and how he solved them. Therefore, first of all, we will find out what the candidate has done at previous jobs. After the interviewer gives tasks from our real subject area and checks how the candidate will cope with them. As a result, we have a formalized technical interview scenario, where the interviewer should answer certain questions. Interestingly, the time for interviewing new tasks has hardly changed - we still spend an average of 1.
Process
In the course of the research of feedback, it turned out that today the candidate from the technical specialist who is interviewing him is no longer waiting for a simple “task-answer” dialogue and talks only on technical topics. The market is changing: candidates are interested in knowing exactly what tasks they will be solving, in which team, which technologies and approaches are used in related fields. Now we have each interviewer must know what business problems are solved in different teams, rough plans and the current state of technology, not only the backend, but all the other team roles.
Cherry on the cake
I decided to make this point separately, because it is in almost any article about the interview, but still most of the companies sin with non-compliance. We now do not force to write code on a piece of paper. Each interviewer should bring a laptop with them, then the choice for the candidate.
Stage 3: Final
Here the change was only one, but significant. Now, at each final meeting, in addition to the manager, a business representative from the team to which we want to take a candidate also goes. We want to establish a direct dialogue about the direction plans and the tasks to be solved.
Stage 4: Adaptation
It would seem: well, here, the employee is already in the company, why further steam? We have, since the founding of the company, a mentoring institution: each new employee receives a mentor in his team. But there was something to improve. Different teams have a different level of complexity of the subject area, and there is a temptation to send an employee to multi-day training before he starts performing his first task. As our practice has shown, after such training, a person usually remembers almost nothing, is sad, and time is wasted. Therefore, we introduced a rule: “An employee on the third day must take the task from the sprint.” The rule works perfectly in conjunction with the training system, where a beginner can learn the necessary knowledge at the exact moment when he needs it.
We also standardized the feedback process: every month we have a checklist for each employee. Feedback results are sure to come (both good and bad). As a result, by the end of the probationary period, we have a full-fledged employee who is able to solve problems and is integrated into the team
Conclusion
What do we have at the exit? The results are as follows:
- The number of responses to a vacancy has changed from “almost never” to “every month several responses”
- Pickup speed increased 4 times with the same quality
- We have a standard technical assessment framework for technical specialists, which allows you to understand well how the future employee will cope with the work.
- Optimized your time and the time of the candidate
- Groped how best to carry out the adaptation inside