📜 ⬆️ ⬇️

Recruitment of a new level - using Ethereum

The time in which we live has long been called the period of information decentralization. More and more projects are moving away from storing information on one (or several) servers to using Blockchain technology. Our team was honored to become part of a big idea - the development of a job search portal (Job Board), where the main part of the business logic is implemented on the so-called smart contracts .



The main idea of ​​the portal was a system in which each participant has his own “card” (an entity within the network blockchain), which has its own balance, facts about the owner (where he worked, studied, participated), with the possibility of confirming them. In addition, each vacancy should have a custom test task, after which the applicant automatically receives a reward.

Development


Immediately after receiving and discussing the terms of reference, we began to write contracts. Their first versions described the minimally necessary model of interaction between the employer and the applicant: the first could create vacancies, declare a reward for passing her test, the second - look for vacancies, get tested and receive remuneration for it.
')
At this stage, we had 3 contracts: the employer, the applicant and the vacancy. Problems of this approach:


After brainstorming and a few liters of coffee, we came to the conclusion that it was necessary to create a single contract, let's call it an oracle, which will store information about all the participants and their actions. It was also decided to abandon the contract vacancies in favor of recording in the contract of the oracle.

Version 1.0


At this stage, a new entity - Oracle. The employer's and applicant's contracts have not gone away, but now they have become proxy contracts necessary for identifying participants and performing their actions — publishing vacancies, turning them on or off, subscribing to vacancies, receiving remuneration and transferring received tokens to their personal ETH accounts.
At the same time, an idea came to us - why does each vacancy have only one rigidly assigned test for it? Then the idea of ​​creating the Vacancy pipeline was born.

Pipeline


Our team leader, Kirill Varlamov , described the need to create the necessary functionality:
Recruiting is a funnel with filters. The analogy is first a cheap coarse filter (test), then a more demanding fine filter (KYC / interview), then a clean filter (interview with a technical specialist).

The simplest filter is a questionnaire review by an HR officer and approval or refusal to continue working with a candidate. Another, costly and time-consuming option of the filter is a personal interview. An advanced version is an automated test, cheap and passing without human intervention. It may be, for example, the first or second in the chain of motion of the applicant.

At this stage, it is unclear what sequence will work best and what is the cost of each step and efficiency. Most likely, the cost and quality will be different for different employers and for different vacancies. The employer should be able to customize the sequence of steps that the applicant is taking. The architecture must support the extension of step types with new variants.

The search engine-> response-> interview now implemented is not flexible enough and today does not allow us to describe a flexible step-by-step process.

The same evening, the first contract drafts appeared describing this functionality.

Contract code Pipeline.sol
pragma solidity ^0.4.21; contract Pipeline { struct Pipeline { bytes32 title; bool is_payable; bool is_approvable; } mapping (address => uint256) public balances; Pipeline[] public stages; mapping(address => Pipeline) public candidate_stages; mapping(address => mapping(bytes32 => bool)) candidate_paid_stages; // ["first","second","third","four"],[false,true,true,false] function new_pipelines(bytes32[] _titles, bool[] _is_payable) public { require(_titles.length < 10); require(_titles.length == _is_payable.length); for (uint8 i=0; i < _titles.length; i++) { stages.push(Pipeline(_titles[i], _is_payable[i])); } } function new_candidate(address _candidate) public { candidate_stages[_candidate] = stages[0]; } function next_stage(address _candidate) public returns(bool) { for (uint8 i = 0; i < stages.length - 1; i++) { if (stages[i].title == candidate_stages[_candidate].title) { candidate_stages[_candidate] = stages[i+1]; return true; } } } function test_pay_to_candidate(address _candidate) public { require(candidate_stages[_candidate].is_payable); require(!candidate_paid_stages[_candidate][candidate_stages[_candidate].title]); balances[_candidate] += 5; candidate_paid_stages[_candidate][candidate_stages[_candidate].title] = true; } } 


Naturally, the code of this contract was greatly simplified, it was not tied to
real tokens, there was no CRUD to control actions, but the process was started,
and we were not stopped. For ourselves, we have defined several types of actions, from
which pipeline was built:


Each action inside the pipeline had its reward, which the applicant received after successful completion, could be approvable - then the applicant had to wait for the moment when the employer checked the results of the answers, for example, on the exam action and “advance” the applicant to the next level.

Example pipeline eyes of the applicant


The screenshot below shows the most basic version of the pipeline. It consists of 3 actions:

  1. At the beginning, the employer wants to personally approve or reject the candidacy of the applicant, looking at his profile in the system, assessing his professional qualities and skills. Waiting reward for the applicant - 10 tokens.
  2. The next step is a test task. After the applicant answers the questions, the system will check his answers and, on the basis of the passing score, will make decisions, “advance” the candidate to the next action - an interview, or leave the employer the right to choose. Reward - 5 tokens.
  3. At the end of the path of the applicant - an interview with the employer. In the first version of the system, we used a simple chat application for communication between the employer and the applicant. The reward for this step is 20 tokens.



Can you do more action?
The presented option describes only the most minimal option to configure filters. Thus, an employer may not establish the actions of expectations and immediately begin with test tasks, which may be several (for example, the first test for knowledge of basic things, unpaid, the next — more specialized, with a declared reward). The number of actions is limited to the 6th in the basic version, and can be increased if necessary.

At this stage, there were several unclosed options for using the system:


Version 2.0


It was decided to abandon the roles of the participants of the system - now each user can, as before, view vacancies, respond to them, and also be an employee of the company. To implement this functionality, contracts have been developed:


Thanks to the new system of relations, the participants had the opportunity to become part of companies, and the owners of companies - to choose their roles: owner, recruiter or simple employee.

Worker
On employees of the company, as well as on other roles, only one restriction is imposed - they cannot subscribe for vacancies of their company. In addition, this role does not provide any privileges.

Recruiter
Recruiters of the company have the right to configure actions within the pipeline - setting up exams (the number of questions, the questions themselves, passing score), interviews (setting the time for conducting, the minimum duration).
In addition to actions to set up filters, recruiters, as the name implies, have the opportunity to check the results of applicants, conduct interviews, promote and reject candidates.

What is the minimum duration in the chat?
By this time, we completely changed the interview system, and now this is not just a chat with a company employee, but an external service for video interviews, and new parameters have appeared for setting it up - the list of recruiters responsible for conducting it, the start and end date and time the minimum duration after which the system will consider the interview to take place. For example, an employee of a company can set up an interview like this: I want to conduct an interview from January 1 to January 20, from 8:00 to 18:00, lasting for 10 minutes - now the system will offer time to which an employee of the company will get to this action. convenient to conduct an interview. The applicant, however, has the right to change the automatically offered time, the main condition is that it should fall within the established framework and not be occupied.


Owner
The owners of companies received, in addition to the capabilities of all previous roles, the ability to create new vacancies, indicating the allowed amount , build the initial pipeline, indicating the number of steps, their type and amount of remuneration.

results


The final result of our work is a portal that fully satisfies the duties assigned to it.

Steps necessary for posting a job:


After these simple steps, your vacancy will appear in the general list of system vacancies, and applicants will be able to respond to it and try to go all the way from waiting for your approval to a personal conversation with you.

If you are a job seeker and want to get a few tokens, and maybe work:


The code for the entire project is completely open and available on Github .

Source: https://habr.com/ru/post/420961/


All Articles