.reveal{opacity:1!important;transform:none!important}
02HR и рекрутинг

Единая HR-платформа для массового найма и сопровождения кандидатов

Отклики с площадок доходят до найма без потерь, а кандидат видит свой статус в одном портале.

Платформа объединяет источники кандидатов, внутренний рекрутинг и портал кандидата в один процесс, снижая риск потери отклика между площадкой и командой.

Контекст
Отклик с площадки нужно принять без потерь, связать с вакансией и кандидатом и провести через общение, интервью и решение — при этом разные роли видят только разрешённый им срез данных.
Бизнес-проблема
Соединить внешние площадки с внутренним процессом найма так, чтобы отклик не терялся и не терял историю статуса при сбоях сети или повторной доставке.

Единый workflow с защитой от дублирования событий, ролевым доступом и отдельным порталом — рекрутер и кандидат в одном процессе, но с разными срезами данных.

От границ задачи до работающей системы

  1. 01 Проектирование модели кандидата, вакансии и этапов найма
  2. 02 Интеграционный слой с внешними площадками
  3. 03 Внутренний back office и портал кандидата
  4. 04 Контроль доступа и жизненного цикла персональных данных

Проблема

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

Пользователи и контекст

  • Рекрутер и менеджер работают с вакансиями, откликами, карточками кандидатов, назначают интервью и стажировку.
  • Руководитель управляет ролями, справочниками и видит агрегированные отчёты и состояние фоновых процессов.
  • Служба безопасности работает с отдельным, ограниченным по ролям срезом проверки кандидата.
  • Кандидат входит в отдельный портал, подтверждает согласие на обработку данных, переписывается с командой и получает уведомления о статусе.
  • Приём и дедупликация откликов с внешних площадок с сохранением событий, которые нельзя обработать сразу, для повторной попытки позже.
  • Единая карточка кандидата с историей статусов, интервью, стажировкой и решением по найму.
  • Асинхронная синхронизация статуса обратно на внешнюю площадку через отдельный устойчивый механизм с повторными попытками.
  • Мессенджер и портал кандидата с уведомлениями и живыми обновлениями статуса.
  • Ролевой доступ и анонимизация версия согласия на обработку персональных данных и автоматическая анонимизация по истечении срока хранения.
  1. Приём и дедупликация

    Система принимает вебхук-события с внешних площадок и сопоставляет отклик и кандидата с уже существующими записями по источнику и контактным данным.

  2. Назначение и коммуникация

    Отклику назначается ответственный с учётом идентичности кандидата на площадке; дальнейшее общение идёт через внутренний мессенджер с живыми обновлениями.

  3. Этапы найма

    Интервью, стажировка и решение о трудоустройстве фиксируются с историей статусов и причинами отказа.

  4. Синхронизация и хранение данных

    Изменение статуса надёжно передаётся обратно на площадку с повторными попытками; персональные данные анонимизируются по истечении срока хранения.

Обезличенный список вакансий и откликов на синтетических кандидатах
Back office: вакансии и отклики (реконструкция экрана, синтетические данные)
Карточка кандидата с выдуманными контактными данными
Карточка кандидата: контакты и история статусов (реконструкция экрана, синтетические данные)
Экран мессенджера с синтетической перепиской
Мессенджер: переписка рекрутера и кандидата (реконструкция экрана, синтетические данные)
Портал кандидата с примером статуса отклика
Портал кандидата: статус отклика и уведомления (реконструкция экрана, синтетические данные)

Слой коннекторов принимает события с внешних площадок и передаёт их в фоновые задачи, которые обновляют модель кандидата и вакансии; back office и портал кандидата используют общие данные с разными правами доступа, а живые обновления идут через отдельный канал сообщений.

  • Слой коннекторов к внешним площадкам
  • Фоновые задачи приёма и синхронизации
  • Back office
  • Портал кандидата
  • Канал живых обновлений
Общая модель кандидата, вакансий и статусов

Надёжность и безопасность

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

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

Почему важно Отклик не теряется из-за временной проблемы синхронизации данных.

Дедупликация учитывает не только идентификатор события, но и совпадение кандидата по контактным данным.

Проблема Внешняя площадка может повторно доставить одно и то же событие с новым идентификатором.

Почему важно Один и тот же кандидат не создаётся в системе повторно.

Исходящая синхронизация выполняется отдельным устойчивым механизмом с состоянием и повторными попытками.

Проблема Изменение статуса нужно синхронизировать с внешней площадкой надёжно, а не в рамках одного HTTP-запроса пользователя.

Почему важно Временная недоступность внешней площадки не приводит к потере изменения статуса.

Идентифицирующие поля анонимизируются автоматически по истечении настроенного срока хранения.

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

Почему важно Жизненный цикл персональных данных заложен в продукт, а не оставлен на ручной регламент.

Исходящее сообщение системы «усыновляется» при получении подтверждения от площадки вместо создания повторной записи.

Проблема Кандидат может написать в чат несколько раз, а исходящее сообщение оператора не всегда сразу получает идентификатор площадки.

Почему важно Переписка не задваивается даже при задержке подтверждения от внешней площадки.

Каждая исходящая операция синхронизации хранит собственное состояние и обрабатывается независимо от остальных.

Проблема Синхронизация статуса на площадку и автоответ кандидату — разные операции, и обе не должны зависеть от результата друг друга.

Почему важно Сбой одной операции не блокирует и не откатывает другую.

  • Python
  • Django
  • PostgreSQL
  • Celery
  • Redis
  • Channels / WebSocket
  • Docker Compose

Избранные проекты

Расскажите о процессе, который больше не помещается в текущие инструменты.

Достаточно коротко описать владельца, процесс, где теряются деньги или время, и какие системы уже используются. Сначала проверим, нужна ли собственная разработка вообще.

Или напрямую

Отправляя форму, вы принимаете условия обработки данных.