Перейти к основному контенту
Tech Path Finder
КурсыИнтервьюКод-ревьюБлог
Tech Path Finder

Персонализированный путеводитель в IT. Квизы, мок-интервью, код ревью и аналитика прогресса.

@potapov_me

Платформа

  • Курсы
  • Прогресс
  • Мок-интервью
  • Код ревью
  • Живое ревью с ИИ
  • Тренажёр переговоров
  • Закладки

Контент

  • Блог
  • Главная
  • Обратная связь

Компания

  • О проекте
  • Тарифы
  • Условия использования
  • Конфиденциальность
  • Согласие на обработку данных
  • Cookie
  • Реквизиты

Аккаунт

  • Войти
  • Зарегистрироваться
  • Профиль

© 2026 Tech Path Finder. Все права защищены.

·ИП Потапов К.С.·Политика конфиденциальности·
Сделано с ❤️ в России
  1. Найм
hiring

Найм

Технические интервью, критерии оценки, обратная связь, адаптация новых сотрудников, избежание предвзятости

Учебник: Найм и построение команды

Время освоения: ~40 минут Цель: Научиться выстраивать эффективный процесс найма — от описания вакансии до онбординга — и избегать типичных ошибок, которые дорого обходятся команде


#Быстрый справочник

#Воронка найма

ЭтапЧто происходитКлючевой результат
Job DescriptionОписание роли, требований, контекстаПривлечь нужных кандидатов, отсеять нерелевантных
Скрининг резюмеCriteria matrix, shortlist10–15 кандидатов для интервью
Телефонный/видео скрининг30 мин, культура + базовые навыки5–7 кандидатов на техэтап
Техническое интервьюCoding, system design, кейсы2–3 финалиста
Финальное интервьюМотивация, deep dive, fit1 оффер
Оффер и онбордингПереговоры, план 30/60/90Успешная интеграция

#Типы интервью

ТипЦельКогда использовать
Structured InterviewОдинаковые вопросы + scorecard для всехВсегда, снижает bias
Behavioural (STAR)Поведение в прошлых ситуацияхSoft skills, culture fit
Technical CodingРешение алгоритмических задачJunior/Middle разработчики
System DesignПроектирование системMiddle/Senior/Staff
Case InterviewАнализ реального сценарияSenior/Lead роли
Take-home заданиеПрактическая работа без давленияАльтернатива live coding

#Criteria Matrix (scorecard)

КритерийJuniorMiddleSenior
Технические навыки40%35%25%
Problem-solving30%30%25%
Коммуникация15%20%25%
Leadership/Ownership5%10%20%
Culture fit10%5%5%

Быстрый справочник

  • Structured interview надёжнее unstructured в 2x — одинаковые вопросы всем кандидатам
  • Scorecard до интервью: без неё решение принимается "по ощущению"
  • 5 cognitive biases в найме: affinity, halo, recency, attribution, confirmation
  • Job description: требования vs nice-to-have — будь честен, иначе теряешь кандидатов
  • Take-home задания: не более 3–4 часов; оплачивай если можешь
  • Онбординг: 30/60/90 план + buddy системa — снижает время до продуктивности
  • Решение о найме: совет директоров принципа "hire for strength, not absence of weakness"

#Введение (5 минут)

Найм — это не административная задача HR. Это стратегическая функция тимлида, которая определяет качество команды на годы вперёд. Одна неудачная hire в небольшой команде из 5 человек — это 20% деструктивной энергии. И наоборот: правильный найм мультиплицирует эффективность команды.

Почему найм критически важен для тимлида:

  • Один сильный инженер может заменить 3 средних по продуктивности
  • Средняя стоимость неудачного найма — от 1 до 3 годовых зарплат кандидата (рекрутинг, онбординг, потеря производительности, увольнение)
  • Культура команды формируется через людей, которых в неё нанимают
  • Тимлид несёт ответственность за результат — значит, должен влиять на то, кто в команде

Типичная ошибка: делегировать найм полностью HR и участвовать только в финальном интервью. Тимлид должен быть вовлечён с этапа job description.

Помните: лучше потратить 3 месяца на правильный найм, чем 12 месяцев на управление неправильным человеком.


#Создание Job Description (8 минут)

#Почему большинство JD не работают

Типичный job description — это список из 20 требований, половина которых — wish list, не обязательные условия. Такой JD отпугивает хороших кандидатов (особенно женщин и underrepresented groups, которые не подают заявку, если не соответствуют 100% требований) и привлекает тех, кто просто умеет хорошо "продавать себя" на бумаге.

#Структура эффективного JD

1. Контекст и миссия (3-4 предложения) Что делает команда? Какую проблему решает продукт? Какова роль этой позиции в большой картине?

Мы строим платёжную инфраструктуру для 2M+ пользователей.
Backend Engineer будет отвечать за надёжность платёжного pipeline
и владеть сервисами обработки транзакций.

