How Slack bot can accelerate the hiring process

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:

• Easy and fast search for suitable interviewers;
• Easy identification of free specialists ready for interviews;
• Ability to alert the interviewer about the upcoming meeting with the least expenditure of the recruiter’s time;
• Reduction of employee communication to the necessary minimum to free up time for flow tasks.

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:

• eliminate duplication of requests in personal correspondence,
• enable specialists to more flexibly determine the response time to such requests, and
• to evaluate the coincidence of requests with opportunities.

Solution advantages:

• The responsibility for identifying a suitable interviewer is now transferred to the professionals themselves. Everyone responds to the request themselves and understands their possible role at the meeting;
• The time spent communicating and waiting for answers is reduced;
• The solution automatically sends a scheduled meeting notification to the specialist who independently accepted the request;
• The solution can easily be integrated with existing tools;
• The time spent by recruiters to manage the requests is eliminated.

Disadvantages of the solution:

• A slow response to requests arises due to less responsibility on the part of specialists;
• During the execution of flow tasks, the information field of employees can be loaded with irrelevant requests;
• The solution does not enable recruiters to enumerate the total number of applicants per interviewer request.

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.

Solution advantages:

• Communication about the time of the meeting is reduced;
• A declaration of the interviewer’s capabilities for a predictable period of time is easily accessible.

Disadvantages of the solution:

• Additional actions for specialists within weekly tasks;
• Difficulty identifying suitable specialists due to additional comparisons of data in tables;
• Inability to notify the interviewer about the upcoming employment without direct contact;
• Additional time and effort spent filtering and updating information when working with tables;
• The possible intersection of requests and communication among different recruiters with interviewers.

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.

Solution advantages:

• Independent management of suitable time by the interviewer;
• Automated time reminder;
• Convenient search for a suitable specialist indicating the necessary parameters and date;
• Managed conflict resolution when booking time slots;
• Automatic time reservation notification;
• Control over data at every step of interaction;
• Reduction of communication between process participants to a minimum.

Solution Disadvantages:

• Self-management and support of the bot’s performance;
• Search for solutions that are universally suitable for most users in the implementation of the interface;
• A single process that does not suit all technical specialists.

To implement such a bot, the following set of technologies was chosen:

• Python 3.10 is the current version of the programming language used. It is fast to write, very commonly used, and also has a large developer community and many libraries to implement the plan;
• Slack Bolt library – the official library for working with Slack applications, available in Python;
• boto3 library – the official library for working with AWS. In our case it is necessary to interact with the DynamoDB database, available in Python;
• the google-api-client library – the official library for working with the Google API, is used to work with Google Calendar and provides the ability to interact with employee calendars in Google Workspace, available in Python;
• apscheduler library – an open-source library that provides the ability to schedule automatic execution of certain code at a specified time (time interval) with specified parameters.

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:

• handlers – contain classes that are used to catch interaction events with the bot;
• services – classes responsible for interacting with third-party services;
• database – classes for working with the database;
• middlewares – allows you to process requests before sending them to the handler directly through the context;
• blocks – universal blocks and buttons that are reused in handlers;
• utils – this includes the necessary helper classes (helpers) for working with timezones, mailing messages and time intervals.

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.

Database model:

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:

• Opening the modal window should occur within 3 seconds. To circumvent this limitation, an approach was chosen that involves opening a “waiting window” that contains the corresponding text, and after updating this window with data, which, for example, are taken from the database.
• The application must respond to Slack within 15 seconds to confirm that the request has been processed. For such a response, the Acknowledge function from the slack-bolt library is used, and the approach described in the previous paragraph also helped us to get around this limitation in places of long database queries or multiple queries.
• To save data, the user needs to send a message with the results of some operations. This helped us keep an additional history of user actions for further useful information for debugging.
• The blocks that are used to form the interface can be used in modal windows, in messages, and also on the Home page. It helps to build flexible interfaces. In our implementation, this feature is also used to display a message that is supposed to be sent to users. This way, bot admins also see what messages will look like for users.
• The ability to natively confirm user actions (confirm object) is made possible through a built-in interface element that can be attached to almost any user interaction. It allows you to display additional information explaining the consequences; for example, what will happen and how the bot will understand a field change or a button click.

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:

• [3500] time spans have been confirmed;
• [900] were booked by recruiters;
• Over 4,000 search queries were completed through the bot;
• 7 bots on the stage environment were created to work on the final result;
• 12 releases with functionality were deployed;
• 9 time zones are taken into account when working with the bot in all Grid Dynamics locations.

Although not described in this article, it is worth mentioning the following functionalities of the bot:

• Collection of statistical data and processing to obtain useful insights for management;
• Creation and management of information about interviewers by the administration of the bot and distribution of rights to work with this for representatives of the company’s management;
• Output of information from the database to users who are described there and the ability to set some parameters on the part of users;
• Sending messages and notifications to all user groups;
• Processing and displaying information about errors;
• Integration with Google Calendar to determine the time that can be used by interviewers;
• Marking of time intervals in which there are already confirmations from interviewers of similar parameters.

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!