Время, в котором мы живем, уже давно можно назвать периодом информационной децентрализации. Все больше проектов уходят от хранения информации на одном (или нескольких) серверах к использованию технологии Blockchain. Нашей команде в выпала честь стать частью большой идеи — разработка портала по поиску работы (Job Board), где основная часть бизнес логики реализована на так называемых смарт-контрактах.



Основной идеей портала была система, в которой каждый участник имеет свою «карточку» (сущность внутри блокчейн сети), которая имеет свой баланс, факты о владельце (где работал, учился, участвовал), с возможностью их подтверждения. Кроме этого, каждая вакансия должна была иметь настраиваемое тестовое задание, после прохождения которого соискатель автоматически получает вознаграждение.

Разработка


Сразу после получения и обсуждения технического задания мы приступили к написанию контрактов. Первые их версии описывали минимально необходимую модель взаимодействия работодателя и соискателя: первые могли создавать вакансии, объявлять вознаграждение за прохождение её теста, вторые — искать вакансии, проходить тестирование и получать за это вознаграждение.

На этом этапе мы имели 3 контракта: работодатель, соискатель и вакансия. Проблемы такого подхода:

  • Работодатель является единственным владельцем вакансии — он должен сам проводить отбор соискателей, или же передавать свой аккаунт в системе команде рекрутеров.
  • Вся информация о том, на какие вакансии подписан соискатель, на данном этапе хранится в самом контракте соискателя, что увеличивает его размер и, соотвественно, цену размещения.
  • Такая же ситуация и с контрактом вакансии — вся информация о соискателях, подписанных на неё, хранилась внутри самого контракта вакансии.

После мозгового штурма и нескольких литров кофе мы пришли к выводу, что необходимо создать единый контракт, назовем его оракул, который будет хранить информацию о всех участниках и их действиях. Так же было решено отказаться от контракта вакансии в пользу записи в контракте оракула.

Версия 1.0


На данном этапе появилась новая сущность — Oracle. Контракты работодателя и соискателя никуда не делись, но теперь они стали proxy контрактами, необходимыми для идентификации участников и выполнения ими своих действий — публикация вакансий, их включение или отключение, подписка на вакансии, получения вознаграждения и перевод полученных токенов на свои личные  ETH аккаунты.
В то же время нам пришла идея — почему каждая вакансия имеет только 1 жестко закрепленный за ней тест? Тут родилась идея создания Vacancy pipeline.

Pipeline


Наш тимлид Кирилл Варламов так описал необходимость создания нужного функционала:
Рекрутинг это есть воронка с фильтрами. Аналогия — сначала дешевый фильтр грубой очистки (тест), потом более ресурсоёмкий фильтр тонкой очистки (KYC/интервью), потом чистовой фильтр (интервью с техническим специалистом).

Простейший фильтр это ревью анкеты сотрудником HR и одобрение или отказ от продолжения работы с кандидатом. Другой, дорогостоящий и трудозатратный вариант фильтра — личное собеседование. Продвинутый вариант это автоматизированный тест, дешевый и проходящий без участия человека. Он может быть, например, первым или вторым в цепочке движения соискателя.

На данном этапе непонятно какая последовательность будет работать лучше всего и какова стоимость исполнения каждого из шагов и эффективность. Скорее всего стоимость и качество будет отличаться у разных работодателей и по разным вакансиям. Работодатель должен иметь возможность кастомизировать последовательность шагов, по которым проходит соискатель. Архитектура должна поддерживать расширение типов шагов новыми вариантами.

Реализованная сейчас машинерия поиск->отклик->интервью недостаточно гибкая и сегодня не позволяет описать гибкий поэтапный процесс.

Тем же вечером появились первые наброски контракта, описывающие этот функционал.

Код контракта 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;
      }
  }
  


