Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
1.6 Структура собеседования
Интервью – это не просто куча вопросов, которые вы накидываете кандидату. В каждый момент собеседования вы должны понимать что и для чего вы делаете. Поэтому давайте рассмотрим условные «типы» интервью, то есть типы вопросов, которые вы задаёте. Я называю их условными, потому что реальное интервью обычно содержит кусочки разных типов.
HR интервью.
Обычно проводится сотрудником HR отдела. Это короткое интервью, на котором оценивается общий уровень адекватности кандидата, проверяется заинтересованность кандидата в работе, определяется формат дальнейшего общения. Здесь, как и во всех других интервью, не только у кандидата спрашивают что-то, но кандидату даётся информация. Кандидату рассказывают о компании, о процессе собеседования, о том, что его ждёт дальше и чем всё это закончится.
Не стоит считать, что для кандидата всё очевидно. Собеседования в разные компании очень различаются и кандидат (особенно неопытный) может быть сильно удивлён, что ему сразу не сказали уровень зарплаты или что собеседования нужно будет проходить на английском и в вечернее время. Многие компании делают памятку (в напечатанном виде или на сайте), которая отвечает на основные вопросы. Если такой памятки нет, то, возможно, вам придётся самому ответить на вопросы, относящиеся к HR.
Техническое интервью.
Обычно, именно эта часть считается «настоящим» собеседованием. Не только технари, но, что удивительно, и управленцы считают оценку технических знаний единственно важной частью собеседования. Причина этого заблуждения проста: абсолютное большинство компаний не имеют людей с нужными навыками для оценки чего-то кроме технических навыков.
Техническое интервью часто совсем «не похоже» на интервью. Это может быть тест, тестовый проект, решение задач на кодирование или предоставление кода, написанного в прошлом. Есть много инструментов, которые могут помочь в оценке технических знаний кандидата. Но беседа живого эксперта с кандидатом не может быть заменена всеми этими вспомогательными средствами.
Кстати, английский язык – это тоже технический навык, и его оценка мало чем отличается от оценки умения писать на Java. Равно как, если вы собеседуете менеджера, то умение применить Scrum тоже относится к навыкам техническим.
Техническому интервью разработчиков посвящён следующий раздел этой книги.
Менеджерское интервью.
Я называю его менеджерским потому, что обычно его проводит нанимающий менеджер. Но его вполне может проводить и технический специалист, если его квалификация позволяет это.
Этот тип интервью предназначен для исследования личности кандидата. Собеседующий должен понять, насколько кандидат впишется в текущую команду, какие проблемы будут с ним, как можно использовать его сильные стороны. Высокий технический уровень кандидата совсем не означает, что он будет отличным работником в вашей компании. И на практике я часто видел, как прекрасный, но неправильно нанятый технический специалист, приносил гораздо больше вреда, чем пользы.
Менеджерскому интервью также посвящён целый раздел этой книги.
Офер.
Собственно предложение работы кандидату, которое также часто выливается в отдельное интервью. Более детально описано в главе 4.1 «Офер».
Не нужно путать тип интервью с целями интервью. Например, цель «Оставить хорошее впечатление о компании» должна быть частью любого интервью. Неправильно думать, что если вы оцениваете технический уровень кандидата, то достаточно сконцентрироваться на этом и не обращать внимание ни на что другое. Часто кандидат принимает решение о принятии офера, основываясь на уровне технического собеседования.
Также технический специалист не может игнорировать «менеджерскую» часть интервью. В итоге этот кандидат придёт в вашу команду, и вам придётся с ним работать. Эта работа может быть счастьем или мучением, и в ваших интересах узнать кандидата получше.
На практике примерно 20% времени технического интервью я трачу на «менеджерские» вопросы. Как кандидат относится к используемым в вашем проекте технологиям? Сможет ли кандидат изучить новые технологии? Будет ли он прислушиваться к вашим замечаниям по его коду? Все эти вопросы нужно выяснить.
Даже часть, относящаяся к оферу, не может быть полностью проигнорирована на техническим интервью. Например, если вы видите явный пробел в знаниях кандидата, который будет ему мешать, нужно это сказать ему (аккуратно) и получить подтверждение от кандидата, что он ликвидирует этот пробел в будущем.
Это может выглядеть вот так: «Я вижу, что вы имеете мало опыта в работе с многопоточностью. Наш проект требует хороших знаний в этой области. Если вы будете работать с нами, то вам придётся работать с многопоточностью постоянно. Готовы ли вы к этому? Как вы думаете, сможете ли вы в течение пары месяцев прокачаться в этой области? Как вы это сделаете?» Если кандидат примет офер, он должен хорошо понимать, на что он подписывается.
Если говорить конкретно о распределении времени, то для часового технического интервью я рекомендую начать с короткого рассказа о себе, проекте и компании (HR часть). Следующие полчаса лучше посвятить основной части интервью, техническим вопросам. После технических вопросов пятнадцать минут надо уделить вопросам менеджерским. И это оставит десять минут на вопросы кандидата, что будет продолжением HR части.
Если вы руководитель, то логичнее, наоборот, менеджерскую часть делать полчаса, а техническую – 15 минут, но порядок лучше оставить прежним: сперва техническая часть, потом менеджерская. Технические вопросы привычней для кандидата, вызывают меньше напряжения и являются подготовкой для менеджерской части.
Таким образом, типовая структура интервью следующая: Знакомство → Технические вопросы → Менеджерские вопросы → Ответ на вопросы кандидата
Очень важно отслеживать время, чтобы успеть всё. Затянувшееся знакомство с интересным кандидатом может не оставить времени в конце интервью на ответы на вопросы, а это неприемлемо. Обычно я выкладываю перед собой свои наручные часы, чтобы точно знать, успеваю ли я обсудить все вопросы.
Если какой-то вопрос отнимает больше времени, чем было задумано, то имеет смысл просто перейти к следующему. Иногда у вас и у кандидата есть время, чтобы провести интервью дольше запланированого, но часто вы оба подчиняетесь жёсткому графику, и такой возможности нет.
Глава 2 Техническое собеседование
Область IT состоит из технарей, и задачи перед ними стоят очень технические. Именно поэтому у нас настолько высоко ценятся эксперты, и именно поэтому компании прикладывают столь значительные усилия, чтобы оценить технический уровень кандидатов.
Конкретные вопросы на техническом интервью очень сильно зависят от используемых в проекте технологий, языка программирования и философии разработки, принятой в компании. Конечно, собеседование разработчика C++ для встраиваимых криптографических решений очень сильно отличается от собеседования разработчика приложений для анализа данных на языке R. Но принципы остаются одинаковыми.
В этой главе мы поговорим об этих принципах и рассмотрим примеры конкретных задач, которые я использую на собеседованиях.
2.1 Открытые вопросы
Обычно, для оценки технического уровня кандидату задают по списку очень узкие вопросы: «Когда вызываются статические конструкторы в C#?», или «Реализацией какого шаблона проектирования являются события?», или «Тип DateTime передаётся по ссылке или по значению?» Но этот подход не становится решением, а ведёт к появлению целого набора других проблем.
Если вопросы достаточно сложные, то кандидат может легко забыть конкретный ответ на конкретный вопрос. Ведь в условиях стресса на собеседовании мы легко можем забыть детали спецификации языка, правда? Поэтому приходится добавлять много вопросов на одну и ту же тему. Такое тестирование начинает отнимать всё больше времени, а результаты становятся всё менее и менее относящимися к реальной работе.
Самая же главная проблема такого подхода – кандидат замыкнётся, так как бомбардировка человека вопросами совсем не помогает наладить контакт. И кандидат быстро устанет от бессмысленных вопросов и сочтёт ваш подход непрофессиональным. И будет прав.
Но ведь любой разработчик определенно может сказать, насколько крут его собеседник после короткого разговора. Вы, возможно, сами не раз это видели в кулуарных разговорах на конференциях. Когда встречается эксперт, то уже через несколько минут становится очевидно, что он эксперт. Как же повторить этот трюк в условиях собеседования? Как сделать его управляемым?
Решением является отказ от списка узких вопросов в пользу беседы на технические темы. Собеседование должно проводиться в формате разговора. При этом не нужно спрашивать отдельные факты, а нужно оценивать зрелость кандидата и уровень в целом, исходя из того, насколько свободно он себя чувствует в разных областях. Для этого необходимо задавать довольно общие вопросы и получать от кандидата развёрнутые ответы.
Возвращаясь к примеру с кулуарными разговорами на конференции, можно заметить, что вряд ли кто-то когда-нибудь произвёл впечатление, вспомнив полный список параметров стандартной функции или перечислив все известные способы запуска отдельного потока вычислений. Но часто эксперт показывает свой уровень, выразив мнение о ближайшем будущем какой-то технологии или рассказав, как он сумел решить какую-то проблему в проекте. Поэтому в собеседовании стоит придерживаться открытых вопросов, не подразумевающих конкретные ответы, а подталкивающих кандидата к обсуждению какой-то темы.
Вот несколько примеров таких открытых вопросов:
– Какая самая серьёзная проблема вам встречалась в ваших проектах?
– Что бы вы хотели изучить в ближайшее время?
– Если бы вам достался на поддержку большой старый продукт с большим количеством кривого кода, то как бы вы стали исправлять в нём баги?
– Какие проекты вам нравятся больше всего?
– Какие технологии из тех, с которыми вы работали, вы считаете самыми бесполезными?
С этим подходом есть одна проблема. Несмотря на то, что кандидаты с презрением относятся к обычным «протокольным» вопросам типа «назовите точный тип первого параметра функции scanf()», открытые вопросы многих из них ставят в тупик. Такие вопросы кажутся слишком общими, не имеющими точного ответа, спорными. Многие разработчики с подозрением к ним относятся и молчат.
Разговорить кандидата и объяснить, что вы хотите услышать – это ваша задача. Например, вы решили поговорить о шаблонах проектирования. И задали несложный вопрос: «Какие проблемы с использованием шаблонов проектирования вы знаете или встречали на практике?» В ответ вполне реально получить не длинный ответ, а напряжённую тишину. И если вам кажется, что кандидат смотрит на вас непонимающим взглядом не потому, что он действительно не знает проблем шаблонов проектирования, а потому, что он не понимает, чего вы от него ждёте, то попробуйте задавать вопросы более развёрнуто, переформулируйте вопрос, приведите пример ответа или сделайте всё это разом.
Например, так: «Да, я понимаю, что мой вопрос слишком общий. Просто не бывает плюсов без минусов. Любая технология имеет какую-то цену и применима не везде. Многие книги рассказывают нам, что шаблоны проектирования – это классная штука, и это правда. Но мне хочется поговорить о проблемах, которые они рождают. Ведь всегда есть проблемы. Например, шаблоны надо учить и тратить на это время. В канонических книгах перечислены десятки шаблонов, а в одном проекте применяется ничтожный процент из них. То есть время, потраченное на изучение многих шаблонов потрачено зря. Может быть вы знаете ещё какие-то минусы шаблонов проектирования, которые мы могли бы обсудить?»
