Geekfactor Geekfactor
Копируемый план тех. интервью 60–90 минут для HR и техлидов

Копируемый план тех. интервью 60–90 минут для HR и техлидов

Автор: Без автора

Готовый план технического интервью: шаблон на 60–90 минут, роли участников, рубрика оценки 1–4 с поведенческими якорями и алгоритм дебрифинга. Такой план закрывает четыре этапа: вводный блок, техническое задание, обсуждение и итоговое решение. Дальше в статье — конкретные шаблоны, чек-листы подготовки и рубрика, которую можно скопировать и применить на ближайшем собеседовании.

Кратко:

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

Содержание

Чек-лист подготовки к техническому интервью: 48 часов и день Х

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

За 48 часов до встречи:

  1. Отправьте кандидату письмо с длительностью, форматом (видеозвонок, живой код, задача) и списком инструментов, которые понадобятся.
  2. Сверьтесь с техлидом, какие компетенции критичны для конкретной роли, и зафиксируйте это в профиле успеха.
  3. Проверьте технические доступы: ссылку на IDE или whiteboard, права в репозитории, тестовое окружение.
  4. Разошлите интервьюерам рубрику оценки и напомните про независимое заполнение карточек.
  5. Назначьте роли: кто ведёт беседу, кто наблюдает и фиксирует сигналы, кто отвечает за резервный план на случай сбоев.

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

Шаблон плана технического интервью на 60–90 минут

Шаблон 60-минутного интервью с введением, основной задачей, доработками и вопросами кандидата остаётся самым универсальным форматом: он даёт достаточно сигнала, но не утомляет кандидата, как отмечает HackerRank. Слишком растянутый процесс отсеивает сильных специалистов ещё до оффера — они просто уходят к тем, кто решает быстрее.

Базовая раскладка на час:

  • 5–10 минут — знакомство, короткий рассказ о роли и формате, снятие напряжения.
  • 35–45 минут — основная задача: код, дизайн системы или разбор кейса, в зависимости от грейда.
  • 10–15 минут — обсуждение решения, вопросы кандидата к команде, обратная связь по next steps.

Для junior-позиций формат стоит сжать до 45 минут с одной несложной задачей и акцентом на то, как человек рассуждает вслух, а не на идеальный синтаксис. Для senior-ролей логичен двухраундовый формат: первый час на кодинг или алгоритмическую задачу, второй — отдельная сессия по дизайну системы с архитектором или тимлидом в качестве интервьюера.

Роли распределяются так: рекрутер открывает встречу и снимает организационные вопросы, ведущий техинтервью держит основную задачу и тайминг, а наблюдатель или второй интервьюер фиксирует сигналы в рубрике, не вмешиваясь в диалог. Формат задания выбирайте под роль: алгоритмическая задача подходит для позиций с высокой алгоритмической нагрузкой, дизайн системы — для senior и архитекторов, take-home — когда живой код неудобен по часовому поясу или формату работы.

Рубрика оценки: четыре измерения и шкала с поведенческими якорями

Рубрики для кодинговых интервью обычно строятся вокруг четырёх измерений: коммуникация, решение задач, техническая компетентность и тестирование, согласно Tech Interview Handbook. Каждое измерение получает отдельную шкалу от 1 до 5 с описанием, что именно значит каждая отметка — без этого оценка превращается в субъективное «вроде норм».

Пример поведенческих якорей для измерения «решение задач»:

  • 1 — кандидат не может сформулировать план решения даже с подсказками, теряется при первом же усложнении.
  • 3 — предлагает рабочее решение, но не рассматривает альтернативы и не проговаривает компромиссы.
  • 5 — сравнивает несколько подходов, явно проговаривает trade-offs с учётом сложности и контекста задачи.

Стандартизированный рубрикатор с такими якорями переводит субъективную беседу в сопоставимые данные и снижает влияние личных симпатий на итоговую оценку, отмечает AIHR. Для middle и senior позиций стоит агрегировать оценку по сумме баллов за каждое измерение отдельно — это показывает конкретные слабые зоны. Для junior разумнее использовать общий балл: детализация по метрикам на раннем уровне часто избыточна и усложняет решение.

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

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

Дебриф и принятие решения после технического интервью