Естественно, код данного контракта был сильно упрощен, в нем не было привязки к
реальным токенам, отсутствовал CRUD для управления действиями, но процесс был запущен,
и нас было не остановить. Для себя мы определили несколько типов действий, из
которых строился pipeline:

  • Wait action — подразумевает явное ожидание одобрения со стороны работодателя.
  • Exam action — тестовое задание. Оно может содержать от одного вопроса
    одного из нескольких видов — вопрос с одним ответом, с несколькими ответами и
    вопрос, на который соискатель должен дать развернутый ответ.

    Quiz application
    Для составления тестовых заданий было создано отдельное приложение, в котором вопросы
    разделяются по категориям. Для каждого вопроса и ответа указывается так называемый вес,
    благодаря которому появляется возможность гибкой настройки проходного балла.

    Как автоматически проверять развернутый ответ?
    Для этих целей мы использовали алгоритм поиска расстояния между векторами,
    построенными на основе заведомо правильного ответа и ответа соискателя.
  • Interview action — живое интервью между соискателем и работодателем.

Каждое действие внутри pipeline имело своё вознаграждение, которое получит соискатель после успешного прохождения, могло быть approvable — тогда соискатель должен был ждать момента, когда работодатель проверит результаты ответов, например на exam action и явным образом «продвинет» соискателя на следующий уровень.

Пример pipeline глазами соискателя


На скриншоте ниже представлен самый базовый вариант pipeline. Он состоит из 3-х действий:

  1. В начале работодатель хочет лично одобрить или отклонить кандидатуру соискателя, посмотрев его профиль в системе, оценив его профессиональные качества и навыки. Вознаграждение за ожидание для соискателя — 10 токенов.
  2. Следующий шаг — тестовое задание. После того, как соискатель ответит на вопросы, система проверит его ответы и, на основе проходного балла, примет решения, «продвинуть» кандидата на следующее действие — интервью, или оставить право выбора за работодателем. Вознаграждение — 5 токенов.
  3. В конце пути соискателя — интервью с работодателем. В первой версии системы мы использовали простое приложение чат для общения работодателя и соискателя. Награда за данный шаг — 20 токенов.



А можно больше действий?
Представленный вариант описывает лишь самый минимальный вариант настройки фильтров. Так, работодатель может не устанавливать действия ожиданий и сразу начать с тестовых заданий, которых может быть несколько (например первый тест на знание базовых вещей, не оплачиваемый, следующий — более узкоспециализированный, с объявленным вознаграждением). Количество действий ограничено 6-ю в базовом варианте, и может быть увеличено при необходимости.

На этом этапе оставалось несколько не закрытых вариантов использования системы:

  • Действия соискателей проверяет всегда один человек — работодатель, разместивший вакансию.
  • Участник, зарегистрированный в системе, всегда либо соискатель, либо работодатель.

Версия 2.0


Было принято решения отказаться от ролей участников системы — теперь каждый пользователь может как и раньше просматривать вакансии, откликаться на них, а также быть сотрудником компании. Для реализации этого функционала были разработаны контракты:

  • Oracle — контракт никуда не делся, все так же описывал всю логику работы системы.
  • Member — контракт участника системы. Описывает методы работы с контрактом оракула со стороны участника, такие как: создание вакансий, подписка на вакансию, создание компаний, управление членами компании и их ролями, CRUD для управления vacancy pipeline.
  • Company — контракт компании. Теперь каждая вакансия принадлежит компании, вознаграждение за прохождение pipeline выплачивается с её счета.
  • Facts — новый контракт, описывающий возможность для любого участника добавлять факты о себе и о других участниках, подтверждать факты других участников.

Благодаря новой системе отношений, у участников появилась возможность стать частью компаний, а у владельцев компаний — выбирать их роли: владелец, рекрутер или простой работник.

Работник
На работников компании, как и на остальные роли, накладывается только одно ограничение — они не могут подписываться на вакансии своей компании. Кроме этого никаких привилегий данная роль не предусматривает.

Рекрутер
Рекрутеры компании имеют право на конфигурацию действий внутри pipeline — настройку экзаменов (количество вопросов, сами вопросы, проходной балл), интервью (установка времени проведения, минимальной длительности).
Кроме действий по настройке фильтров, рекрутеры, как это следует из названия роли, имеют возможность проверять результаты соискателей, проводить интервью, продвигать и отклонять кандидатов.

