Как провести техническое интервью, чтобы оно не скатилось в бесполезную болтовню

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

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

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

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

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

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

Вот какие роли нужны, чтобы провести техническое интервью:

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

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

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

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

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

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

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

Старайтесь не задавать вопросов по темам, которые не связаны с вашими повседневными задачами. Если вы не используете Golang, то не стоит на всякий случай выяснять, знаком ли собеседник с горутинами. Избегайте стандартных и «душных» вопросов вроде «перечислите методы класса Object в Java», «назовите область видимости метода clone в классе Object».

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

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

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

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

Через 5–6 секунд он выдавал одно предложение, после небольшой паузы — второе. Чтобы проверить собеседника, я начинал задавать смежные вопросы, которые нельзя взять и загуглить. В эти моменты кандидат просто валился — было понятно, что он ничего не знает в этой области.

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

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

Вот еще факторы, на которые я обращаю внимание:

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

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

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

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

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

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

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

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

Вот как может выглядеть список материалов для профессионального развития джуна:

#hr #рекрутинг #hrm #recruiting #найм_сотрудников #подборперсонала #hrm #huntflow #itrecruitment #itrecruiter #recruitment