2. Must-have vs. Nice-to-have Разделяйте обязательные требования и желаемые явно:

  • Must-have: 3+ года опыта с Python, понимание распределённых систем, опыт с PostgreSQL
  • Nice-to-have: Знакомство с Kafka, опыт в финтех, контрибьюции в open source

3. Избегание bias в JD:

  • Убирайте слова "рок-звезда", "ниндзя", "гений" — они отпугивают разнообразных кандидатов
  • Не требуйте диплом, если это не критично для роли
  • Не указывайте конкретные годы опыта без обоснования (правило "5 лет с React" при существовании React 8 лет — красный флаг)
  • Используйте гендерно-нейтральный язык
  • Инструменты проверки: Textio, Gender Decoder

4. Что включить в JD, чего обычно не включают:

  • Стек технологий (реальный, а не aspirational)
  • Как выглядит типичный день/неделя
  • Как принимаются технические решения в команде
  • Процесс найма (сколько этапов, что ожидать)
  • Компенсационная вилка (прозрачность привлекает сильных кандидатов)

#Скрининг и отбор (8 минут)

#Скрининг резюме через Criteria Matrix

Не читайте резюме интуитивно — создайте matrix критериев заранее:

КритерийВесКандидат AКандидат B
Релевантный стек33/32/3
Размер системы (scale)32/33/3
Навыки лидерства21/22/2
Отраслевой опыт11/10/1
Итого977

Это убирает субъективность и позволяет сравнивать кандидатов честно.

#Телефонный/видео скрининг (30 минут)

Цель скрининга — убедиться, что кандидат базово подходит до дорогостоящего технического интервью.

Структура:

  1. Intro (5 мин): расскажите о компании и роли
  2. Мотивация (5 мин): почему эта роль, почему сейчас
  3. Ключевые вопросы (15 мин): 2-3 вопроса по must-have критериям
  4. Вопросы кандидата (5 мин)

Сигналы к отказу на скрининге:

  • Кандидат не может объяснить, что делал в предыдущих ролях
  • Ищет только деньги/статус без интереса к задачам
  • Не задаёт ни одного вопроса

#Take-home задания

Take-home задание — хорошая альтернатива live coding, особенно для senior-кандидатов.

Когда использовать: Middle+ роли, когда нужно оценить реальный код, а не "coding под давлением"

Правила хорошего take-home:

  • Ограничение по времени: 3-4 часа (и соблюдайте его)
  • Реальная задача, похожая на работу (не абстрактные алгоритмы)
  • Платите за время (для senior-задач >4 часов)
  • Давайте чёткие критерии оценки заранее

#Техническое интервью (10 минут)

#Structured vs. Unstructured

Unstructured интервью (разговор без плана) — одно из самых ненадёжных инструментов оценки. Интервьюер оценивает "chemistry" и "gut feeling", что напрямую коррелирует с affinity bias.

Structured интервью — каждый кандидат получает одинаковые вопросы, оценивается по одинаковым критериям. Надёжность предсказания performance выше в 2x.

Структура технического интервью (60-90 минут):

БлокВремяСодержание
Введение5 минРасскажите о себе, снимите напряжение
Техническая задача35-40 минCoding или system design
Behavioural вопросы15 мин2-3 STAR вопроса
Вопросы кандидата10 минОбязательно!
Wrap-up5 минСледующие шаги

#Coding Challenges: что оценивать

Не только "решил ли задачу", а:

  • Ход мышления: уточняет ли требования, называет ли assumptions?
  • Коммуникация: думает ли вслух?
  • Итеративность: начинает ли с brute force, оптимизирует ли?
  • Обработка edge cases: помнит ли о null, пустых массивах, переполнении?
  • Тестируемость: пишет ли тесты или думает о них?

#Системный дизайн: структура ответа

Ожидаемый фреймворк от кандидата:

  1. Уточнение требований (functional + non-functional)
  2. Оценка масштаба (QPS, хранилище)
  3. High-level дизайн
  4. Deep dive в компоненты
  5. Трейд-оффы и alternatives

#Behavioural вопросы по методу STAR

  • Situation: Опишите контекст
  • Task: Какая была задача/проблема
  • Action: Что конкретно вы сделали (именно вы, не команда)
  • Result: Каков измеримый результат

Примеры вопросов:

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

#Избегание предвзятости (5 минут)

#Основные типы bias в найме

BiasОписаниеРешение
Affinity bias"Он/она похож на меня"Diverse interview panels
Halo/Horn effectОдно качество окрашивает всёScorecard с отдельными критериями
Confirmation biasИщем подтверждение первого впечатленияСтруктурированные вопросы
Beauty/likeabilityПривлекательность = компетентностьАнонимные coding challenges
Attribution biasУспех — заслуга, провал — обстоятельстваОдинаковые вопросы для всех

#Практические меры

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

Diverse panels: минимум 2 интервьюера, желательно разного пола/бэкграунда.

Blind review: при скрининге резюме — скройте имя и фото (tools: Blendoor, GapJumpers).