Что за минимальная длительность в чате?
К этому времени мы полностью изменили систему интервью, и теперь это не просто чат с сотрудником компании, а внешний сервис для видео-интервью, и для его настройки появились новые параметры — список рекрутеров, ответственных за его проведение, дата и время начала и окончания и минимальная длительность, после которой система будет считать, что интервью состоялось. Например, сотрудник компании может настроить интервью так: я хочу проводить интервью с 1 до 20 января, с 8:00 до 18:00, длительностью в 10 минут — теперь система будет предлагать соискателям, добравшимся до этого действия, время, в которое сотруднику компании удобно провести интервью. Соискатель же в праве изменить автоматически предложенное время, главное условие — чтобы оно входило в установленные рамки и не было занято.


Владелец
Владельцы компаний получили, кроме возможностей всех предыдущих ролей, возможность создавать новые вакансии, указывая allowed amount, выстраивать первоначальный pipeline, указывая количество шагов, их тип и сумму вознаграждения.

Результаты


Итоговым результатом нашей работы является портал, полностью удовлетворяющий возложенным на него обязанностям.

Шаги необходимые для размещения вакансии:

  • Регистрация и заполнение своего профиля.
  • Создание компании и зачисление токенов на её счет.
  • Публикация вакансии, с описанием необходимых навыков и умений.
  • Конфигурация и настройка vacancy pipeline.
  • Включение вакансии.

После этих несложных шагов ваша вакансия появится в общем списке вакансий системы, а соискатели смогут откликнуться на неё и попробовать пройти весь путь от ожидания вашего одобрения до личной беседы с Вами.

Если Вы соискатель и хотите получить несколько токенов, а может быть и работу:

  • Регистрация и заполнение своего профиля. Укажите прошлые места работы и основные обязанности, уровень образования и учреждения, в которых учились, свои достижения — так работодатель сможет лучше оценить Ваши умения, и у Вас появится шанс дойти до конца!
  • На странице вакансий найдите вакансию, подходящую именно Вам и подпишитесь на неё.
  • После прохождения первого шага, если он оплачиваемый — Вы получите свои первые токены в системе.

Код всего проекта полностью открыт и доступен на Github.

Комментарии (6)


  1. APXEOLOG
    22.08.2018 17:51

    А для чего конкретно так необходима децентрализация в вашем случае?


    И вдогонку: На что соискатель может потратить эти коины?


    1. proofx Автор
      22.08.2018 19:06

      Привет! Спасибо, хороший вопрос, ответ на который я забыл упомянуть в статье.
      Децентрализация позволяет иметь открытый источник информации о вакансиях, кандидатах, реестра достижений и утверждений, возможности авторизации и аутентификации без зависимости от сторонних сервисов.
      Коины можно вывести через централизованные и децентрализованные биржи, то есть преобразовать их в фиатные деньги. Встречный спрос стимулируется со стороны работодателей, которые заинтересованы в привлечении сотрудников.


  1. jahr
    22.08.2018 23:51

    Полезная статья с техническими подробностями, как минимум — хороший учебный пример, непонятно за что ее заминусовали.


  1. Anton_Zh
    23.08.2018 05:36

    А как быть с персональными данными соискателя? По 152 ФЗ частные лица (коими являются соискатели) имеют право на полное удаление своих ПД из БД любых сервисов. А у вас из блокчейна это как удаляется?


    1. kvarlamo
      23.08.2018 12:08

      Применение блокчейна и децентрализованных технологий скорее не ставит, а наоборот снимает вопрос хранения персональных данных. При соблюдении принципа Self-sovereign identity, персональные данные хранятся у субъекта, а в блокчейн попадают только пруфы (например, хэши от сырых данных, корни деревьев меркла и другие криптографические артефакты, из которых восстановить исходные данные невозможно). Предъявление и сопоставление сырых данных, при необходимости, обеспечивается стандартными криптографическими примитивами.
      Прототип этими свойствами, конечно же, не обладает. Но он и по своему назначению не призван решить эту проблему, это отдельная история.


      1. Anton_Zh
        24.08.2018 01:38

        Честно говоря, не очень понятно, что он вообще призван решить. В статье вроде описано, что люди на нескольких этапах думали, где хранить данные, и им не пришла мысль о ПД?
        Тогда о какой децентрализации и открытом источнике информации о соискателях может идти речь, если данные о соискателях будут храниться в отдельной БД? Допустим обезличенная цепочка блоков доступна всем, но она не имеет смысла без данных, а передача ПД ограничена GDPR/ФЗ 152. Как другие участники системы при этом будут верифицировать изменения в цепочку блоков?