Рекрутер в ИТ: от новичка до профессионала (включая сорсинг)

Курс обучает полному циклу IT-рекрутмента: от понимания рынка и ролей до сорсинга, интервью и оффера. Вы освоите инструменты поиска, оценку кандидатов, работу с заказчиком и аналитикой, а также построите устойчивый процесс найма.

1. Введение в IT-рекрутмент: роли, рынок, процессы и этика

Введение в IT-рекрутмент: роли, рынок, процессы и этика

Что такое IT-рекрутмент и чем он отличается от «обычного» подбора

IT-рекрутмент — это подбор специалистов для разработки и эксплуатации цифровых продуктов: от мобильных приложений и веб‑сервисов до инфраструктуры, аналитики данных и кибербезопасности.

Главная особенность IT‑подбора в том, что рекрутеру приходится работать с:

  • быстро меняющимся рынком и технологиями
  • высокой конкуренцией за кандидатов
  • большим количеством специализаций и уровней (junior/middle/senior)
  • оценкой не только «софт‑скиллов», но и технического контекста вакансии
  • При этом IT‑рекрутер не обязан уметь программировать. Но он обязан понимать язык рынка: что именно делает специалист, чем отличаются роли, какие ожидания у кандидатов и как устроен процесс найма.

    Участники процесса: кто есть кто

    IT‑подбор — это командная работа. Внутри компании обычно участвуют несколько ролей.

    | Роль | Что делает | Типичные зоны ответственности | |---|---|---| | Рекрутер | Ведёт вакансию end‑to‑end | сбор требований, интервью с кандидатами, координация этапов, оффер, коммуникация со стейкхолдерами | | Сорсер | Находит и привлекает кандидатов | поиск, составление списков, первичные сообщения, работа с каналами и базами | | Hiring manager (нанимающий руководитель) | Владелец потребности в найме | формулирует требования, принимает решение, участвует в интервью | | Технический интервьюер | Оценивает профессиональные навыки | техинтервью, проверка практического опыта, рекомендация по уровню | | HR/People partner | Следит за процессом и политиками | грейды, компенсации, согласования, онбординг, политика найма | | Recruitment coordinator | Помогает с организацией | расписание интервью, письма, документы, логистика |

    Важно различать:

  • Сорсинг — это поиск и первичное привлечение (часто про «холодный» контакт и работу с воронкой откликов/ответов).
  • Рекрутинг — более широкий цикл: от старта вакансии до выхода человека (и часто включая аналитику, переговоры, координацию интервью).
  • Рынок IT: почему кандидаты «ведут» процесс

    В IT кандидаты часто выбирают из нескольких вариантов. Это формирует реальность, где ценятся:

  • скорость (компания, которая медлит, теряет кандидатов)
  • качество коммуникации (уважение времени и прозрачность)
  • понятные условия (диапазоны, формат работы, задачи, команда)
  • Чтобы лучше понимать аудиторию, полезно регулярно смотреть на общерыночные отчёты:

  • Stack Overflow Developer Survey 2024 — про профили разработчиков, технологии и предпочтения
  • GitHub Octoverse — про тренды в разработке и активность сообществ
  • Эти источники не заменяют аналитику по конкретной стране/городу, но помогают видеть общую картину: какие технологии «на слуху», как меняются форматы работы, на что обращают внимание специалисты.

    Базовый процесс IT‑подбора: от запроса до выхода

    Ниже — типовая схема. В реальности шаги могут объединяться или переставляться, но логика почти всегда похожа.

    !Наглядная карта этапов найма и ответственности

    Intake: снятие требований (старт вакансии)

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

    На intake обычно фиксируют:

  • роль и задачи на первые 3–6 месяцев
  • обязательные навыки и «желательные» навыки
  • уровень (junior/middle/senior) и критерии уровня
  • формат работы (офис/гибрид/удалёнка), график, локация
  • вилка/диапазон компенсации и тип занятости
  • этапы интервью и кто принимает решение
  • Результат intake — понятный профиль, по которому можно:

  • корректно искать людей
  • правильно презентовать роль кандидату
  • оценивать кандидатов одинаковыми критериями
  • Поиск кандидатов: inbound и outbound

    Обычно используют два потока:

  • Inbound — входящие отклики (например, через карьерный сайт или площадки)
  • Outbound — исходящий поиск и «холодные» сообщения (сорсинг)
  • В IT outbound особенно важен, потому что сильные специалисты часто не откликаются сами.

    Первичный контакт (outreach)

    Outreach — первое сообщение кандидату.

    Хорошее outreach‑сообщение:

  • короткое и уважительное
  • сразу объясняет контекст (компания, команда, продукт)
  • содержит суть роли (задачи, стек на уровне «в целом», формат)
  • не требует «сразу прислать резюме», если есть профиль
  • предлагает удобный следующий шаг (созвон/переписка)
  • Скрининг рекрутера (recruiter screen)

    Скрининг — короткое интервью (часто 20–40 минут), где рекрутер проверяет соответствие базовым требованиям и риски.

    Обычно обсуждают:

  • опыт и роль кандидата в проектах
  • мотивацию к смене работы и ожидания
  • условия (зарплата, формат, сроки выхода)
  • коммуникацию и адекватность ожиданий
  • Цель скрининга — не «оценить код», а:

  • понять, стоит ли тратить время команды на следующие этапы
  • собрать вводные для техинтервью (на что смотреть глубже)
  • Технические и командные интервью

    Технические этапы различаются по компаниям, но почти всегда включают:

  • оценку реального опыта (проекты, решения, ответственность)
  • проверку уровня по ключевым навыкам
  • обсуждение подходов (например, тестирование, код‑ревью, дизайн)
  • Командное/менеджерское интервью часто фокусируется на:

  • взаимодействии в команде
  • ответственности, самостоятельности, зрелости
  • совпадении ожиданий по задачам и темпу
  • Оффер и переговоры

    Оффер — формальное предложение кандидату. Важно, чтобы до оффера кандидат понимал:

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

    Онбординг и «закрытие цикла»

    Даже после принятия оффера остаются риски:

  • контр‑оффер от текущего работодателя
  • изменение обстоятельств у кандидата
  • затягивание документов
  • Поэтому рекрутер поддерживает контакт до выхода и помогает команде подготовиться к онбордингу.

    Воронка рекрутмента: почему важны цифры, а не «ощущение»

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

    !Пример воронки и точек улучшения

    Часто используют такие метрики:

    | Метрика | Что означает | Зачем нужна | |---|---|---| | Time to fill | время от открытия вакансии до принятия оффера/закрытия | показывает, как быстро компания закрывает потребность | | Time to hire | время от первого контакта с кандидатом до принятия оффера | показывает скорость этапов и потери времени внутри процесса | | Offer acceptance rate | доля принятых офферов | сигнал о конкурентности условий и качестве работы с ожиданиями | | Response rate | доля ответов на outreach | показатель качества сорсинга и сообщений | | Source of hire | откуда пришёл кандидат (канал) | помогает вкладываться в работающие источники |

    Важно: метрики — это не «оценка рекрутера как человека», а инструмент улучшения процесса. Например, низкий response rate чаще говорит о качестве списка и текста, а не о «плохом рекрутере».

    Этика и профессиональные принципы в IT‑рекрутменте

    Этика в рекрутменте — это не абстракция, а ежедневные решения, которые влияют на репутацию компании и вашу личную репутацию на рынке.

    Конфиденциальность и персональные данные

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

    Практики, которые считаются базовой нормой:

  • не передавать резюме/профиль третьим лицам без понятного основания и согласия
  • хранить данные ограниченное время и в защищённых системах
  • не обсуждать кандидата «в коридоре» и в неролевых чатах
  • Если вы работаете с кандидатами из ЕС или ваша компания там присутствует, вам важно понимать логику GDPR.

  • Общий регламент ЕС по защите данных (GDPR), официальный текст
  • Честность в коммуникации

    Этичная коммуникация — это:

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

    В рекрутменте легко допустить предвзятость — неосознанное предпочтение «похожих на нас».

    Профессиональный подход включает:

  • оценку по критериям роли, а не по «нравится/не нравится»
  • одинаковые вопросы и структура интервью для сопоставимых кандидатов
  • аккуратность с личными темами (возраст, семья, здоровье), если они не относятся к работе
  • Отказ и обратная связь

    Отказывать — часть работы. Этичный отказ:

  • своевременный
  • нейтральный по тону
  • по возможности с короткой, корректной причиной (без оценочных ярлыков)
  • Не всегда можно дать подробный фидбек (например, из‑за политики компании), но можно дать уважение и ясность.

    Профессиональные ориентиры

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

  • ACM Code of Ethics and Professional Conduct
  • Результат работы IT‑рекрутера: что считать «хорошим наймом»

    В IT‑подборе недостаточно «закрыть вакансию». Хороший результат — это баланс:

  • компания наняла человека, который соответствует задачам и уровню
  • кандидат понял роль и условия и осознанно принял решение
  • процесс был достаточно быстрым и прозрачным
  • коммуникация не испортила репутацию бренда работодателя
  • Что дальше в курсе

    В следующих материалах мы будем последовательно разбирать:

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

    2. Понимание IT-ролей и стека: как читать вакансии и резюме

    Понимание IT-ролей и стека: как читать вакансии и резюме

    Зачем IT-рекрутеру разбираться в ролях и стеке

    В предыдущей статье мы разобрали базовый процесс найма: intake, поиск, outreach, скрининг, интервью, оффер и метрики. На практике качество каждого этапа зависит от того, насколько вы понимаете кого именно ищете и как описать роль на языке кандидата.

    Понимание IT-ролей и стека помогает рекрутеру:

  • корректно переводить запрос нанимающего менеджера в понятный профиль кандидата
  • отличать обязательные требования от желаемых
  • находить релевантных людей в сорсинге по правильным ключевым словам
  • быстро читать резюме и видеть соответствие задачам, а не только «список технологий»
  • задавать точные вопросы на скрининге и собирать вводные для техинтервью
  • Базовые понятия: роль, стек, домен, продукт

    Чтобы дальше говорить на одном языке, зафиксируем определения.

  • IT-роль — набор типичных задач и зон ответственности в команде (например, backend-разработчик, QA-инженер, DevOps-инженер).
  • Технологический стек (tech stack) — набор технологий, с которыми человек или команда работает при создании и поддержке продукта. Обычно включает язык программирования, фреймворки, базы данных, инфраструктуру, инструменты разработки.
  • Домен (domain) — предметная область продукта: финтех, e-commerce, логистика, медтех и т.д. Домен влияет на требования (например, безопасность, регуляторика, нагрузки).
  • Продукт — то, что создаёт команда (приложение, платформа, внутренний сервис). Важно отличать продуктовую разработку от проектной/аутсорсинга, потому что меняются процессы, горизонты планирования и ожидания к самостоятельности.
  • «Анатомия» технологического стека

    Один и тот же стек можно описать по слоям — это сильно упрощает чтение вакансий и резюме.

    !Слои стека помогают быстро понять, где именно работает специалист и какие технологии для него ключевые

    Язык и рантайм

    Это основа, вокруг которой строится большая часть требований.

    Примеры:

  • Java, C#, Python, JavaScript/TypeScript, Go, PHP, Ruby
  • Важно рекрутеру:

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

  • Документация Python
  • Документация TypeScript
  • Фреймворки и библиотеки

    Это инструменты для ускорения разработки в конкретной области.

    Примеры:

  • frontend: React, Angular, Vue
  • backend: Spring, ASP.NET, Django, FastAPI
  • Подсказка рекрутеру:

  • в резюме важнее связка язык + фреймворк + тип задач, чем длинный список библиотек
  • вакансии часто содержат «экосистему»: например, Node.js + TypeScript + NestJS + PostgreSQL
  • Справочные источники:

  • Документация React
  • Документация Django
  • Данные: базы, кеш, очереди

    Почти любой продукт хранит данные и обрабатывает события.

    Типовые элементы:

  • Реляционные базы данных: PostgreSQL, MySQL
  • NoSQL: MongoDB, Cassandra (когда важны масштабирование/гибкость модели)
  • Кеш: Redis (ускорение доступа)
  • Очереди/стриминг: RabbitMQ, Kafka (асинхронная обработка)
  • Как читать требования:

  • «опыт с PostgreSQL» часто значит умение писать запросы, понимать индексы и оптимизацию
  • «Kafka» часто означает событийную архитектуру и работу с потоками данных, а не просто «умел подключить библиотеку»
  • Инфраструктура и деплой

    Здесь чаще всего встречаются:

  • облака: AWS, GCP, Azure
  • контейнеризация: Docker
  • оркестрация: Kubernetes
  • Рекрутеру полезно помнить:

  • «Kubernetes» в резюме может означать очень разную глубину: от «деплоил по готовому Helm chart» до «строил платформу и работал с сетью/безопасностью»
  • Быстрый ориентир по терминам:

  • Документация Kubernetes
  • Инженерные практики: CI/CD, тестирование, наблюдаемость

    Даже если роль не DevOps, в вакансиях часто встречаются практики:

  • CI/CD — автоматизация сборки, тестов, доставки кода
  • тестирование — unit/integration/e2e, тест-дизайн
  • наблюдаемость (observability) — логи, метрики, трассировки; мониторинг и алерты
  • Почему это важно при чтении резюме:

  • senior-уровень часто проявляется не в «количестве технологий», а в ответственности за качество, стабильность и процесс поставки
  • Карта основных IT-ролей: кто что делает и как выглядит в вакансии

    Ниже — практичная карта ролей, которые чаще всего нанимают. Важно: названия могут отличаться, а обязанности пересекаться.

    !Обзорная карта помогает быстро соотнести вакансию с семейством ролей и ожидаемым стеком

    Разработка

    Frontend-разработчик

  • зона ответственности: интерфейс, взаимодействие с API, производительность UI, доступность
  • типичный стек: JavaScript/TypeScript, React/Vue/Angular, HTML/CSS, инструменты сборки
  • маркеры в вакансиях: SPA, SSR, performance, design systems
  • Backend-разработчик

  • зона ответственности: серверная логика, API, работа с данными, интеграции, производительность
  • типичный стек: Java/Spring, C#/.NET, Python/Django/FastAPI, Go; БД; очереди
  • маркеры в вакансиях: микросервисы, highload, транзакции, интеграции, очереди
  • Fullstack-разработчик

  • зона ответственности: и frontend, и backend (обычно с уклоном в одну сторону)
  • риск для рекрутера: в резюме «fullstack» иногда означает «делал всё понемногу», поэтому важно уточнять глубину по ключевым частям
  • Mobile-разработчик

  • iOS (Swift), Android (Kotlin/Java), кроссплатформа (Flutter, React Native)
  • маркеры: публикация в сторах, работа с SDK, оптимизация, push, аналитика
  • Качество (QA)

    QA Manual (тестировщик)

  • зона ответственности: тест-планы, тест-кейсы, проверка функциональности, баг-репорты
  • маркеры: виды тестирования (функциональное, регресс, smoke), инструменты (Jira), понимание клиент-сервер
  • QA Automation

  • зона ответственности: автоматизация тестов, поддержка тестовой инфраструктуры
  • типичный стек: язык (Java/Python/JS), фреймворки тестирования, CI, иногда Docker
  • Ключевой момент:

  • «автоматизация» — это не просто «писал тесты», а ещё и поддержка стабильности тестов, интеграция в пайплайн, работа с флаки (нестабильными) тестами
  • Инфраструктура

    DevOps-инженер

  • зона ответственности: доставка изменений, инфраструктура как код, CI/CD, окружения, базовая эксплуатация
  • типичный стек: Linux, Docker, Kubernetes, Terraform/Ansible, облака, CI
  • SRE (Site Reliability Engineer)

  • зона ответственности: надёжность сервиса через инженерные подходы, SLO/SLI, инциденты, устранение системных причин
  • пересечение с DevOps большое, но SRE чаще сильнее про измеримость надёжности и работу с инцидентами как с инженерной задачей
  • Если хотите быстро понять, что обычно вкладывают в SRE-подход, полезен открытый источник:

  • Site Reliability Engineering (книга Google)
  • Данные

    Data Analyst (аналитик данных)

  • зона ответственности: отчёты, метрики, продуктовая/бизнес-аналитика, гипотезы
  • типичный стек: SQL, BI-инструменты, базовая статистика, визуализация
  • маркеры: cohort, funnel, retention, A/B-тесты (в продуктовых командах)
  • Data Engineer (инженер данных)

  • зона ответственности: пайплайны данных, качество данных, хранилища, интеграции
  • типичный стек: SQL, Python/Scala/Java, ETL/ELT, Airflow, Spark, хранилища
  • Data Scientist / ML Engineer

  • зона ответственности: модели, эксперименты, внедрение ML в продукт
  • типичный стек: Python, библиотеки ML, MLOps, эксперименты, продакшенизация
  • Типичная ошибка при чтении резюме:

  • путать аналитика данных с data engineer: у первого чаще про смысл метрик и принятие решений, у второго — про надёжную поставку данных и инфраструктуру
  • Безопасность

    Роли в безопасности сильно различаются. Частые направления:

  • AppSec — безопасность приложений (уязвимости, процессы, SAST/DAST, threat modeling)
  • SecOps — мониторинг, реагирование, защита инфраструктуры
  • Как рекрутеру не ошибиться:

  • всегда уточняйте объект защиты: приложение, облако, сеть, endpoints, процессы разработки
  • Управление и дизайн (часто рядом с IT-наймом)

    Даже если вы в первую очередь нанимаете инженеров, в IT-командах часто участвуют:

  • Product Manager — отвечает за ценность продукта, приоритизацию, результаты
  • Project Manager — отвечает за сроки, риски, координацию исполнения
  • UX/UI Designer — проектирует опыт и интерфейс
  • Эти роли важны тем, что в вакансиях инженеров могут быть ожидания по взаимодействию с продуктом/дизайном (например, самостоятельная проработка решений, участие в discovery).

    Как читать IT-вакансию: пошаговый разбор

    Цель рекрутера — превратить описание в поисковый и оценочный профиль. Удобный алгоритм:

  • Выделите «обязательно» и «желательно»
  • Поймите тип задач и контекст
  • Определите «фильтры» (что отсекает кандидатов)
  • Соберите слова для сорсинга
  • Подготовьте вопросы для intake и скрининга
  • Что в вакансии чаще всего является «обязательным»

    Обычно это ограничения, без которых человек не сможет выполнять работу.

    Примеры обязательного:

  • конкретный язык/платформа (например, Kotlin для Android)
  • опыт с определённым типом архитектуры (например, микросервисы), если продукт так устроен
  • требования по локации/графику/дежурствам (on-call)
  • язык коммуникации (например, английский для международной команды)
  • Что часто является «желательным» и подлежит обсуждению

    Часто компании пишут широкий список «на вырост». Его задача — описать идеального кандидата, но не всегда это реальный фильтр.

    Примеры желательного:

  • «опыт с Kubernetes» для backend-разработчика (иногда достаточно понимания принципов)
  • «знание нескольких облаков» (часто достаточно одного)
  • «опыт во всех базах данных мира» (обычно важна одна ключевая + общий подход)
  • Практика:

  • на intake уточняйте: какие 3–5 требований критичны, а какие можно добрать в первые месяцы
  • «Скрытые» требования, которые не всегда написаны явно

    Часть критичных условий прячется в формулировках. Это стоит вытащить вопросами.

    Типичные скрытые требования:

  • нагрузка и надёжность: если написано highload, 24/7, SLA — уточняйте ожидания по инцидентам и дежурствам
  • зрелость процессов: стартап, «быстро растём» — часто означает неопределённость и необходимость самостоятельности
  • роль в жизненном цикле: ownership, end-to-end — значит, человек будет отвечать не только за код, но и за эксплуатацию/качество
  • интеграции: «много внешних сервисов» — значит, важно уметь работать с API, отказоустойчивостью, ретраями
  • Как превратить вакансию в ключевые слова для сорсинга

    Составьте 3 набора ключей:

  • роль и синонимы: backend engineer, software engineer, Java developer
  • ядро стека: Java + Spring + PostgreSQL (или эквиваленты)
  • контекст: microservices, distributed systems, highload, fintech, payments
  • Важно:

  • не перегружайте запрос редкими инструментами, если они не обязательны
  • используйте «якоря»: язык, основной фреймворк, тип домена/задач
  • Как читать резюме: что считать сигналами релевантности

    Резюме инженера удобно читать как ответ на три вопроса:

  • Что человек делал? (задачи)
  • В каком контексте? (масштаб, команда, продукт)
  • Какой вклад и уровень ответственности? (ownership, влияние, качество решений)
  • Сильные блоки резюме (и как их интерпретировать)

    Опыт по проектам

    Смотрите не только на названия компаний, а на содержание:

  • тип продукта (B2B/B2C, внутренняя платформа, финтех и т.д.)
  • ответственность (писал фичи, проектировал сервис, вел подсистему)
  • взаимодействие (с продуктом, дизайном, аналитиками, DevOps)
  • Стек

    Хороший знак — когда стек привязан к проектам и задачам.

    Менее информативно, когда:

  • перечислен список из 30 технологий без контекста
  • Достижения и результаты

    Лучше всего, когда есть измеримый эффект, но и качественные формулировки тоже полезны.

    Примеры «сильных» формулировок:

  • «снизил время ответа API за счёт оптимизации запросов и кеширования»
  • «внедрил CI, уменьшил количество ручных шагов релиза»
  • «выстроил мониторинг и алерты для критичных сервисов»
  • Как аккуратно оценивать уровень (junior/middle/senior) по резюме

    Годы опыта — слабый индикатор. Более надёжные сигналы:

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

  • если в резюме много «делал фичи по ТЗ» и мало ответственности за решения — чаще это junior/middle
  • если есть ownership подсистемы, архитектура, техническое лидерство — чаще middle/senior (зависит от масштаба)
  • Красные флаги: что требует уточнения, а не мгновенного отказа

    «Красный флаг» — это повод задать вопрос, а не сразу дисквалифицировать кандидата.

    Типичные ситуации:

  • частая смена работы без объяснения
  • очень широкий стек «всё подряд» без проектов
  • большие пробелы в опыте (важно уточнить причины)
  • резюме не содержит задач и ответственности (может быть просто плохо оформлено)
  • Этичная практика из предыдущей статьи применима и здесь: не додумывать, а уточнять.

    Быстрый глоссарий: термины, которые часто встречаются

    | Термин | Простое объяснение | Где встречается | |---|---|---| | API | способ взаимодействия программ (обычно через HTTP) | backend, frontend, интеграции | | Microservices | система из многих сервисов, взаимодействующих между собой | backend, DevOps/SRE | | CI/CD | автоматизация сборки, тестов и доставки | почти все инженерные роли | | On-call | дежурства для реакции на инциденты | DevOps/SRE, иногда backend | | SLA/SLO | договорённый/целевой уровень надёжности сервиса | SRE, эксплуатация | | ETL/ELT | процессы загрузки и преобразования данных | data engineer | | Observability | способность понимать состояние системы по логам/метрикам/трейсам | DevOps/SRE, backend |

    Вопросы для intake: чтобы не искать «не того человека»

    Ниже — вопросы, которые повышают точность профиля и экономят время на сорсинге и скрининге.

  • Какие задачи на первые 3 месяца?
  • Какие 3–5 требований критичны, без них нельзя?
  • Какие требования можно добрать после выхода?
  • Как устроен стек сейчас и что планируется менять?
  • Есть ли on-call, работа с инцидентами, требования 24/7?
  • Как выглядит идеальный кандидат с точки зрения ответственности?
  • Какие причины отказа встречались раньше?
  • Результат хорошего intake — не «идеальный список технологий», а ясный профиль:

  • роль и задачи
  • уровень ответственности
  • ядро стека
  • условия и ограничения
  • критерии успеха
  • Как связать это с сорсингом и скринингом

    Эта статья — мост между вводной темой про процесс и следующими практиками курса.

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

    3. Снятие заявки и работа с нанимающим менеджером: требования и профили

    Снятие заявки и работа с нанимающим менеджером: требования и профили

    Зачем рекрутеру сильный intake и партнёрство с нанимающим менеджером

    В предыдущих статьях мы разобрали:

  • общий процесс IT-подбора и роли участников
  • базовую карту IT-ролей и «анатомию» стека, чтобы читать вакансии и резюме по смыслу, а не по списку технологий
  • Теперь ключевой навык, который соединяет эти знания в работающую систему, — снятие заявки (intake) и правильная работа с нанимающим менеджером.

    Если intake сделан поверхностно, дальше ломается всё:

  • сорсинг идёт в неверный рынок (не те ключевые слова, не тот уровень, не те локации)
  • скрининг становится «угадайкой»
  • техкоманда получает нерелевантных кандидатов
  • офферы отклоняются из-за несостыкованных ожиданий
  • Цель рекрутера на этом этапе — превратить размытое «нужен сильный разработчик» в проверяемый профиль: что человек будет делать, в каком контексте, по каким критериям его оценят и на каких условиях он согласится.

    !Карта того, как intake превращается в профиль, критерии оценки и план поиска

    Роли и ответственность: кто за что отвечает

    Важно договориться о границах ответственности заранее.

    | Зона | Нанимающий менеджер | Рекрутер | |---|---|---| | Зачем открыта позиция и что болит | формулирует бизнес-потребность | помогает уточнить и превратить в критерии | | Задачи, приоритеты, контекст команды | задаёт факты и ожидания | структурирует, фиксирует, задаёт уточняющие вопросы | | Требования по навыкам и уровню | определяет минимальный порог и «планку» | помогает отделить must-have от nice-to-have и проверить рынок | | Интервью-этапы и критерии оценки | обеспечивает техническую оценку и решение | предлагает структуру процесса и scorecard, следит за консистентностью | | Коммуникация с кандидатами | участвует на нужных этапах | ведёт кандидата end-to-end, управляет ожиданиями | | Сроки, скорость, дисциплина процесса | держит доступность интервьюеров | координирует и подсвечивает узкие места |

    Ключевой принцип: решение о найме — у бизнеса, но качество процесса и точность профиля — совместная ответственность.

    Подготовка к intake: что собрать до встречи

    Intake-встреча проходит значительно лучше, если рекрутер приходит не «с пустыми руками». До встречи соберите вводные.

  • Действующее описание вакансии (если есть)
  • Что уже пробовали
  • Кто в команде и как устроены роли
  • Рынок и ограничения
  • Практичный чек-лист подготовки:

  • Прочитайте текущую вакансию и выделите спорные пункты (обычно это слишком длинный список технологий и размытые обязанности).
  • Посмотрите 3–5 похожих вакансий на рынке (для ориентира по формулировкам и обязательным требованиям).
  • Соберите вопросы по неизвестным терминам из вакансии.
  • Подготовьте короткий черновик профиля: роль, уровень, ядро стека, локация/формат, компенсация, ключевые задачи.
  • Структура intake-встречи: что обязательно обсудить

    Ниже — структура, которая подходит большинству IT-вакансий. Её можно проводить за 30–60 минут.

    Контекст: зачем нужен человек

    Задача рекрутера — понять, какая проблема решается наймом.

    Примеры хороших уточнений:

  • роль на замену или рост команды
  • что «горит» прямо сейчас
  • какой результат ожидается через 3–6 месяцев
  • Формулировка результата должна быть простой и прикладной. Например:

  • «Запустить новый платежный сервис в прод и обеспечить стабильность в пике»
  • «Ускорить цикл релизов, сократить ручные операции и повысить наблюдаемость»
  • Задачи и зона ответственности

    Разделяйте «технологии» и «работу».

  • Список задач на первые 4–12 недель
  • Ожидания по уровню самостоятельности
  • Какие решения человек принимает сам
  • С кем взаимодействует ежедневно
  • Полезная формула, чтобы избежать абстракций: задача + контекст + ответственность.

    Пример:

  • «Поддерживать и развивать API для мобильного приложения»
  • «В микросервисной архитектуре, высокие требования к отказоустойчивости»
  • «С ответственностью за качество релиза и участие в on-call»
  • Требования: как отделить must-have от nice-to-have

    У рекрутера должна получиться короткая, честная «суть», иначе сорсинг будет дорогим и медленным.

    #### Must-have (без этого нельзя)

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

    Примеры must-have:

  • конкретная платформа (например, Android на Kotlin)
  • обязательная локация или график
  • опыт с критичным типом задач (например, платежи и транзакции, если это ядро продукта)
  • английский на уровне, достаточном для ежедневной коммуникации
  • #### Nice-to-have (сильно желательно, но обсуждаемо)

    Это «усилители», которые повышают ценность кандидата, но не должны убивать воронку.

    Примеры nice-to-have:

  • второй облачный провайдер
  • редкий инструмент мониторинга при наличии общего опыта observability
  • знание конкретного фреймворка при релевантном языке и близкой экосистеме
  • Практика для фиксации требований:

    | Блок | Must-have | Nice-to-have | Вопрос для уточнения | |---|---|---|---| | Язык/платформа | Java | Kotlin | Готовы ли рассмотреть кандидатов без коммерческого Kotlin, но с JVM-экосистемой? | | Архитектура | микросервисы | event-driven | Какая часть системы микросервисы, а какая монолит? | | Инфраструктура | Docker | Kubernetes | Нужно ли уметь администрировать K8s или достаточно уметь деплоить? | | Процессы | code review | TDD | Какой процесс релизов и какая зрелость тестов? |

    Уровень и критерии: junior/middle/senior без гаданий

    Чтобы не спорить «на ощущениях», привязывайте уровень к ответственности.

  • Junior
  • Middle
  • Senior
  • Ориентиры, которые можно использовать в разговоре:

  • Junior: выполняет задачи с поддержкой, учится в процессе, ответственность ограничена.
  • Middle: самостоятельно ведёт задачи и компоненты, понимает последствия решений, стабильно поставляет результат.
  • Senior: отвечает за области, влияет на архитектуру и качество, помогает другим, думает системно.
  • Важно согласовать с менеджером два вопроса:

  • какой уровень нужен по задачам ближайших месяцев
  • какие «сигналы senior» обязательны, а какие желательны
  • Ограничения и условия: то, что ломает найм, если скрыть

    Эти пункты должны быть известны рекрутеру до старта поиска.

  • формат работы (удалёнка/гибрид/офис), локация
  • график и нагрузка
  • наличие on-call и частота дежурств
  • тип занятости (штат/контракт), оформление
  • вилки компенсации и что в неё входит
  • Если менеджер не готов назвать диапазон, рекрутеру сложно корректно управлять ожиданиями кандидата и скоростью воронки.

    Интервью-процесс и SLA по скорости

    Скорость критична в IT-найме. На intake нужно договориться:

  • Какие этапы интервью
  • Кто интервьюеры
  • Сколько времени на обратную связь после каждого этапа
  • Кто финально принимает решение
  • Формулируйте это как внутреннее «SLA процесса» (сроки реакции), даже если вы не используете слово SLA.

    Артефакты intake: что должно остаться после встречи

    После intake у рекрутера должны быть оформлены артефакты, которые можно переиспользовать в работе.

    Профиль кандидата (Candidate Profile)

    Это документ на 1–2 страницы, который заменяет «разрозненные сообщения в чате».

    Рекомендуемая структура профиля:

  • Название роли и уровень
  • Коротко о продукте и команде
  • 3–6 ключевых задач
  • Must-have требования (3–7 пунктов)
  • Nice-to-have требования (3–7 пунктов)
  • Ограничения (локация, формат, on-call)
  • Диапазон компенсации и условия
  • Признаки успеха на 3–6 месяцев
  • Пример фрагмента профиля (сжатый формат):

  • Роль: Backend Engineer (Middle/Senior)
  • Задачи: развитие API, интеграции с внешними провайдерами, оптимизация запросов, участие в on-call
  • Must-have: Java, Spring, PostgreSQL, микросервисы, опыт с транзакционными системами
  • Nice-to-have: Kafka, Kubernetes, опыт финтех/платежи
  • Условия: гибрид, 1–2 дня офис; on-call 1 неделя в 6 недель
  • Scorecard: единые критерии оценки

    Scorecard — это список критериев, по которым интервьюеры оценивают кандидата одинаково. Это снижает субъективность и помогает давать сравнимую обратную связь.

    Подход, который хорошо работает: 5–7 критериев, каждый с описанием «что считаем хорошим».

    | Критерий | Что проверяем | Пример сигналов | |---|---|---| | Опыт по ядру стека | реальная работа с ключевыми технологиями | не просто «знаю Spring», а проектный опыт и решения | | Архитектурное мышление | понимание компромиссов | может объяснить, почему выбрал подход | | Работа с данными | запросы, индексы, транзакции | понимает причины деградаций и как искать | | Качество и поставка | тесты, релизы, CI/CD | участвовал в улучшениях процесса | | Надёжность | инциденты, on-call, мониторинг | понимает влияние изменений на прод | | Коммуникация | ясность, совместная работа | задаёт вопросы, структурирует мысли |

    Если компания стремится к структурированным интервью, полезно ориентироваться на подходы к единым критериям и сопоставимым вопросам.

  • Google re:Work: Use structured interviewing
  • План сорсинга: якоря, синонимы, исключения

    На основе профиля рекрутер делает основу для сорсинга.

  • Якоря
  • Синонимы названий
  • Контекстные ключи
  • Минус-слова
  • Пример:

  • Якоря: Java, Spring, PostgreSQL, microservices
  • Синонимы: Backend Engineer, Software Engineer, Java Developer
  • Контекст: payments, highload, distributed systems, Kafka
  • Минус-слова (осторожно): например, исключить intern, если ищем middle+
  • Важно: минус-слова используйте аккуратно, чтобы не вырезать сильных кандидатов с нетипичными названиями.

    Калибровка: как согласовать «что такое хороший кандидат»

    Даже после intake часто остаётся риск разных ожиданий у участников. Поэтому полезна калибровка — короткое согласование примеров.

    Рабочие форматы калибровки:

  • Разобрать 2–3 реальных профиля (анонимно) и спросить менеджера: «берём на интервью или нет, почему».
  • Согласовать «анти-профиль»: кто точно не подходит.
  • Согласовать «компромиссы»: на что готовы закрыть глаза ради скорости или сильных сторон.
  • Результат калибровки — меньше итераций и меньше эмоциональных отказов «не то» без причины.

    Типичные ошибки в работе с нанимающим менеджером и как их предотвратить

    | Ошибка | Как проявляется | Что делает рекрутер | |---|---|---| | Слишком широкий профиль | ищем «единорога», воронка нулевая | добивается списка из 3–5 must-have | | Непроверенные ожидания по зарплате | офферы не принимают | фиксирует диапазон и объясняет рыночные риски | | Нет ясности по on-call | кандидат уходит на финале | поднимает тему в начале и формулирует условия честно | | «Хочу как тот сильный из прошлой команды» | копирование вместо критериев | переводит пример в конкретные навыки и ответственность | | Несогласованный процесс | интервью растягиваются | договаривается о сроках фидбека и доступности |

    Коммуникация и фиксация договорённостей: чтобы не «утонуть в чатах»

    Профессиональная работа рекрутера — это не только разговор, но и управление информацией.

    Рекомендации:

  • После intake отправляйте менеджеру короткое резюме: профиль, must-have, ограничения, этапы, сроки.
  • Храните версию профиля в одном месте (ATS, документ, база знаний команды), а не в переписке.
  • Любое изменение требований фиксируйте как изменение профиля, а не «на словах».
  • Полезный формат письма-резюме после intake:

  • Роль и уровень
  • Задачи на 3 месяца
  • Must-have (5 пунктов)
  • Nice-to-have (5 пунктов)
  • Условия и диапазон
  • Процесс интервью и ответственные
  • Следующий шаг: когда первые кандидаты и когда следующий синк
  • Как это связано с дальнейшими темами курса

    Эта статья — практическая база для следующих навыков:

  • для сорсинга: вы получаете правильные якоря, синонимы и ограничения, без которых boolean-запросы будут неточными
  • для скрининга: вы знаете, какие требования критичны и какие вопросы помогут подтвердить релевантность
  • для аналитики воронки: вы заранее согласуете скорость и критерии, а значит сможете измерять, где именно «течёт процесс»
  • Сильный intake делает рекрутера партнёром бизнеса: вы не просто «ищете резюме», а управляете наймом как предсказуемым процессом.

    4. Сорсинг: каналы, boolean/x-ray, GitHub, LinkedIn и сообщества

    Сорсинг: каналы, boolean/x-ray, GitHub, LinkedIn и сообщества

    Что такое сорсинг и почему он начинается с intake

    В прошлых статьях курса мы:

  • разобрали базовый процесс IT-подбора и метрики воронки
  • научились читать вакансии и резюме через роли, стек и контекст
  • разобрали intake и артефакты: Candidate Profile, scorecard, план сорсинга
  • Сорсинг — это системный поиск и первичное привлечение кандидатов, чаще всего через исходящие касания (outbound). В IT это критично, потому что сильные специалисты часто:

  • не ищут работу активно
  • не откликаются на вакансии
  • выбирают из нескольких предложений
  • Сорсинг работает хорошо, когда вы опираетесь на результаты intake:

  • Понятная роль и уровень (что именно человек будет делать и с какой ответственностью)
  • Ядро стека и контекст задач (что обязательно, а что можно добрать)
  • Ограничения (локация, формат работы, on-call, язык коммуникации)
  • Вилка и условия (чтобы не «сжечь» кандидата позже несостыковкой)
  • !Схема показывает, как intake превращается в стратегию поиска и управляемую воронку

    Каналы сорсинга: где искать кандидатов

    Каналы удобно делить на inbound и outbound.

  • Inbound — входящие отклики (карьерный сайт, площадки, рекомендации)
  • Outbound — вы сами находите людей и пишете им (LinkedIn, GitHub, сообщества, X-Ray)
  • Ниже — практичная карта каналов с плюсами, ограничениями и типичными сценариями.

    | Канал | Когда особенно полезен | Сильные стороны | Ограничения и риски | |---|---|---|---| | LinkedIn | большинство инженерных ролей, международный найм | много профилей, фильтры, история опыта | часть сильных кандидатов неактивна; ограничения поиска; важно соблюдать правила платформы | | GitHub | разработчики, иногда DevOps/SRE, open-source ориентированные команды | видны артефакты работы: репозитории, активность, интересы | не все ведут GitHub; активность не всегда = коммерческий опыт | | Профессиональные сообщества (Slack/Discord/Telegram, форумы) | нишевые роли, быстрый доступ к аудитории | доверие внутри комьюнити, быстрые рекомендации | важно не спамить; нужна репутация и ценность | | Митапы и конференции | senior/lead, редкие специализации | высокий сигнал качества, живые контакты | дороже по времени; не всегда масштабируется | | Job boards | массовые роли, junior, локальные рынки | быстрые отклики, понятный поток | качество может быть неоднородным; конкуренция | | Реферальная программа | любые роли, особенно сложные | высокая конверсия, быстрый цикл | зависит от культуры компании и мотивации |

    Важно: хороший сорсер не «верит в один канал». Он строит микс: 1–2 основных канала + 1–2 дополнительных для усиления.

    Подготовка к поиску: ключи, синонимы, исключения

    Сорсинг ломается чаще всего не на инструментах, а на том, что рекрутер ищет не теми словами и не в том рынке. Перед тем как писать boolean-запросы и открывать LinkedIn, сделайте поисковую карту.

    Якоря

    Якоря — признаки, без которых кандидат не подходит. Обычно это:

  • роль или семейство ролей (например, backend engineer)
  • основной язык/платформа (например, Java)
  • ключевой фреймворк или экосистема (например, Spring)
  • обязательный контекст (например, payments, highload) только если это реально must-have
  • Синонимы

    Названия ролей и формулировки отличаются. Поэтому вы собираете список:

  • синонимов названий должностей
  • вариантов написания технологий
  • альтернативных терминов
  • Примеры:

  • backend engineer, software engineer, java developer, server-side developer
  • PostgreSQL, Postgres
  • microservices, distributed systems
  • Минус-слова (исключения)

    Минус-слова помогают убрать нерелевантные профили, но ими легко «отрезать» сильных людей.

    Используйте исключения аккуратно:

  • сначала соберите 20–30 профилей и посмотрите, что «мешает»
  • исключайте только то, что стабильно даёт мусор
  • Примеры:

  • если ищете middle+, иногда уместно исключить intern (но проверьте, нет ли релевантных профилей с таким словом в старом опыте)
  • если ищете backend, иногда исключают recruiter, hr, чтобы не ловить людей с упоминаниями в описании
  • Boolean-поиск: логика, которую важно понимать

    Boolean — это способ собирать поисковый запрос из логических операторов.

    Базовые элементы:

  • AND — должны встречаться оба условия
  • OR — достаточно любого из условий
  • NOT или - — исключить условие
  • кавычки для точной фразы (в разных системах работают по-разному)
  • скобки () для группировки
  • Ключевой принцип: boolean помогает не «найти идеального кандидата», а управлять шумом и приближаться к релевантности итерациями.

    Шаблоны boolean-запросов

    Ниже примеры запросов как логики. Конкретный синтаксис зависит от системы поиска.

  • Базовый запрос на роль и язык:
  • ("backend" OR "software engineer" OR "java developer") AND (Java OR JVM)

  • Добавляем экосистему и данные:
  • ("java developer" OR "backend engineer") AND (Spring OR "Spring Boot") AND (PostgreSQL OR Postgres)

  • Исключаем нерелевантный пласт:
  • ("java developer" OR "backend engineer") AND Spring AND (PostgreSQL OR Postgres) NOT ("android" OR Kotlin)

    Практическое правило:

  • сначала собирайте широкий список на 1–2 якорях
  • затем добавляйте уточнения
  • исключения добавляйте последними
  • !Визуализация помогает запомнить, как собирать запрос от общего к частному

    X-Ray поиск: как искать по сайтам через поисковик

    X-Ray — это поиск по конкретному сайту через Google (или другой поисковик) с помощью операторов, чаще всего site:.

    X-Ray полезен, когда:

  • встроенный поиск площадки ограничен
  • вы хотите искать по публичным страницам без входа в аккаунт
  • вы ищете профили на сайтах, где нет удобного поиска (часть форумов, страницы компаний, портфолио)
  • Базовый оператор:

  • site:example.com — искать только по этому сайту
  • Официальная справка Google по операторам:

  • Google: Refine web searches
  • Шаблоны X-Ray

  • Поиск профилей на GitHub:
  • site:github.com ("Berlin" OR "Germany") (Java OR Kotlin) (Spring OR "Spring Boot")

  • Поиск резюме на сайтах с публичными страницами:
  • site:example.com ("DevOps" OR SRE) (Kubernetes OR K8s) (Terraform OR IaC)

  • Поиск по портфолио/персональным сайтам:
  • ("backend engineer" OR "java developer") (CV OR resume) ("Spring Boot")

    Важное ограничение: X-Ray работает только по страницам, которые поисковик индексирует. Если сайт закрывает страницы от индексации, результаты будут неполными.

    Этическая и юридическая рамка

    X-Ray и сорсинг в целом требуют дисциплины:

  • не собирайте и не храните больше персональных данных, чем нужно для найма
  • используйте данные для профессиональной цели и с уважением
  • соблюдайте правила платформ и локальное законодательство о персональных данных
  • LinkedIn сорсинг: как искать и как не «сжигать» базу

    LinkedIn часто становится основным каналом для IT-сорсинга, потому что там есть:

  • структура опыта
  • названия ролей и компаний
  • навыки и ключевые слова
  • локации и иногда язык
  • Как искать эффективнее

  • Начинайте с 2–3 якорей и расширяйте через синонимы.
  • Смотрите не только текущий тайтл, но и:
  • - раздел About - описания проектов - предыдущие роли

  • Используйте фильтры осознанно:
  • - локация и формат (если это реальный фильтр) - индустрия и компании (если важно) - уровень (косвенно через опыт и scope, а не только годы)

  • Делайте заметки, почему человек попал в список (помогает при handoff менеджеру и при повторном касании).
  • Как читать профиль на LinkedIn как рекрутер

    Оценивайте профиль по логике из статьи про чтение резюме:

  • что делал человек (задачи)
  • в каком контексте (масштаб, продукт, домен)
  • какая ответственность (ownership, влияние, качество)
  • Красные флаги в LinkedIn — это повод уточнить, а не отказать:

  • очень общий профиль без задач
  • несостыковки дат
  • «всё подряд» без фокуса
  • GitHub сорсинг: когда он даёт преимущество

    GitHub — платформа для хранения и совместной разработки кода. Для сорсинга GitHub полезен тем, что даёт дополнительные сигналы, которых нет в резюме.

    Официальная документация по поиску на GitHub:

  • GitHub Docs: Searching on GitHub
  • Какие сигналы на GitHub реально полезны рекрутеру

    Не пытайтесь «оценивать качество кода» как инженер, если вы не технический специалист. Смотрите на то, что можно интерпретировать корректно.

    Полезные сигналы:

  • активность (есть ли недавние коммиты или участие в проектах)
  • тематика репозиториев (какие технологии, какие типы задач)
  • роль в проектах (создатель, контрибьютор, участник команды)
  • README и документация (умение оформлять и объяснять)
  • следы командной работы (pull requests, reviews, issues) если они публичны
  • Осторожно интерпретируйте:

  • отсутствие активного GitHub не означает слабого специалиста
  • многие коммерческие проекты закрыты и не видны
  • популярность репозиториев не равна профессиональному уровню
  • Как искать на GitHub

    Подхода обычно два:

  • искать людей через GitHub-поиск и ключевые слова
  • искать через X-Ray по публичным профилям и репозиториям
  • Если вы используете GitHub-поиск, полезно знать, что там есть своя логика запросов и фильтров (в документации выше). Практическая стратегия рекрутера:

  • Начните с языка или ключевой технологии (например, Java)
  • Добавьте контекст (например, Spring, microservices)
  • Проверьте профиль: описание, pinned репозитории, активность
  • Сопоставьте с вашим Candidate Profile (must-have и ограничения)
  • Как писать кандидатам, найденным на GitHub

    Почти всегда лучше писать не «внутри GitHub», а в предпочитаемый канал контакта кандидата, если он указан:

  • email в профиле
  • личный сайт
  • LinkedIn
  • Сообщение должно объяснять, почему вы пишете именно этому человеку: на GitHub это особенно важно, потому что люди быстро распознают массовую рассылку.

    Сообщества: как искать через доверие, а не через спам

    Под сообществами здесь понимаем профессиональные пространства, где люди общаются по технологиям и практике:

  • чаты и каналы (Slack/Discord/Telegram)
  • тематические форумы
  • локальные митапы
  • open-source сообщества вокруг проектов
  • Сорсинг через сообщества требует другой тактики: вы приходите не только «брать», но и давать.

    Рабочие форматы:

  • Короткий пост с понятной ролью и условиями
  • Запрос рекомендаций с точным профилем (must-have, локация, диапазон)
  • Вовлечение в тему (например, ответ на вопрос, полезная подборка ресурсов)
  • Плохая практика:

  • массовые одинаковые сообщения в личку участникам
  • скрытие ключевых условий (формат, on-call, вилка)
  • Качество сорсинга: воронка и итерации

    Чтобы сорсинг был управляемым, фиксируйте простые показатели по каждой вакансии и каналу:

  • сколько профилей найдено
  • сколько сообщений отправлено
  • сколько ответов получено
  • сколько позитивных ответов (готовность обсуждать)
  • сколько созвонов назначено
  • Если показатели низкие, причины обычно лежат в одной из зон:

  • Профиль слишком узкий или противоречивый (возвращаемся к intake)
  • Неправильные якоря и ключевые слова (пересобираем запрос)
  • Канал не подходит роли или рынку (меняем микс каналов)
  • Слабый outreach (переписываем сообщение и персонализацию)
  • Неконкурентные условия (эскалируем менеджеру и HR)
  • Практический вывод

    Сорсинг — это не «магия поиска», а дисциплина:

  • начинать с качественного intake и понятного профиля
  • выбирать каналы под роль и рынок
  • строить запросы от общего к частному (boolean)
  • использовать X-Ray для расширения охвата
  • читать LinkedIn и GitHub как источники сигналов о релевантности
  • работать с сообществами через уважение и ценность
  • измерять воронку и улучшать процесс итерациями
  • Следующий логичный шаг после сорсинга — научиться делать сильный outreach и скрининг так, чтобы найденные кандидаты превращались в интервью и офферы, а не «пропадали в переписке».

    5. Коммуникации с кандидатами: outreach, мотивация, воронка и CRM

    Коммуникации с кандидатами: outreach, мотивация, воронка и CRM

    Почему коммуникации — это продолжение intake и сорсинга

    В предыдущих модулях курса мы разобрали:

  • как устроен IT-рекрутмент и его метрики
  • как понимать роли и стек, читать вакансии и резюме
  • как снимать заявку (intake) и фиксировать профиль кандидата
  • как делать сорсинг: каналы, boolean, X-Ray, LinkedIn, GitHub, сообщества
  • Коммуникация с кандидатом — это мост между найденным профилем и движением по процессу. Даже сильный сорсинг не даст результата, если:

  • первое сообщение выглядит как массовая рассылка
  • вы не понимаете мотивацию и ограничения кандидата
  • вы не управляете воронкой касаний и теряете людей в переписке
  • у вас нет системы учёта (CRM/ATS/таблица), и вы не можете повторять успешные действия
  • В IT коммуникации особенно важны, потому что кандидат часто:

  • не в активном поиске
  • сравнивает несколько возможностей
  • ценит конкретику, скорость и уважение к времени
  • !Коммуникации как связующее звено между сорсингом и интервью

    Термины, которые используем в этой теме

    Чтобы дальше не было разночтений:

  • Outreach — первое исходящее сообщение кандидату (обычно холодное), цель которого получить ответ и согласие на следующий шаг.
  • Follow-up — повторное касание, если кандидат не ответил.
  • Кандидатская воронка коммуникаций — путь от найденного профиля до согласованного созвона и передачи на интервью.
  • CRM (в рекрутменте) — система учёта контактов и истории коммуникаций с кандидатами, включая тех, кто не в процессе прямо сейчас.
  • ATS (Applicant Tracking System) — система учёта кандидатов, которые уже попали в процесс по конкретной вакансии.
  • На практике один инструмент может совмещать и CRM, и ATS функции. Важно не название, а то, чтобы у вас была дисциплина учёта и понятные статусы.

    Цели outreach: что считается успехом

    Ошибка новичков — считать успехом факт отправки сообщения. Для рекрутера успех в outreach — это управляемый переход по шагам.

    Обычно цель строится так:

  • получить ответ
  • добиться содержательного ответа
  • превратить интерес в короткий созвон или переписку по условиям
  • собрать вводные для скрининга и следующего этапа
  • В некоторых ситуациях целью может быть не созвон, а:

  • уточнить открытость к предложениям и ожидания
  • попросить рекомендацию (referral)
  • договориться вернуться через 2–3 месяца
  • Структура сильного outreach-сообщения

    Хорошее первое сообщение одновременно:

  • уважает внимание кандидата
  • показывает релевантность
  • даёт достаточно контекста
  • предлагает простой следующий шаг
  • Практичная структура:

  • Короткое приветствие и персонализация: почему вы пишете именно этому человеку.
  • Контекст: компания или продукт (настолько прозрачно, насколько позволяет политика), команда, формат.
  • Суть роли: 1–2 ключевые задачи, ядро стека на высоком уровне.
  • Ценность для кандидата: что может быть интересно (задачи, масштаб, ответственность, влияние, условия).
  • Приземлённый CTA (call to action): простой вопрос или предложение короткого созвона.
  • Персонализация: что реально работает

    Персонализация — это не обращение по имени. Это причина, по которой вы выбрали кандидата.

    Примеры хороших оснований:

  • опыт с конкретным стеком и типом задач (например, микросервисы и транзакции)
  • релевантный домен (например, платежи, логистика, медтех)
  • вклад в open-source или публичные выступления
  • похожий контекст масштаба (например, highload, 24/7, on-call)
  • Плохая персонализация:

  • общие фразы, которые подходят любому (например, «у вас впечатляющий опыт»)
  • Длина, тон и формат

    Практическое правило: первое сообщение должно читаться за 15–25 секунд.

  • тон: профессионально-дружелюбный, без давления
  • формат: 4–7 коротких строк, лучше с пустыми строками между смысловыми блоками
  • без больших вложений и требований «пришлите резюме», если профиль уже виден
  • Шаблоны outreach под разные ситуации

    Шаблоны полезны как старт, но их нужно адаптировать под роль и контекст из intake.

    Шаблон для LinkedIn (универсальный)

  • Привет, Имя! Увидел(а) ваш опыт с якорь 1 и якорь 2 в контекст проекта/домена.
  • Мы в компания/продукт ищем роль/уровень в команду, которая делает 1 ключевая задача.
  • Стек в целом: язык/платформа, ключевой компонент, данные/инфра (если важно).
  • Если вы открыты к предложениям, можно 15 минут созвониться на этой неделе? Или удобнее пару вопросов в чате.
  • Шаблон, когда нельзя раскрывать компанию

  • Привет, Имя! Пишу, потому что у вас в профиле есть опыт якорь и проекты в контекст.
  • Есть роль роль/уровень в продуктовой команде (не аутсорс), задачи: 1–2 задачи.
  • Условия: формат, локация (если фильтр), диапазон обсуждаем.
  • Если вам актуально, могу раскрыть больше деталей в личном созвоне на 10–15 минут.
  • Шаблон “вопрос вместо предложения” для пассивных кандидатов

    Этот формат часто снижает давление и повышает ответы.

  • Привет, Имя! Увидел(а), что вы работали с технология/контекст.
  • Подскажите, вам в принципе интересны роли, где есть задача/ответственность (например, ownership сервиса, архитектурные решения)?
  • Если да, расскажу про одну позицию и условия — можно в чате.
  • Follow-up стратегия: как напоминать без спама

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

    Рекомендуемая последовательность касаний

    Ниже пример, который часто работает в IT (его нужно адаптировать под рынок и канал).

    | День | Канал | Суть касания | Что важно | |---|---|---|---| | 0 | LinkedIn/Email | первое сообщение | релевантность и простота следующего шага | | 2–3 | тот же | короткий follow-up | добавить уточнение ценности или вопрос | | 6–8 | альтернативный (если уместно) | финальное касание | вежливо закрыть петлю, дать возможность вернуться позже |

    Как писать follow-up

    Хороший follow-up:

  • очень короткий
  • содержит один новый смысл (уточнение, вопрос, новая деталь)
  • позволяет кандидату легко отказаться
  • Пример:

  • Привет, Имя! Аккуратно напомню про сообщение выше. Важно: в роли много X (например, ownership сервиса и влияние на архитектуру). Если неактуально — ок, просто скажите, и я не буду отвлекать.
  • Мотивация кандидата: как понять, что реально важно

    В IT «мотивация» редко сводится только к зарплате. Обычно это набор факторов, и ваша задача на коммуникациях и скрининге:

  • понять приоритеты
  • выявить стоп-факторы
  • сопоставить ожидания с реальностью роли
  • Модель факторов мотивации, удобная рекрутеру

    Чтобы не уходить в психологию, используйте прикладную рамку из четырёх блоков:

  • Задачи: что человек будет делать ежедневно
  • Среда: команда, процессы, стиль менеджмента, степень самостоятельности
  • Условия: формат, локация, график, on-call, компенсация
  • Рост: развитие, влияние, технологии, масштаб, обучение
  • Вопросы, которые раскрывают мотивацию без давления

    Эти вопросы уместны и в переписке, и на скрининге.

  • Что вам важно в следующей роли: задачи, команда, технологии, влияние, условия?
  • Что вы точно не рассматриваете? Например, офис 5/2, частый on-call, отсутствие английского, аутсорс.
  • Какие задачи дают энергию, а какие вы бы хотели делать меньше?
  • Насколько для вас критичны диапазон и структура компенсации (оклад/бонус/опционы)?
  • Если вы рассматривали предложения недавно, что было решающим фактором?
  • Важно: цель этих вопросов не «продать вакансию», а избежать ситуации, когда кандидат проходит 3 этапа и отваливается на условиях.

    Управление ожиданиями: что нужно проговаривать рано

    Один из главных источников потерь воронки — несостыковка ожиданий, о которой молчали до финала.

    Критичные темы, которые лучше поднимать раньше:

  • формат работы и локация
  • вилка и структура компенсации (хотя бы ориентир)
  • on-call, ночные окна, дежурства, инциденты
  • английский и частота коммуникаций на нём
  • реальный стек и технический долг, если они существенны
  • количество этапов, сроки и кто принимает решение
  • Это продолжение этики из вводного модуля: честность экономит время всем и защищает доверие.

    Воронка коммуникаций: как измерять эффективность outreach

    Чтобы улучшать коммуникации, нужно видеть цифры по шагам. Минимальная воронка для outbound обычно такая:

  • найдено профилей
  • отправлено сообщений
  • получено ответов
  • получено позитивных ответов
  • назначено созвонов
  • кандидат дошёл до скрининга
  • Ключевые метрики и как их понимать

  • Response rate — доля ответов на сообщения.
  • Формула:

    Где:

  • — количество полученных ответов (любых)
  • — количество отправленных первых сообщений
  • Positive reply rate — доля позитивных ответов среди отправленных.
  • Где:

  • — ответы вида «да, интересно», «давайте созвон», «пришлите детали»
  • — количество отправленных первых сообщений
  • Практическая интерпретация:

  • низкий response rate часто означает проблемы со списком (не те люди) или текстом (нечитаемо, без релевантности)
  • низкий positive reply rate при нормальном количестве ответов часто означает неконкурентные условия, не тот уровень роли или слабую ценность предложения
  • !Воронка коммуникаций и точки, где теряются кандидаты

    Итерации: как улучшать воронку по шагам

    Рабочий алгоритм улучшений:

  • Если мало ответов:
  • 1. проверьте релевантность списка (якоря из intake) 2. упростите сообщение и усилите персонализацию 3. протестируйте другой канал или время отправки
  • Если ответов много, но мало позитивных:
  • 1. проверьте соответствие уровня (junior/middle/senior) и ожиданий по ответственности 2. проговорите ключевые условия честнее и раньше 3. уточните, что именно кандидатам не подходит, и вернитесь к менеджеру с данными
  • Если позитив есть, но до созвона не доходят:
  • 1. предложите 2–3 слота времени вместо вопроса «когда удобно?» 2. сократите шаг между «интересно» и «давайте поговорим» 3. проверьте скорость вашей реакции

    CRM дисциплина: как не терять кандидатов и не выгорать

    Коммуникации становятся профессиональными, когда они системны. Без учёта и статусов вы будете:

  • писать одному и тому же человеку дважды
  • забывать про follow-up
  • терять контекст мотивации
  • не понимать, что работает
  • Что должно быть в карточке кандидата

    Минимальный набор полей, который реально помогает:

  • источник (LinkedIn, GitHub, рекомендация, сообщество)
  • роль и уровень, под которые кандидат потенциально подходит
  • ключевые якоря (например, Java, Spring, Payments)
  • локация и формат (если критично)
  • статус коммуникации
  • дата последнего касания и дата следующего касания
  • заметки по мотивации и стоп-факторам
  • согласие или запрет на контакты, если вы это фиксируете
  • Статусы коммуникаций: простой, но рабочий набор

    Важно, чтобы статусы были одинаковыми у всей команды.

    Пример статусов для outbound:

  • найден
  • сообщение отправлено
  • follow-up запланирован
  • ответ получен
  • заинтересован
  • неактуально сейчас
  • отказ
  • не отвечал, закрыто
  • Отдельно полезно иметь признак “можно вернуться позже” и дату, когда вернуться.

    Напоминания и “следующий шаг”

    Ключевая привычка рекрутера: у каждой карточки должен быть следующий шаг.

    Если вы закончили переписку и не поставили следующий шаг, кандидат скорее всего потеряется.

    Примеры корректных следующих шагов:

  • “Отправить follow-up в четверг”
  • “Запросить слоты у кандидата после уточнения вилки”
  • “Вернуться через 2 месяца, когда закончится проект”
  • Как коммуницировать с отказами и паузами профессионально

    Отказы — часть воронки. Кандидатский опыт (candidate experience) влияет на бренд работодателя и на будущий найм.

    Принципы отказа

  • быстро
  • нейтрально
  • по возможности с причиной на уровне критериев роли
  • с сохранением двери открытой, если это уместно
  • Пример короткого отказа после первичного диалога:

  • Спасибо за диалог. По текущей позиции нам важно X (например, коммерческий опыт с Kotlin под Android), а у вас он пока не основной. Если будет актуально, я с радостью вернусь к вам по ролям ближе к Y.
  • Пауза со стороны компании

    Если процесс замедлился, лучшее, что может сделать рекрутер — честно сообщить:

  • что происходит
  • когда будет обновление
  • что вы сделаете дальше
  • Так вы снижаете риск, что кандидат “додумает” негативную причину и уйдёт.

    Этические и юридические аспекты коммуникаций

    Коммуникации — это работа с персональными данными и репутацией.

    Базовые правила:

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

  • Общий регламент ЕС по защите данных (GDPR), официальный текст
  • Практический итог

    Коммуникации с кандидатами — это управляемая система, которая опирается на предыдущие этапы курса:

  • intake даёт точный профиль и ограничения
  • сорсинг даёт список релевантных людей
  • outreach и follow-up превращают список в разговоры
  • вопросы про мотивацию помогают не терять кандидатов на финале
  • воронка и метрики показывают, что улучшать
  • CRM дисциплина защищает от хаоса и делает результат повторяемым
  • Следующая логичная ступень после этого модуля — углубиться в проведение скрининга и сопровождение кандидата по этапам так, чтобы скорость, качество и опыт кандидата были стабильно высокими.

    6. Интервью и оценка: прескрининг, компетенции, техэтапы и обратная связь

    Интервью и оценка: прескрининг, компетенции, техэтапы и обратная связь

    Как этот модуль связан с предыдущими

    В предыдущих темах курса вы выстроили основу управляемого найма:

  • разобрали процесс IT-подбора, роли и метрики
  • научились читать роли и стек, отделять must-have от nice-to-have
  • освоили intake и артефакты: Candidate Profile, scorecard, план сорсинга
  • научились сорсить и выстраивать коммуникации: outreach, follow-up, воронка, CRM
  • Следующий слой профессионализма — как проводить кандидата через интервью-этапы так, чтобы решения были предсказуемыми, справедливыми и быстрыми.

    Здесь рекрутер — не просто координатор. Он:

  • защищает качество оценки через структуру и критерии
  • повышает конверсию кандидатов через прозрачность и сопровождение
  • снижает риск ошибок найма через калибровку и доказательность
  • управляет впечатлением кандидата через корректную обратную связь
  • !Схема интервью-воронки с целями этапов и ответственными

    Термины: прескрининг, скрининг, интервью и оценка

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

  • Прескрининг — короткая проверка базовых условий и интереса кандидата до полноценного интервью.
  • Скрининг рекрутера (recruiter screen) — структурированное интервью 20–40 минут, где рекрутер подтверждает базовую релевантность и управляет ожиданиями.
  • Интервью с нанимающим менеджером — оценка по задачам, ответственности, контексту команды и совместимости ожиданий.
  • Технический этап — оценка профессиональных навыков в формате, который выбрала компания.
  • Scorecard — единая форма критериев оценки, чтобы сравнивать кандидатов по одинаковым правилам.
  • Компетенция — наблюдаемое поведение, связанное с успехом в роли: например, ownership, коммуникация, системное мышление.
  • Важно: рекрутеру не нужно становиться техническим интервьюером, но нужно понимать что именно проверяют этапы и как это переводить кандидату и менеджеру.

    Прескрининг: как быстро отсечь нерелевантное и не потерять сильных

    Прескрининг полезен, когда у вас много исходящих касаний, или когда вакансия имеет жёсткие ограничения. Он может быть в чате или в коротком звонке на 10–15 минут.

    Цели прескрининга

  • подтвердить жёсткие фильтры (локация, формат, язык, on-call, тип занятости)
  • проверить базовый уровень релевантности по роли и ядру стека
  • понять, есть ли смысл в полноценном скрининге
  • не тратить время кандидата и команды, если очевидно не совпадает
  • Типичные вопросы прескрининга

  • Какой формат работы вам подходит: удалёнка, гибрид, офис?
  • Есть ли ограничения по локации или часовому поясу?
  • Насколько вы готовы к on-call, если он есть? Что для вас приемлемо по частоте?
  • Какой у вас текущий фокус по роли: backend, fullstack, platform, data?
  • Какие ожидания по компенсации и срокам выхода?
  • Прескрининг должен быть коротким и корректным. Его задача — пригласить на следующий шаг или честно закрыть вопрос, а не устроить мини-техинтервью.

    Скрининг рекрутера: что именно вы оцениваете и как

    Скрининг рекрутера — это этап, на котором вы одновременно:

  • оцениваете базовое соответствие профилю
  • продаёте роль на языке кандидата
  • фиксируете риски и ожидания
  • готовите данные для технического интервью и менеджера
  • Что проверяет рекрутер на скрининге

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

  • Контекст опыта: продукт, домен, масштаб, команда
  • Роль и вклад: что делал кандидат лично, где был ownership
  • Ядро стека: насколько глубоко совпадает must-have
  • Уровень ответственности: самостоятельность, принятие решений, влияние
  • Мотивация и критерии выбора: задачи, среда, условия, рост
  • Ограничения и стоп-факторы: формат, on-call, английский, сроки, вилка
  • Процесс: согласие с этапами, доступность по времени
  • Как задавать вопросы так, чтобы ответы были сравнимы

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

    Рабочий принцип — структурированное интервью: одинаковые блоки и критерии для сопоставимых кандидатов.

  • Google re:Work: Use structured interviewing
  • Поведенческие вопросы и метод STAR

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

    Один из самых известных форматов структурирования ответа — STAR:

  • Situation — ситуация
  • Task — задача
  • Action — действия
  • Result — результат
  • Wikipedia: STAR method
  • Рекрутеру не обязательно требовать от кандидата идеальный STAR. Но полезно мягко направлять:

  • Какая была ваша роль?
  • Что вы сделали лично?
  • Чем закончилось?
  • Что бы вы улучшили, если бы делали снова?
  • Компетенции и scorecard: как сделать оценку доказательной

    Чем компетенции отличаются от навыков

  • Навык — что человек умеет делать: язык, фреймворк, инструмент.
  • Компетенция — как человек действует в работе: ответственность, коммуникация, принятие решений.
  • В IT-найме ошибки часто происходят так:

  • навыки совпали
  • компетенции не совпали
  • человек не справился с ответственностью уровня или контекстом команды
  • Зачем нужен scorecard

    Scorecard помогает:

  • уменьшить субъективность типа нравится или не нравится
  • собрать оценку по одинаковым критериям от разных интервьюеров
  • проводить адекватный debrief и принимать решения быстрее
  • объяснять отказ на уровне критериев роли
  • Пример scorecard для инженерной роли

    | Критерий | Что наблюдаем | Как выглядит сильный сигнал | |---|---|---| | Опыт по ядру стека | реальный опыт, а не перечисление | может рассказать о решениях и компромиссах | | Ownership | ответственность за компонент или результат | инициировал улучшения, доводил до прод | | Качество поставки | тесты, CI/CD, код-ревью, стабильность | снижал ручной труд, улучшал надёжность | | Системное мышление | понимание последствий решений | видит риски, масштабирование, отказоустойчивость | | Коммуникация | ясность, умение договориться | структурирует, уточняет, умеет спорить по делу | | Совместимость по условиям | формат, on-call, язык, сроки | совпадение без скрытых конфликтов |

    Важно: критерии должны соответствовать Candidate Profile из intake. Если профиль изменился, scorecard тоже должен обновиться.

    Технические этапы: какие бывают и как рекрутер управляет качеством и опытом

    Технический этап — зона ответственности технических интервьюеров, но рекрутер управляет тем, чтобы этап:

  • проверял именно то, что критично для роли
  • не был чрезмерным по времени и сложности
  • был прозрачен для кандидата
  • давал сравнимый результат
  • Ниже — распространённые форматы.

    Техническое интервью по опыту

    Формат:

  • разговор по проектам, решениям, инцидентам, компромиссам
  • Что проверяет:

  • глубину опыта, мышление, зрелость
  • Роль рекрутера:

  • заранее собрать вводные со скрининга, чтобы интервьюер не начинал с нуля
  • Live coding

    Формат:

  • решение задач в реальном времени
  • Плюсы:

  • видно ход мыслей
  • Риски:

  • стресс, зависимость от формата, не всегда коррелирует с реальной работой
  • Роль рекрутера:

  • заранее объяснить среду, язык, ожидания, время
  • подтвердить, что задача релевантна уровню и роли
  • Take-home задание

    Формат:

  • кандидат выполняет задание дома и присылает результат
  • Плюсы:

  • ближе к реальной работе
  • Риски:

  • высокая стоимость времени кандидата
  • риск нечестности или помощи извне
  • Роль рекрутера:

  • согласовать разумный лимит времени
  • заранее дать критерии оценки и дедлайн
  • обеспечить быстрый разбор и обратную связь
  • System design интервью

    Формат:

  • проектирование системы на доске или в документе
  • Что проверяет:

  • архитектурное мышление, компромиссы, масштабирование, надёжность
  • Когда уместно:

  • middle+ и senior роли, особенно backend, platform, distributed systems
  • Роль рекрутера:

  • объяснить кандидату, что оценивают не знание правильного ответа, а ход рассуждений
  • Практические этапы для не-разработческих ролей

    Чтобы не оставлять пробелы, важно помнить про другие семейства ролей.

  • QA: тест-дизайн, анализ требований, иногда авто-тесты
  • DevOps/SRE: инцидентные сценарии, CI/CD, инфраструктура как код, диагностика
  • Data: SQL-кейс, аналитическая задача, пайплайны, качество данных
  • Рекрутеру важно уметь проговорить кандидату:

  • сколько этапов и сколько времени займёт каждый
  • какие материалы можно подготовить заранее
  • как будет приниматься решение и когда будет обратная связь
  • Debrief и финальное решение: как избегать хаоса и предвзятости

    Debrief — обсуждение результатов интервью, где команда сравнивает кандидатов и принимает решение.

    Принципы сильного debrief

  • обсуждаем не личные впечатления, а наблюдаемое поведение и факты
  • опираемся на scorecard и критерии must-have
  • фиксируем риски и способы их проверить, если нужен дополнительный этап
  • разделяем оценку уровня и оценку подхода к работе
  • Типичные источники предвзятости и что делает рекрутер

    | Риск | Как проявляется | Что делать | |---|---|---| | Эффект первого впечатления | решение сформировано в первые 5 минут | возвращать к критериям scorecard | | Гало-эффект | сильная сторона перекрывает слабости | требовать примеры по каждому критерию | | Сходство с интервьюером | нравится, потому что похож | стандартизировать вопросы и сравнение | | Сравнение с предыдущим кандидатом | оценка зависит от очередности | оценивать относительно уровня роли, не относительно других |

    Рекрутер не спорит о технике, но модерирует процесс: где доказательства, какие критерии, какой риск, что делаем дальше.

    Обратная связь кандидату: быстро, корректно, по критериям

    Обратная связь — часть candidate experience и репутации компании. Даже отказ может укрепить доверие, если он:

  • своевременный
  • нейтральный
  • основан на критериях роли
  • не содержит оценочных ярлыков
  • Что можно говорить в отказе

    Обычно безопасный уровень детализации:

  • какой критерий роли не совпал
  • на каком уровне ожидали
  • можно ли вернуться к кандидату позже
  • Что лучше не делать

  • давать диагнозы личности
  • спорить с кандидатом
  • придумывать причины, если их нет
  • обещать, что кандидат точно подходит на будущие роли, если это не согласовано
  • Примеры формулировок

    Отказ после скрининга:

  • Спасибо за разговор. По текущей роли критично X (например, коммерческий опыт с Kubernetes и on-call), а у вас пока это не основной фокус. Если вы будете усиливать эту часть, я буду рад(а) вернуться к вам по похожим позициям.
  • Отказ после техэтапа:

  • Спасибо за время и технический этап. Команда отметила сильные стороны в Y, но по роли сейчас критично X (например, опыт проектирования систем и компромиссы по отказоустойчивости). Поэтому мы не готовы двигаться дальше по этой позиции.
  • Рекрутеру полезно согласовать с компанией политику: какой уровень фидбека допустим, кто его даёт и в какие сроки.

    Операционное управление интервью-этапами: скорость и предсказуемость

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

    Практики, которые дают эффект:

  • заранее назначенные SLA на фидбек после каждого этапа
  • единый шаблон scorecard и обязательность заполнения
  • слотирование интервьюеров заранее, если вакансия приоритетная
  • понятное письмо кандидату: этапы, длительность, подготовка, сроки ответа
  • эскалация задержек не эмоциями, а фактами: кандидат в процессе, дедлайн, риски потери
  • Метрики качества интервью: что смотреть рекрутеру

    Чтобы улучшать этапы, полезно фиксировать хотя бы простые показатели.

  • конверсия между этапами: скрининг → техэтап → финал → оффер
  • доля отказов по условиям на поздних этапах
  • время ожидания фидбека от интервьюеров
  • доля кандидатов, которые сами снялись с процесса из-за скорости или неопределённости
  • Интерпретация важнее цифр. Например, если много отказов после техэтапа, причины обычно в одном из пунктов:

  • неверная планка уровня на intake
  • техэтап проверяет не то, что нужно роли
  • на скрининге не выявляются ключевые риски и ожидания
  • Практический итог

    Сильный рекрутер в IT умеет делать интервью-часть процесса управляемой:

  • прескрининг экономит время и снижает потери
  • скрининг рекрутера превращает хаос ожиданий в понятный профиль и риски
  • компетенции и scorecard делают оценку доказательной и сравнимой
  • понимание техэтапов помогает выстроить прозрачный опыт кандидата
  • debrief снижает предвзятость и ускоряет решения
  • корректная обратная связь защищает бренд и отношения с рынком
  • Этот модуль замыкает цепочку: intake → сорсинг → коммуникации → интервью → решение → обратная связь и превращает найм из набора разговоров в предсказуемую систему.

    7. Оффер, переговоры и аналитика: закрытие вакансий и улучшение процесса

    Оффер, переговоры и аналитика: закрытие вакансий и улучшение процесса

    Как этот модуль связан с предыдущими

    В предыдущем модуле вы выстроили управляемую оценку: прескрининг, скрининг рекрутера, технические этапы, scorecard, debrief и корректная обратная связь. Теперь процесс переходит в самую «дорогую» часть найма: оффер и закрытие.

    Именно на этой стадии чаще всего происходят потери, которые особенно болезненны:

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

    !Наглядная карта этапов после финального интервью до выхода кандидата

    Термины: что мы называем оффером и закрытием

  • Оффер — формальное предложение компании кандидату: роль, уровень, компенсация, условия, дата выхода и юридические детали.
  • Verbal offer — устное (или в созвоне) предложение с ключевыми условиями, чтобы синхронизировать ожидания до отправки документов.
  • Written offer — письменное предложение (письмо, документ, контракт), которое кандидат принимает.
  • Переговоры — обсуждение изменений условий оффера, которые приводят стороны к взаимному согласию.
  • Закрытие вакансии — не «отправили оффер», а довели до результата: кандидат принял предложение и вышел, либо вы управляемо закрыли позицию по другой причине.
  • Preboarding — период от принятия оффера до первого рабочего дня, когда рекрутер снижает риск срыва выхода.
  • До оффера: что нужно выровнять, чтобы не потерять кандидата

    Оффер почти никогда не должен быть «сюрпризом». Чем лучше вы работали на intake, коммуникациях и скрининге, тем меньше «торга из ниоткуда».

    Чек-лист готовности к офферу

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

  • кто финально принимает решение и зафиксировал hire/no hire
  • уровень и название роли (чтобы не было «нанимаем на middle, а в письме junior»)
  • диапазон компенсации и структура (оклад, бонус, опционы, премии)
  • формат работы (удалёнка/гибрид/офис), локация и часовой пояс
  • дата выхода и ограничения кандидата (notice period, отпуск, релокация)
  • наличие on-call и как оно оплачивается или компенсируется
  • юридический формат (штат/контракт, страна, ИП и т.д.)
  • сроки: когда вы отправляете written offer и сколько времени кандидат берёт на решение
  • Если хотя бы один из этих пунктов не согласован, рекрутеру важно остановить «победное» движение и вернуть процесс в управляемое русло.

    Из чего состоит оффер в IT: компоненты, которые кандидат реально сравнивает

    Кандидаты в IT сравнивают не только цифру в письме. Они сравнивают пакет целиком и риски.

    Типовая структура оффера

    | Компонент | Что это означает | Где часто возникают риски потерь | |---|---|---| | Роль и уровень | что именно ожидают и как будут оценивать | разрыв ожиданий по ответственности | | Компенсация | оклад и дополнительные выплаты | кандидат ожидал другое; не проговорили вилку | | Бонус/переменная часть | условия начисления и прозрачность | «бонус есть», но он недостижим или размытый | | Equity/опционы | доля/опцион и условия vesting | сложность объяснения, неопределённость | | Формат работы | удалёнка/гибрид/офис, локация | несостыковка с жизнью кандидата | | График и on-call | дежурства, окна релиза, нагрузка | on-call всплывает слишком поздно | | Бенефиты | ДМС, обучение, техника, отпуск | ожидания кандидата vs реальность | | Дата выхода | старт и условия до старта | затяжные согласования, переносы | | Юридические условия | контракт, испытательный срок, NDA | «мелкий шрифт», который пугает |

    Практический принцип рекрутера: кандидат должен понимать самые влияющие условия до финала интервью. Иначе вы переносите риск в оффер-стадию.

    Как презентовать оффер: сценарий, который повышает принятие

    Почему сначала verbal offer

    Verbal offer помогает:

  • проверить, что ключевые условия совпадают с ожиданиями
  • быстро снять вопросы кандидата до отправки документов
  • не запускать бюрократию, если кандидат уже понимает, что не готов
  • Рекомендуемый сценарий разговора

    Ниже структура созвона на 10–20 минут. Её можно адаптировать под культуру компании.

  • Коротко подтвердите решение команды и почему кандидат выбран.
  • Назовите роль, уровень, команду и 2–3 главных ожидания по задачам.
  • Озвучьте компенсацию и структуру (что входит, что зависит от условий).
  • Проговорите формат работы, on-call и дату выхода.
  • Спросите прямо: что кандидату нужно, чтобы принять решение.
  • Договоритесь о сроках: когда вы пришлёте written offer и когда ждёте ответ.
  • Важно: рекрутеру стоит говорить спокойно и конкретно. Слишком «продающий» тон часто снижает доверие у опытных инженеров.

    Переговоры: как вести профессионально и без конфликта

    Переговоры в IT — не признак проблемы. Это нормальный этап рынка, где кандидаты умеют сравнивать предложения.

    Рамка переговоров: интересы и ограничения

    Чтобы переговоры не превращались в спор, разделяйте:

  • интерес кандидата: например, «хочу больше стабильности и предсказуемости дохода»
  • позицию кандидата: например, «хочу +20% к окладу»
  • ограничение компании: например, бюджет грейда, внутренняя справедливость, политика компенсаций
  • Если вы понимаете интерес, часто можно договориться не только деньгами.

    Рычаги переговоров: чем реально можно управлять

    | Рычаг | Когда помогает | Ограничения | |---|---|---| | Оклад | когда кандидат сравнивает по рынку и уровню | бюджет, грейд, внутренняя справедливость | | Sign-on bonus | когда кандидат теряет бонус/акции на текущей работе | нужен быстрый approval, не всегда принят политикой | | Пересмотр через 3–6 месяцев | когда кандидат сильный, но бюджет ограничен | важны прозрачные критерии, иначе потеря доверия | | Грейд/титул | когда кандидату важна ответственность и трек развития | нельзя «раздавать» тайтлы без реальной роли | | Формат и гибкость | когда человек ценит удалёнку/график | зависит от политики и команды | | Дата выхода | когда кандидат хочет быстрее/позже | зависит от проекта и онбординга | | Обучение/конференции/техника | когда важен рост или комфорт | обычно не заменяет существенную разницу в деньгах |

    Тактики, которые повышают шанс договориться

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

  • Harvard Program on Negotiation: Negotiation skills
  • Конкурирующие офферы и контроффер: как управлять рисками

    Конкурирующий оффер

    Если кандидат говорит, что у него есть другое предложение, ваша задача не «перебить», а понять картину.

    Сильные вопросы рекрутера:

  • какие параметры вы сравниваете в первую очередь: задачи, уровень, деньги, формат, бренд
  • какие условия у другого предложения фиксированы, а какие обсуждаемы
  • какой срок принятия решения
  • Дальше вы:

  • сравниваете со своим оффером по ключевым критериям кандидата
  • эскалируете изменения только при понятном шансe закрыть кандидата
  • не уходите в бесконечный торг без сроков
  • Контроффер от текущего работодателя

    Контроффер часто строится вокруг денег или обещаний изменений. Рекрутеру важно быть этичным: вы не «ломаете» кандидата, вы помогаете принять осознанное решение.

    Что можно сделать профессионально:

  • напомнить, почему кандидат начал процесс и что было триггером
  • предложить кандидату сравнить предложения по 3–5 критериям, а не по одной цифре
  • обсудить риски контроффера: обещания без сроков, повтор проблемы через 3–6 месяцев
  • Что не стоит делать:

  • давить и стыдить
  • говорить плохо про текущего работодателя
  • обещать срочные изменения, которые вы не можете гарантировать
  • Preboarding: как удержать кандидата до выхода

    После принятия оффера риск ещё остаётся. В IT он особенно заметен из-за длинных сроков выхода и конкурентного рынка.

    План контакта до первого дня

    Минимальная дисциплина preboarding:

  • договориться, как и когда вы остаётесь на связи (например, короткий чек-ин раз в неделю)
  • помочь с документами и прозрачными сроками оформления
  • подключить будущего менеджера: короткое приветственное сообщение или созвон
  • выслать план первого дня и онбординга, чтобы снизить неопределённость
  • Сигналы риска, которые стоит отслеживать

  • кандидат стал отвечать медленнее и короче
  • начались переносы подписания документов
  • кандидат задаёт много вопросов про «если вдруг изменится…»
  • внезапно меняются сроки выхода без ясной причины
  • Профессиональная реакция рекрутера: не паниковать, а уточнять и помогать закрывать неопределённость.

    Аналитика: какие метрики помогают закрывать вакансии быстрее и качественнее

    Аналитика в рекрутменте нужна не ради отчётов, а чтобы понимать, где именно теряется время и кандидаты.

    Ниже — базовый набор метрик, который даёт управляемость. Формулы простые; главное — одинаково считать их в команде.

    Time to fill

    Где:

  • — дата открытия вакансии
  • — дата закрытия (часто дата принятия оффера, иногда дата выхода, это важно договориться)
  • Интерпретация:

  • метрика показывает, сколько в целом компания закрывает потребность
  • полезно сравнивать по ролям и уровням, а не «всё вместе»
  • Time to hire

    Где:

  • — дата первого контакта с кандидатом (outreach или отклик)
  • — дата принятия оффера
  • Интерпретация:

  • помогает увидеть скорость именно вашего процесса, а не только рынка
  • если time to hire растёт, ищите узкие места: ожидание фидбека, слоты интервью, согласования оффера
  • Offer acceptance rate

    Где:

  • — количество сделанных офферов за период
  • — количество принятых офферов за период
  • Интерпретация:

  • низкий показатель часто означает неконкурентные условия или слабую работу с ожиданиями
  • важно смотреть причины отказов: деньги, формат, задачи, скорость, контроффер
  • Конверсия по этапам

    Конверсию можно считать для любой пары этапов, например от скрининга до техэтапа:

    Где:

  • — кандидаты, которые пришли на этап
  • — кандидаты, которые прошли дальше
  • Интерпретация:

  • если конверсия падает на техэтапе, это может быть несоответствие планки на intake или нерелевантный формат оценки
  • !Пример того, как выглядит аналитика воронки и где искать узкие места

    Как превращать аналитику в улучшения: цикл профессионального рекрутера

    Метрики сами по себе ничего не меняют. Меняет процесс петля улучшений.

    Шаблон цикла улучшений

  • Зафиксируйте симптом: например, «офферы часто отклоняют» или «оффер согласуется 10 дней».
  • Соберите причины в категорию:
  • - условия и компенсация - скорость процесса - несостыковка ожиданий по задачам/уровню - качество оценки
  • Проверьте данными:
  • - причины отказов по офферу - время между финалом и отправкой оффера - где чаще всего кандидаты «зависают»
  • Согласуйте 1–2 изменения на следующий цикл:
  • - сократить этапы - заранее согласовать вилку и рычаги - изменить текст оффера или сценарий verbal offer - улучшить preboarding
  • Измерьте эффект на следующем пуле кандидатов.
  • Практический принцип: улучшайте процесс малыми итерациями, иначе вы утонете в «реформах без результата».

    Управление стейкхолдерами: как ускорять согласования без конфликта

    Частая причина потери кандидатов — не рекрутер и не интервью, а внутренние задержки.

    Что помогает рекрутеру ускорять офферы

  • заранее согласованный процесс approval: кто, в каком порядке, какие сроки
  • шаблон оффера и список обязательных полей, чтобы не собирать документ заново
  • заранее определённые «коридоры» по компенсации на грейд
  • эскалация не эмоцией, а фактами: дедлайн кандидата, конкурентный рынок, риск потери
  • Короткий формат апдейта по офферу

    Это можно отправлять в чат или письмом.

  • статус: решение принято, оффер в согласовании
  • дедлайн: кандидат ждёт до (дата/время)
  • что нужно: апрув от (роль/имя) и подтверждение суммы
  • риск: у кандидата параллельный процесс/оффер
  • следующий шаг: когда отправляем written offer
  • Этика на стадии оффера

    Оффер и переговоры — зона, где легко разрушить доверие.

    Базовые нормы:

  • не обещать условия, которые не согласованы
  • не «маскировать» важные ограничения (on-call, офис, командировки)
  • уважать право кандидата сравнивать предложения
  • аккуратно работать с персональными данными и деталями других офферов
  • Если компания работает с персональными данными кандидатов в контексте регуляций, держите в голове общие принципы защиты данных.

  • Общий регламент ЕС по защите данных (GDPR), официальный текст
  • Практический итог

    Сильный IT-рекрутер закрывает вакансии предсказуемо, потому что он управляет всей цепочкой после интервью:

  • делает оффер продолжением ранней работы с ожиданиями, а не «сюрпризом»
  • ведёт переговоры через интересы и рычаги, сохраняя доверие
  • снижает риск срыва выхода через preboarding
  • использует метрики, чтобы находить узкие места и улучшать процесс итерациями
  • Этот модуль завершает цикл end-to-end: от intake и сорсинга до принятого оффера и улучшенного процесса найма на следующей вакансии.