Как сделать технические интервью предсказуемее: опыт внутренней школы Островка

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

Для кандидата это один этап. Для компании — процесс, который может меняться от встречи к встрече.

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

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

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

---

Привет, Хабр! Я Павел Шлюпкин, Recruitment Team Lead в Островке. Вместе с командой занимаюсь наймом по направлениям DevOps, 1C, Frontend, QA и Product Design.

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

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

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

• как они готовятся к встрече;

• на что опираются при оценке;

• как фиксируют ответы;

• какой фидбек оставляют после интервью. 

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

Почему одного опыта оказалось мало 

Летом 2024 года мы разбирали технические интервью во фронтенд-направлении и увидели заметный разброс внутри одного процесса. У одних интервьюеров встреча была жёстче структурирована, у других многое зависело от хода разговора. Кто-то глубже проверял практический опыт, кто-то сильнее смотрел на теорию и ожидаемый грейд. 

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

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

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

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

Что показал кастдев внутри компании

Мы опросили 12 сотрудников, которые уже проводят интервью — представителей Backend, Frontend, Data/ETL, QA, UX, Product и Project Management.

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

На верхнем уровне всё выглядело похоже. Почти у всех интервью было примерно одно и то же «тело»: знакомство, рассказ о себе и компании, вопросы об опыте кандидата, проверка hard и soft skills, ответы на вопросы кандидата.

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

Например:

• что делать, если кандидат ведёт себя странно, нервничает, резко отвечает, токсично шутит или нарушает деловой формат;

• как проверять навык, если сам интервьюер не чувствует себя в нём достаточно уверенно;

• можно ли завершить интервью через 20–30 минут, если уже понятно, что кандидат не проходит по базовым требованиям;

• как поставить no hire спорному кандидату и не превратить фидбек в набор субъективных впечатлений;

• как фиксировать ответы: писать цитаты, общие выводы, баллы, грейд, сильные и слабые стороны;

• кто и как должен обучать новых интервьюеров.

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

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

Выбираем подходящий формат

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

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

В июле 2024 года стартовал кастдев, а в сентябре мы перешли к составлению программы школы. До августа 2025-го программу дорабатывали; в сентябре запустили первые группы. 

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

Как мы собирали программу 

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

Программу построили вокруг трёх больших этапов:

• что происходит до интервью;

• что происходит во время интервью;

• что происходит после интервью.

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

1. До интервью: подготовка, резюме и матрица компетенций

Первый образовательный блок был посвящен подготовке.

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

Например:

• есть ли в опыте кандидата технологии или навыки, критичные для роли;

• где по резюме видно сильные зоны, а где возможны пробелы;

• какие вопросы уже могли быть закрыты на HR-интервью;

• нет ли конфликта интересов, если интервьюер лично знаком с кандидатом;

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

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

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

Следующий блок обучения — матрица компетенций.

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

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

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

2. Во время интервью: структура, вопросы и спорные ситуации

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

Предлагали примерно такую логику:

• короткое знакомство и small talk;

• рассказ интервьюера о себе, команде и компании;

• план встречи;

• вопросы по опыту кандидата;

• технический блок: теория, практика или разбор кейсов;

• вопросы кандидата;

• завершение и ожидания по дальнейшим шагам.

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

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

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

После теории участники придумывали вопросы под заданные навыки и пробовали формулировать их в формате поведенческого интервью. Многие спорные места становятся видны только тогда, когда пытаешься написать вопрос сам. Слишком общий вопрос почти всегда приведёт к общему ответу. Слишком закрытый — к «да/нет». Хороший вопрос вытаскивает ситуацию, в которой навык действительно проявился.

Самые горячие темы оказались не про hard skills

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

Вот примеры таких сценариев: 

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

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

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

• Кандидат явно не проходит уже в первые 20–30 минут — одна из самых спорных ситуаций. Интервьюеры хорошо понимают цену своего времени: когда базовые требования не закрыты, продолжать встречу ещё сорок минут кажется странным. Но есть и другая сторона — кандидатский опыт и уважение к человеку, который выделил время и пришёл на интервью.

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

  Рассматривали и обратный вариант — как быть, если интервьюеру не хватает времени.

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

Интервьюер как бренд-агент

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

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

