In the process of hiring new people in any company, there are several interrelated actions that need to be taken by the recruiter, the candidate and the company's specialists who participate in the stage of assessing future employees’ level of knowledge. In a general sense, hiring can be divided into stages that a candidate goes through from the moment of sending an application to receiving an offer from a recruiter to consider a vacancy. All of these stages require the expenditure of valuable time by current employees.
In the case of technical interviews, more often than not, a technician will want to be involved in the process. At this stage, the company's specialists check the candidate's hard skills, which requires time coordination between the three parties involved in the interview process: the recruiter, the candidate and the technician. The recruiter acts as a mediator both at the moment of agreement and directly at the interview.
To better illustrate the scale, imagine that the company has over 50 people on the recruiting team and about 900 engineers who are willing to participate in technical interviews.
The problem of coordinating the timing of such an interview is that technical specialists have their own set of tasks and free time slots that don’t always correspond with the recruitment team’s schedule. The time slots that can be used for a meeting are not always explicit and calculated without the personal consent of the two parties. As a result, in order for the recruiter to determine the time and relevant attendees able to participate in the interview, requires a fair amount of work. First, the recruiter needs to list all suitable specialists, then sort through this list and send a written request to each potential interviewer, and finally choose a convenient time that matches the candidate’s and the recruiter’s schedule. It goes without saying that all these activities take place during office hours, when a response from the interviewer can take anywhere from a few minutes to several hours. Thus, the speed of selecting the time of the meeting is highly dependent on the capabilities of the interviewer, both at the time of receipt of the request and at a convenient time for the candidate.
Summing up the current scenario, there are several points that must be satisfied by the decision:
The first decision to optimize the Grid Dynamics recruitment process was to concentrate the pool of interviewers and requests into one communication channel. A simple collection of information about the required parameters of an interview from a recruiter in communication channels - for example, in a Slack chat - is designed to:
Disadvantages of the solution:
A second option that could satisfy the set goals is to collect information about the capabilities of interviewers for a certain period in advance, and create a database to contain this information.
Disadvantages of the solution:
This option incorporated all the advantages of the previous solutions thanks to a Slack-based implementation. First of all, using an automated assistant, or, more simply, a bot, we can build a chain of actions for everybody involved in a way that prevents more non-compliance with approaches or instructions. By normalizing and defining the data nesting and distribution we need in the database, we also lose the complexity of working with direct data by providing the user of each of the roles with a specific interaction interface.
To implement such a bot, the following set of technologies was chosen:
Further to this, additional basic functions were written for the implementation, which are used to improve the quality of the code and the stability of its work.
For example, when receiving information about a user, at the output, we have a dictionary that can only be accessed through a string key. For such a case, functions are written that parse the data from the information received and issue exactly the requested one.
The infrastructure of the bot itself looks like this:
A small ORM (object relation model) was also written, which allows you to more flexibly and efficiently work with data that is stored in the database. In this case, we also get rid of working with associative arrays in favor of working with objects. Unfortunately, no ready-made solutions for working with DynamoDB were found.
The project consists of several parts:
As for setting up the application itself in Slack, in our case, we only needed the rights to send messages to users, permission to display the Home page (Home tab), as well as the ability to search for information in the Workspace for more convenient mapping of bot users and their information stored by Slack itself.
Common action handler workflow:
With the new App Settings interface, Slack lets you work directly with manifest.json to customize your apps. This was very helpful for further empowerment; for example, to allow a bot to share real-time error/bug logs in production.
The most convenient option for interacting with the bot was to use the display of modal windows that allow you to place up to 100 blocks of information. The nice thing is that such windows can have the ability to submit and contain blocks of information input (these are both selectors and text input). It is also convenient to use buttons that directly help to work with data associated with the information specified in the block.
The important aspects of working with the Slack Application are highlighted below:
As for the slack-bolt library itself, one of the most important aspects is the creation of interfaces using objects of classes of various blocks. The library also allows you to use dictionaries (dict) to define block information, however, it is sufficient to use the classes built into the library to get rid of many of the problems with validation on the Slack side. The main feature is also the ability to use various built-in options for receiving events and interacting with Slack servers. Of course, for the implementation of our bot, interaction through sockets was chosen.
Both recruiters and interviewers noted that the benefits of the bot are really great. This is also proven through the results below, which are taken into account by management to understand how the progress of hiring is improving and to obtain the necessary metrics for reporting, for example, for the last month:
Although not described in this article, it is worth mentioning the following functionalities of the bot:
Many of our clients work with Slack on a daily basis to solve routine tasks of the same type using traditional and manual methods such as personal communication, online chats or shared Google Docs, without realizing the great potential and benefits of working through automated assistants.
How will the bot develop further? There are many ideas on this, but one of the first would be to use a bot internally to find interviewers, to assess our internal engineers during their promotion, to work with our interns, etc. Plans are also already outlined for an API that would allow the bot to perform some action on requests from other services.
Interested to learn how Grid Dynamics can help streamline your recruitment processes with Slack bot? Get in touch with us to start a discussion!