Дебриф — это не встреча ради галочки, а структурированный процесс с чётким алгоритмом:

  1. Каждый интервьюер заполняет карточку оценки сразу после своего блока, пока детали свежи в памяти.
  2. Координатор (обычно рекрутер) собирает все карточки перед общей встречей.
  3. Команда встречается на 15–20 минут, обсуждает расхождения в оценках и приходит к консенсусу или голосует.
  4. Итоговое решение фиксируется письменно вместе с планом онбординга, если кандидат принят.

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

По срокам разумный ориентир — обратная связь кандидату в течение 24–72 часов после финального этапа. Долгое молчание чаще всего означает потерю сильного кандидата в пользу более быстрой компании.

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

Практика Geekfactor: рубрики в деле для узких технических ролей

Geekfactor регулярно адаптирует стандартную рубрику под задачи конкретного проекта: для platform engineer добавляется отдельный блок про работу с инфраструктурой как кодом и инцидент-менеджмент, для senior developer — усиленный вес на архитектурные решения и оценку trade-offs с учётом бизнес-контекста. Опытные интервьюеры оценивают не только финальный код, но и то, насколько кандидат способен обосновать выбор с точки зрения бизнеса, а не только технологии, отмечает практическое руководство по найму.

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

Как записывать фидбэк и организовать дебрифинг

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

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

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

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

Как снизить предвзятость при оценке кандидатов

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

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

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

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

Как снизить предвзятость при оценке кандидатов — overview diagram

Шаблоны заданий: живой код, дизайн системы, take-home

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

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

Дизайн системы уместен для middle и senior позиций и требует 45–60 минут отдельным блоком. Здесь важнее не итоговая схема, а то, как кандидат прорабатывает требования: спрашивает про нагрузку, обсуждает компромиссы между консистентностью и доступностью, называет конкретные технологии с обоснованием, а не просто перечисляет модные слова.

Сравнение форматов заданий для технического интервью

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

Опыт кандидата: информирование и скорость решения

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

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

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

Финальное решение разумно сообщать в течение 24–72 часов после последнего этапа, как уже говорилось в разделе про дебриф. Если процесс объективно требует больше времени из-за согласований, честнее сказать об этом прямо, чем тянуть без объяснений. Кандидаты на техническом рынке труда обычно ведут несколько процессов параллельно, и скорость решения нередко перевешивает размер оффера.

Технические требования к подготовке интервью

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

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

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

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

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

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

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

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

Если сбой длится дольше пяти минут, разумнее honestly перенести оставшуюся часть интервью на другое время, чем пытаться впихнуть урезанную версию задачи в оставшееся окно. Кандидат, вынужденный решать сложную задачу за 15 минут вместо 40 из-за технических проблем не по его вине, получает несправедливо заниженную оценку.

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

Вопросы для оценки софт-скиллов на техническом интервью

Технические навыки редко определяют, приживётся ли человек в команде. Софт-скиллы стоит проверять не отдельным блоком «про личное», а встроенными вопросами внутри технической части интервью.

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

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

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

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

Этичность и легальность процесса технического интервью

Технический процесс найма затрагивает персональные данные кандидата, и это накладывает конкретные обязательства на организаторов интервью, а не только на HR-отдел в целом.

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

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

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

Take-home задания заслуживают отдельного внимания: если задача предполагает использование реального кода компании или данных, замаскированных под тестовые, кандидат должен быть прямо предупреждён об этом и о том, как будут использованы результаты его работы.

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

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

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

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

— Kirill

Как Geekfactor помогает выстроить процесс технического интервью

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

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

Источники

Для тех, кто хочет разобрать методологию детальнее: Google re:Work даёт научную базу под структурированное интервью, Tech Interview Handbook — готовые примеры рубрик, а материал Appliqu полезен при составлении банка follow-up вопросов.

Часто задаваемые вопросы

Сколько должно длиться техническое интервью?

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

Нужно ли давать take-home задание всем кандидатам?

Нет, take-home стоит использовать выборочно: когда живой формат неудобен по часовым поясам или когда роль требует самостоятельной проработки без давления времени. Ограничивайте задание двумя тремя часами работы.

Как оценивать кандидата без личной предвзятости?

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

Что делать, если интервьюеры сильно расходятся в оценках?

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

Через сколько дней нужно давать обратную связь кандидату?

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

Можно ли доверить проведение технического интервью внешнему провайдеру?

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

Рекомендуемые