На интервью хорошо работает честный, спокойный рассказ: чем занимается команда, какие продукты развивает, какие задачи сейчас в фокусе, какие есть инженерные вызовы. В нашем случае мы говорим про travel-tech: продукты, связанные с бронированием отелей, авиа- и ж/д-билетов и другими тревел-сервисами, и наши внутренние tech-направления (разработка, аналитика, продукт).

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

• в какую команду я попаду;

• как быстро можно вырасти или перейти на другой грейд;

• есть ли техническая и менеджерская ветка развития;

• зачем нужен английский, если большая часть команды русскоязычная;

• как прошло интервью и можно ли уже понять результат.

На часть вопросов интервьюер может ответить сам. Например, рассказать, что внутри есть разные треки роста, а конкретный план зависит от команды, задач и результатов. Но есть вопросы, на которые лучше не отвечать сходу. Если собеседующий не знает ответа, стоит честно сказать об этом и предложить уточнить через рекрутера.

Собеседование в паре: два интервьюера — не значит в два раза лучше

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

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

Поэтому до собеседования нужно договориться как минимум о трёх вещах:

• кто следит за таймингом и как пушит, если разговор слишком долго стоит на одном месте;

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

• как фиксируются ответы.

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

3. После интервью начинается самая недооценённая часть

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

Здесь мы пришли к двум договорённостям: 

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

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

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

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

Подробно мы обсуждали спорные решения. В реальном найме не каждый кандидат укладывается в уверенное hire или no hire. Бывает, что сильные стороны есть, сомнения тоже есть, а часть навыков осталась непроверенной. В таком случае maybe — нормальный результат, если интервьюер подробно объясняет, почему решение спорное и что стоит проверить дальше.

С no hire тоже важно быть точным. Кандидат может не подходить конкретной команде или конкретной роли, и это один тип решения. Если на интервью появились серьёзные «красные флаги», это уже другая история. Такие случаи нужно описывать отдельно и через факты: что произошло, в какой момент, как это повлияло на интервью.

Та же логика работает с грейдом. Если команда искала senior, а по результатам интервью видит middle+, должно быть понятно, по каким именно вопросам и компетенциям сделан этот вывод. 

Ключевая часть фидбека — наблюдения. Ярлыки вроде «неуверенный» или «странно себя вёл» легко считываются по-разному. Лучше описывать конкретное поведение.

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

Что изменилось после запусков

На момент свежей внутренней презентации обучение прошли уже 7 групп: 25 тимлидов и 60 рядовых сотрудников. После одного анонса появился лист ожидания примерно на 30 человек — ещё около трёх групп. Это хороший сигнал: запрос на калибровку интервьюеров оказался не только у рекрутмента.

Средняя оценка курса — 8,9 из 10. 70% участников отметили, что получили много новой информации, а 90% подтвердили, что двухдневный формат обучения им подходит.

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

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

Что подтвердили первые потоки

Несколько тезисов, в которых мы ещё раз убедились благодаря школе — и которым после первых потоков стали уделять больше внимания:

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

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

3. Матрица компетенций даёт общий язык для оценки. Чтобы не спорить на уровне «мне кажется, он middle» — «а мне кажется, senior», а раскладывать оценку по навыкам.

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

5. Фидбек — часть интервью, не послесловие. Можно провести отличную встречу, но если потом оставить в системе две строки «норм, двигаем», ценность этапа резко падает.

Отдельно я сделал несколько выводов о разработке самой школы:

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

• Если бы мы начинали заново, я бы быстрее шёл в MVP: собрал минимальную рабочую версию, провёл пилот и доращивал программу уже после обратной связи от участников. Ещё раньше стоило расширить рабочую группу и подключить T&D за методической поддержкой. 

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

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

Школа как постоянная часть найма

Мы не считаем, что школа интервьюеров закрыла все проблемы технического этапа. В интервью всё равно останутся спорные решения и кандидаты, по которым нет однозначного вывода. Но у нас появилась общая основа: формат подготовки новых интервьюеров и более понятное планирование нагрузки на команды.

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

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

***

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

А на чём у вас держится качество технических интервью: на общей системе, опыте отдельных интервьюеров или постоянной калибровке между командами? И где чаще всего возникают сложности? Делитесь!

---

• TG-канал Ostrovok! Tech