После десятков собесов я понял: текущий найм — сломан

2026 год на пороге. Искусственный интеллект ^[1] уже не модное словосочетание, а коллега. Copilot подсказывает код в IDE, а ChatGPT помогает с архитектурой. Но наши подходы к найму техспециалистов всё ещё застряли между допросами и бесконечными этапами, которые отнимают время, но не показывают реальных навыков.

Меня зовут Григорий, я разработчик. За последние несколько лет я прошел десятки собеседований с обеих сторон: и как кандидат, и как интервьюер.

Эта статья — не истина в последней инстанции. Это скорее диалог. Предлагаю порассуждать, каким должно быть техническое собеседование в 2025 году с учётом соврeменных реалий.

> Далее я кратко пройдусь по основным популярным кейсам отбора специалистов, выделю субъективные плюсы и минусы и после предложу своё решение. Если вас интересует только моё предложение — смело пропускайте следующий раздел, но для полноты восприятия ^[2] мысли я рекомендую уделить ему время.

Что мы имеем на данный момент →

• Ускоренный: Общение с HR → Техническое собеседование → Оффер

• Стандартный: Общение с HR → Техническое собеседование → Собеседование с командой → Оффер

• Бигтеховский: Общение с HR → Лайвкодинг → Техническое собеседование → Оффер

• Ультра Бигтеховский: Общение с HR → Лайвкодинг → Техническое собеседование → Собеседование с командой/руководителем → Оффер

Ускоренный

Быстрое закрытие вакансии, но есть риски «промаха» из‑за поверхностной оценки.

• Суть: Одна‑две встречи, где за пару часов пытаются оценить и hard, и soft skill.

• Плюсы: Быстро, не отнимает много времени.

• Минусы: Высокий шанс ошибки ^[3]. Заученные ответы на стандартные вопросы создают иллюзию компетентности.

Стандартный

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

• Суть: Многоэтапный процесс, включающий техническое интервью и встречу с будущей командой для оценки soft skills.

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

• Минусы: Сохраняется шанс ошибки.

Бигтеховский

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

• Суть: Кандидат решает алгоритмические задачи на глазах у интервьюера, а затем отвечает на теоретические вопросы.

• Плюсы: Позволяет оценить ход мыслей под давлением.

• Минусы: Это искусственная, стрессовая среда, имеющая мало общего с повседневными задачами. Она отсеивает не плохих разработчиков, а тех, кто не тренировался решать задачи на LeetCode. Не проверяет умение писать поддерживаемый код и работy в команде.

Ультра Бигтеховский

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

• Суть: Расширенный пайплайн с 4–6 этапами, включающий лайвкодинг, системный дизайн и несколько технических интервью.

• Плюсы: Максимально полная оценка как технических, так и коммуникативных навыков.

• Минусы: Сильный эмоциональный стресс ^[4] для кандидата, требует 20+ часов времени, высокий процент отказов на поздних этапах.

Что предлагаю

Я предлагаю гибридный подход, адаптированный к реалиям 2025 года.

• Гибридный формат: Общение с HR → Техническое задание → Обсуждение задания → Оффер

1. Оценка кандидата ( до 30 минут)

• Кто: Рекрутер или будущий тимлид.

• Суть: Взаимное знакомство. Обсуждение проекта, ценностей команды и ожиданий от роли.

• Цель: Определить, насколько вы подходите друг другу.

2. Практическое задание с честными условиями

• Формат: Небольшое задание, максимально похожее на реальную задачу действующего сотрудника из команды. Объем — не более 4–6 часов реальной работы.

• Условия: Мы четко говорим: «Задача передается вам в пятницу после 18:00, срок сдачи — до понедельника 10:00». Так мы не отнимаем время у текущих рабочих процессов кандидата.

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

Разрешено использовать всё что используется в реальной работе «Stack Overflow, ИИ, поисковики», кроме прямой помощи третьих лиц. Нельзя просить другого человека решить задание за вас.

3. Технический диалог на основе кода (~45 минут)

• Кто: будущий тимлид, представители команды.

• Формат: Встреча, где мы вместе разбираем присланное решение.

• Фокус: Не на том, «правильно» ли оно, а на том, почему оно такое.

• Зачем: Этот необходим для выявления авторства. Человек, который сам писал код, легко и глубоко рассуждает о нем. Это проверка инженерного мышления ^[5], а не памяти ^[6].

4. Принятие решения и Офер

• Процесс: После технического диалога команда проводит внутреннее обсуждение, опираясь на балльную оценку задания и впечатления ^[7] от диалога. Решение принимается коллегиально.

• Обратная связь: Мы предоставляем кандидату развернутую обратную связь по результатам задания и диалога, независимо от исхода. Это знак уважения к потраченному времени.

• Оффер: Финалисту направляется предложение.

Плюсы и минусы

Плюсы:

• Для кандидата:

  • Справедливость: Оценка происходит на основе реальной работы.

  • Прозрачность: Кандидат с первого этапа понимает критерии оценки.

  • Обратная связь: Даже в случае отказа кандидат получает ценный фидбэк.

• Для компании:

  • Мотивация ^[8] кандидата: Мы отсеиваем не мотивированных кандидатов в данной позиции.

  • Релевантная оценка: Видим навыки в условиях, близких к рабочим.

  • Проверка мышления: Мы проверяем способность обосновывать решения, а не просто писать код.

  • Экономия времени команды: Основная нагрузка ложится на этап проверки задания, а не на собеседования.

Минусы:

• Орг. затраты: Нужно создавать и поддерживать актуальные тестовые задания.

• Риск «Завала»: Кандидаты могут завалить команду заданиями на проверку, требуется автоматизация.

• Риск бесплатной работы: Важно, чтобы задание было учебным, а не реальной задачей компании.

Вывод

Методы найма должны эволюционировать вместе с современными технологиями и реалиями работы.

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

А что думаете вы?

Тот же принцип применим и к построению процессов внутри компаний: меньше формальностей, больше реальной работы с причинами, узкими местами и гипотезами. Если хочется системно прокачать этот навык — на курсе «Оптимизация бизнес-процессов» ^[9] разбираются методы моделирования, анализа и улучшения процессов так же прагматично, как хороший технический разбор кода.

Чтобы узнать больше о формате обучения ^[10] и познакомиться с преподавателями, приходите на бесплатные демо-уроки курса:

• 25 ноября: «Как, зачем и когда стоит измерять бизнес-процессы». Записаться ^[11]

• 10 декабря: «Моделирование бизнес-процессов». Записаться ^[12]

• 16 декабря: «Зачем бизнесу улучшать процессы?». Записаться ^[13]