Основной идеей портала была система, в которой каждый участник имеет свою «карточку» (сущность внутри блокчейн сети), которая имеет свой баланс, факты о владельце (где работал, учился, участвовал), с возможностью их подтверждения. Кроме этого, каждая вакансия должна была иметь настраиваемое тестовое задание, после прохождения которого соискатель автоматически получает вознаграждение.
Разработка
Сразу после получения и обсуждения технического задания мы приступили к написанию контрактов. Первые их версии описывали минимально необходимую модель взаимодействия работодателя и соискателя: первые могли создавать вакансии, объявлять вознаграждение за прохождение её теста, вторые — искать вакансии, проходить тестирование и получать за это вознаграждение.
На этом этапе мы имели 3 контракта: работодатель, соискатель и вакансия. Проблемы такого подхода:
- Работодатель является единственным владельцем вакансии — он должен сам проводить отбор соискателей, или же передавать свой аккаунт в системе команде рекрутеров.
- Вся информация о том, на какие вакансии подписан соискатель, на данном этапе хранится в самом контракте соискателя, что увеличивает его размер и, соотвественно, цену размещения.
- Такая же ситуация и с контрактом вакансии — вся информация о соискателях, подписанных на неё, хранилась внутри самого контракта вакансии.
После мозгового штурма и нескольких литров кофе мы пришли к выводу, что необходимо создать единый контракт, назовем его оракул, который будет хранить информацию о всех участниках и их действиях. Так же было решено отказаться от контракта вакансии в пользу записи в контракте оракула.
Версия 1.0
На данном этапе появилась новая сущность — Oracle. Контракты работодателя и соискателя никуда не делись, но теперь они стали proxy контрактами, необходимыми для идентификации участников и выполнения ими своих действий — публикация вакансий, их включение или отключение, подписка на вакансии, получения вознаграждения и перевод полученных токенов на свои личные ETH аккаунты.
В то же время нам пришла идея — почему каждая вакансия имеет только 1 жестко закрепленный за ней тест? Тут родилась идея создания Vacancy pipeline.
Pipeline
Наш тимлид Кирилл Варламов так описал необходимость создания нужного функционала:
Рекрутинг это есть воронка с фильтрами. Аналогия — сначала дешевый фильтр грубой очистки (тест), потом более ресурсоёмкий фильтр тонкой очистки (KYC/интервью), потом чистовой фильтр (интервью с техническим специалистом).
Простейший фильтр это ревью анкеты сотрудником HR и одобрение или отказ от продолжения работы с кандидатом. Другой, дорогостоящий и трудозатратный вариант фильтра — личное собеседование. Продвинутый вариант это автоматизированный тест, дешевый и проходящий без участия человека. Он может быть, например, первым или вторым в цепочке движения соискателя.
На данном этапе непонятно какая последовательность будет работать лучше всего и какова стоимость исполнения каждого из шагов и эффективность. Скорее всего стоимость и качество будет отличаться у разных работодателей и по разным вакансиям. Работодатель должен иметь возможность кастомизировать последовательность шагов, по которым проходит соискатель. Архитектура должна поддерживать расширение типов шагов новыми вариантами.
Реализованная сейчас машинерия поиск->отклик->интервью недостаточно гибкая и сегодня не позволяет описать гибкий поэтапный процесс.
Тем же вечером появились первые наброски контракта, описывающие этот функционал.
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;
}
}
Естественно, код данного контракта был сильно упрощен, в нем не было привязки к
реальным токенам, отсутствовал CRUD для управления действиями, но процесс был запущен,
и нас было не остановить. Для себя мы определили несколько типов действий, из
которых строился pipeline:
- Wait action — подразумевает явное ожидание одобрения со стороны работодателя.
- Exam action — тестовое задание. Оно может содержать от одного вопроса
одного из нескольких видов — вопрос с одним ответом, с несколькими ответами и
вопрос, на который соискатель должен дать развернутый ответ.
Quiz applicationДля составления тестовых заданий было создано отдельное приложение, в котором вопросы
разделяются по категориям. Для каждого вопроса и ответа указывается так называемый вес,
благодаря которому появляется возможность гибкой настройки проходного балла.
Как автоматически проверять развернутый ответ?Для этих целей мы использовали алгоритм поиска расстояния между векторами,
построенными на основе заведомо правильного ответа и ответа соискателя.
- Interview action — живое интервью между соискателем и работодателем.
Каждое действие внутри pipeline имело своё вознаграждение, которое получит соискатель после успешного прохождения, могло быть approvable — тогда соискатель должен был ждать момента, когда работодатель проверит результаты ответов, например на exam action и явным образом «продвинет» соискателя на следующий уровень.
Пример pipeline глазами соискателя
На скриншоте ниже представлен самый базовый вариант pipeline. Он состоит из 3-х действий:
- В начале работодатель хочет лично одобрить или отклонить кандидатуру соискателя, посмотрев его профиль в системе, оценив его профессиональные качества и навыки. Вознаграждение за ожидание для соискателя — 10 токенов.
- Следующий шаг — тестовое задание. После того, как соискатель ответит на вопросы, система проверит его ответы и, на основе проходного балла, примет решения, «продвинуть» кандидата на следующее действие — интервью, или оставить право выбора за работодателем. Вознаграждение — 5 токенов.
- В конце пути соискателя — интервью с работодателем. В первой версии системы мы использовали простое приложение чат для общения работодателя и соискателя. Награда за данный шаг — 20 токенов.
На этом этапе оставалось несколько не закрытых вариантов использования системы:
- Действия соискателей проверяет всегда один человек — работодатель, разместивший вакансию.
- Участник, зарегистрированный в системе, всегда либо соискатель, либо работодатель.
Версия 2.0
Было принято решения отказаться от ролей участников системы — теперь каждый пользователь может как и раньше просматривать вакансии, откликаться на них, а также быть сотрудником компании. Для реализации этого функционала были разработаны контракты:
- Oracle — контракт никуда не делся, все так же описывал всю логику работы системы.
- Member — контракт участника системы. Описывает методы работы с контрактом оракула со стороны участника, такие как: создание вакансий, подписка на вакансию, создание компаний, управление членами компании и их ролями, CRUD для управления vacancy pipeline.
- Company — контракт компании. Теперь каждая вакансия принадлежит компании, вознаграждение за прохождение pipeline выплачивается с её счета.
- Facts — новый контракт, описывающий возможность для любого участника добавлять факты о себе и о других участниках, подтверждать факты других участников.
Благодаря новой системе отношений, у участников появилась возможность стать частью компаний, а у владельцев компаний — выбирать их роли: владелец, рекрутер или простой работник.
Кроме действий по настройке фильтров, рекрутеры, как это следует из названия роли, имеют возможность проверять результаты соискателей, проводить интервью, продвигать и отклонять кандидатов.
Результаты
Итоговым результатом нашей работы является портал, полностью удовлетворяющий возложенным на него обязанностям.
Шаги необходимые для размещения вакансии:
- Регистрация и заполнение своего профиля.
- Создание компании и зачисление токенов на её счет.
- Публикация вакансии, с описанием необходимых навыков и умений.
- Конфигурация и настройка vacancy pipeline.
- Включение вакансии.
После этих несложных шагов ваша вакансия появится в общем списке вакансий системы, а соискатели смогут откликнуться на неё и попробовать пройти весь путь от ожидания вашего одобрения до личной беседы с Вами.
Если Вы соискатель и хотите получить несколько токенов, а может быть и работу:
- Регистрация и заполнение своего профиля. Укажите прошлые места работы и основные обязанности, уровень образования и учреждения, в которых учились, свои достижения — так работодатель сможет лучше оценить Ваши умения, и у Вас появится шанс дойти до конца!
- На странице вакансий найдите вакансию, подходящую именно Вам и подпишитесь на неё.
- После прохождения первого шага, если он оплачиваемый — Вы получите свои первые токены в системе.
Код всего проекта полностью открыт и доступен на Github.
Комментарии (6)
jahr
22.08.2018 23:51Полезная статья с техническими подробностями, как минимум — хороший учебный пример, непонятно за что ее заминусовали.
Anton_Zh
23.08.2018 05:36А как быть с персональными данными соискателя? По 152 ФЗ частные лица (коими являются соискатели) имеют право на полное удаление своих ПД из БД любых сервисов. А у вас из блокчейна это как удаляется?
kvarlamo
23.08.2018 12:08Применение блокчейна и децентрализованных технологий скорее не ставит, а наоборот снимает вопрос хранения персональных данных. При соблюдении принципа Self-sovereign identity, персональные данные хранятся у субъекта, а в блокчейн попадают только пруфы (например, хэши от сырых данных, корни деревьев меркла и другие криптографические артефакты, из которых восстановить исходные данные невозможно). Предъявление и сопоставление сырых данных, при необходимости, обеспечивается стандартными криптографическими примитивами.
Прототип этими свойствами, конечно же, не обладает. Но он и по своему назначению не призван решить эту проблему, это отдельная история.Anton_Zh
24.08.2018 01:38Честно говоря, не очень понятно, что он вообще призван решить. В статье вроде описано, что люди на нескольких этапах думали, где хранить данные, и им не пришла мысль о ПД?
Тогда о какой децентрализации и открытом источнике информации о соискателях может идти речь, если данные о соискателях будут храниться в отдельной БД? Допустим обезличенная цепочка блоков доступна всем, но она не имеет смысла без данных, а передача ПД ограничена GDPR/ФЗ 152. Как другие участники системы при этом будут верифицировать изменения в цепочку блоков?
APXEOLOG
А для чего конкретно так необходима децентрализация в вашем случае?
И вдогонку: На что соискатель может потратить эти коины?
proofx Автор
Привет! Спасибо, хороший вопрос, ответ на который я забыл упомянуть в статье.
Децентрализация позволяет иметь открытый источник информации о вакансиях, кандидатах, реестра достижений и утверждений, возможности авторизации и аутентификации без зависимости от сторонних сервисов.
Коины можно вывести через централизованные и децентрализованные биржи, то есть преобразовать их в фиатные деньги. Встречный спрос стимулируется со стороны работодателей, которые заинтересованы в привлечении сотрудников.