Calibration meeting: после каждых 10-15 хайров проводите calibration — сравнивайте оценки с реальной performance нанятых. Это позволяет обнаружить систематические ошибки.


#Онбординг: план 30/60/90 дней (4 минуты)

Онбординг — продолжение найма. Плохой онбординг обнуляет хороший найм.

#Buddy System

Назначьте новому сотруднику "buddy" — коллегу (не тимлида), к которому можно обращаться с любыми вопросами без страха "выглядеть глупо". Buddy — не ментор, а навигатор по команде.

#План 30/60/90 дней

ПериодФокусОжидаемые результаты
30 днейПонятьЗнает кодовую базу, задеплоил первую задачу, познакомился с командой
60 днейВносить вкладЗакрывает задачи самостоятельно, участвует в code review
90 днейВладетьБерёт ownership над небольшой фичей, предлагает улучшения

#Определение успеха

В первый день озвучьте новому сотруднику:

  • "Через 30 дней успех выглядит так: ..."
  • "Через 90 дней успех выглядит так: ..."

Это убирает тревожность и задаёт ориентиры. Проводите weekly 1:1 в первый месяц — это не overhead, это инвестиция.


#AI-инструменты в найме: возможности и риски

Современные инструменты (GitHub Copilot screening, AI resume screening, automated video interviews) создают новые риски предвзятости.

Риски AI в найме:

  • Systemic bias: AI обучается на исторических данных — если исторически нанимали однородных кандидатов, AI усилит этот паттерн
  • Proxy discrimination: AI может научиться дискриминировать по признакам которые коррелируют с защищёнными характеристиками (почтовый индекс → раса)
  • Screening false negatives: автоматические системы отсеивают нетрадиционных кандидатов (кандидаты без диплома, смена отраслей)

Правила при использовании AI в найме:

  1. AI — фильтр для уменьшения нагрузки, не принимает финальные решения
  2. Регулярно аудитируй: какой % отсеянных кандидатов — женщины / недопредставленные группы?
  3. Дай кандидатам возможность объяснить нетрадиционный бэкграунд
  4. Проверяй AI решения на репрезентативной выборке вручную

Coding challenges и AI: Кандидаты используют AI на take-home заданиях. Это реальность. Адаптируй процесс:

  • Перейди к задачам где важно объяснение решения (почему это решение, какие trade-offs)
  • Используй live coding с обсуждением вместо take-home
  • Оценивай thinking process, не только правильность кода

#⚠️ Типичные ошибки

ОшибкаПочему это плохоКак исправить
Нанимают "похожих на себя" (affinity bias)Команда теряет разнообразие, blind spots накапливаются, инновации замедляютсяScorecard с чёткими критериями, diverse панели, анонимный скрининг резюме
JD из 20 требований без разбивки на must/niceОтпугивает сильных кандидатов, особенно underrepresented groups — они не подают заявку при неполном соответствииСократить до 5-7 must-have, честно назвать nice-to-have
Нет структуры интервью — "просто поговорим"Gut feeling коррелирует с bias, надёжность оценки падает в 2xСоздать scorecard, стандартизировать вопросы для всех кандидатов
Спешка в найме при горящей позицииНанимают "достаточно хорошего" вместо "правильного", потом разгребают годамиЛучше закрыть позицию контрактором и потратить 2-3 месяца на поиск
Онбординг = "вот ноутбук, разберись сам"Время до продуктивности растёт с 1 до 4+ месяцев, риск уйти до 1 года удваивается30/60/90 план + buddy + weekly 1:1 в первый месяц
Не измеряют качество наймаНеясно, какие каналы работают, какие интервьюеры точныОтслеживать: time-to-hire, 90-day retention, 1-year performance rating по каналам

#Практические упражнения

#Упражнение 1: Аудит вашего JD

Возьмите текущий job description вакансии (или придумайте типичный для вашей роли).

  1. Выпишите все требования двумя столбцами: Must-have и Nice-to-have
  2. Для каждого must-have ответьте: "Почему без этого нельзя начать работу с первого дня?"
  3. Проверьте текст через сервис Gender Decoder (decoder.net): сколько мужских/женских слов?
  4. Посчитайте: сколько требований осталось в must-have? Если больше 7 — сократите.

Цель: Создать JD, который честно описывает роль и привлекает разнообразных кандидатов.

#Упражнение 2: Создание Scorecard

Вы нанимаете Middle Backend Engineer. Создайте scorecard для технического интервью.

  1. Выберите 4-5 критериев оценки (не больше)
  2. Для каждого критерия опишите, что означает оценка 1, 3, 5 по шкале
  3. Назначьте вес каждому критерию (в сумме 100%)
  4. Напишите по 2 вопроса для каждого критерия

Пример критерия:

  • Критерий: Системное мышление
  • 1/5: Думает только о текущей задаче, не видит зависимостей
  • 3/5: Учитывает смежные сервисы, задаёт уточняющие вопросы
  • 5/5: Проактивно называет трейд-оффы, предлагает альтернативы с аргументами

Далее: Эффективность