Брать или не брать? или Как собеседовать разработчика
– мне заявляли, что я не мог придумать те решения, которые я даю, и что я где-то видел их раньше (А слабо придумать задачу с нуля, чтобы не было таких опасений?);
– над моим резюме смеялись (Теперь мне это кажется смешным.);
– мне говорили, что я слишком много общаюсь с американцами и что я говорю по-русски с акцентом (Really?!).
Это всё мелочи жизни, но для интровертов, которых в IT много, такие случаи могут быть очень травмирующими (см. историю «Про то, как шесть проектов собеседовали Машеньку »).
В общем, первое что вы должны сделать – это показать кандидату, что вы вменяемы и что вы с кандидатом находитесь на равных в переговорном процессе. Выполнив вторую задачу, вы автоматически выполните первую, поэтому сконцентрируемся на ней.
Скоро мы будем бомбардировать кандидата вопросами, поэтому логично и честно начать с того, что мы дадим ему какую-то информацию. Как минимум, нужно представиться, сказать, сколько времени будет занимать интервью, и примерно описать круг вопросов, которые вы будете задавать. Например, сказать, что не все вопросы будут чисто техническими и что придётся решить пару практических задач.
Вы, скорее всего, будете первым человеком, который реально может рассказать о проекте, об используемых технологиях и о том, кого вы именно ищете. Так и расскажите об этом! Ответьте на какие-то начальные вопросы, которые могли появиться у кандидата, и пообещайте, что после интервью вы ответите на все вопросы, которые к тому времени накопятся.
Вы потратите 10 минут вашего времени, но зато докажете кандидату, что вы не только будете спрашивать его, что вы готовы общаться на равных. Кроме того, вы берёте на себя первую, самую тяжёлую часть разговора. Кандидату теперь гораздо комфортней отвечать на ваши вопросы. Он уже послушал вас, попривык к вам, успокоился.
А вы зато задаёте тон разговора. Вы можете быть подчёркнуто формальным или наоборот шутить, показывая, что серьёзный разговор всё равно может быть развлечением. Главное в этой части быть открытым.
Конечно, вы можете быть связаны различными соглашениями о конфиденциальности, но кандидат должен чувствовать вашу готовность рассказать всё, что вы можете. Потому что это именно то, что вы со своей стороны хотите от него.
Следующим пунктом хорошо задать вопрос, который а) потребовал бы развёрнутого ответа (так как в дальнейшем нам нужны развёрнутые ответы) и б) был лёгким для кандидата (чтобы не ставить его в тупик с самого начала). Я прошу: «Расскажите, пожалуйста, про ваш опыт работы». Можно аналогично спросить про текущий проект. Или про опыт работы с какой-то конкретной технологией. Или про хобби, если оно зацепило ваш взгляд в резюме.
Как результат после примерно 15 минут разговора у вас установлен контакт с кандидатом, кандидат готов не просто отвечать на вопросы, но и разговаривать, и вы можете переходить к основной части интервью. Время, потраченное в начале интервью, окупится сторицей, когда вам потребуется получать прямые ответы на неудобные вопросы.
1.5 Резюме и самооценка
Резюме является самым главным источником начальной информации о кандидате. Но в целом резюме разработчиков ужасны. Мало людей умеют составлять резюме, а кадровый голод позволяет кандидатам и не учиться это делать. Как квинтэссенция у меня сейчас значится резюме разработчика, из которого я не смог понять, на каком языке программирования он пишет. То есть очень часто бывает, что указано несколько языков (Java, Python, R, …), но непонятно, насколько каждый из языков знаком. Но в том резюме вообще ни одного языка указано не было, хотя и заявлялось 7 лет опыта разработки.
Хорошее решение я видел в компании Luxoft. Там рекрутёры высылают кандидатам стандартный шаблон резюме и просят его заполнить. А в этом шаблоне, кроме прочего, есть табличка со списком основных языков программирования и технологий. Кандидат для каждой строчки должен заполнить уровень владения соответствующей технологией от 0 (ничего не знаю) до 5 (эксперт). Такая табличка стирает индивидуальные особенности кандидатов, что для собеседования, конечно, плохо. Зато появляется уверенность, что минимальная необходимая информация будет доступна до интервью.
Так вот, в процессе многолетней работы с такими резюме стала видна одна закономерность. Если в резюме много оценок 4 и 5 (от продвинутых знаний до уровня эксперта), то скорее всего кандидат имеет уровень junior’а.
Действительно опытные эксперты обычно гораздо более скромны в оценке своих знаний. Пятёрки они ставят всего в нескольких строчках, для технологий, с которыми они работали десяток лет, или по которым они защитили кандидатскую.
Для ряда технологий стоят четвёрки. Это там, где у них просто многие годы опыта, но недостаточно, чтобы они стали экспертами мирового уровня. И ещё кучка технологий, которые оценены в 3 и меньше. Опытный человек всегда имеет широкие познания в смежных областях.
Причём, многие простые технологии опытные разработчики просто не указывают, считая их само собой разумеющимися. Вот и получается, что если смотреть только оценки, то действительно опытные эксперты выглядят какими-то троечниками.
В психологии это называется эффектом Даннинга—Крюгера и качественно изображается следующим графиком:
Рис. 1.1: Эффект Даннинга—Крюгера
Профи всегда знает, насколько велика область за пределами его знаний и рассуждает примерно так: «За знание языка C++ я только 4 могу себе поставить. Конечно спецификации C++ v.11 и C++ v.14 я знаю очень хорошо, но с теорией компиляторов я не очень дружу и не могу иногда объяснить, почему создатели языка приняли то или иное решение. Вот Вася – тот точно эксперт. Он на международных конференциях по этой теме выступает. Я не так крут, как Вася. Блин. Может даже 3 надо поставить».
Новичок рассуждает примерно так: «Знание языка C++ у меня точно на пятёрку. Я же знаю все операторы циклов: и for, и while, и даже этот странный do..while. И даже зачёт по C++ сдал, хотя и с трудом. Препод, зверь, валил по-страшному».
В процессе работы неоднократно кто-то из команды прокачивался в какой-то технологии и шёл исправлять в своём резюме оценку 5 на 4. Так что если вы видите очень скромное описание основных навыков, то не стоит отбрасывать такого кандидата. Наш менталитет поощряет занижение собственных достижений. Возможно кандидат просто очень скромный.
Собеседуя кандидатов, нужно этот момент учитывать. Если разработчик говорит, что какую-то технологию он знает не очень, то это может означать, что он просто никак докторскую по этой теме закончить не может.
Новички же сильно переоценивают свои знания. Вместо общих вопросов об уровне владения технологиями, лучше задавать конкретные: Был ли опыт использования этой конкретной технологии в реальном проекте? Какие сложности встречались и как они были преодолены? Чем нравится и чем не нравится эта технология?
1.6 Структура собеседования
Интервью – это не просто куча вопросов, которые вы накидываете кандидату. В каждый момент собеседования вы должны понимать что и для чего вы делаете. Поэтому давайте рассмотрим условные «типы» интервью, то есть типы вопросов, которые вы задаёте. Я называю их условными, потому что реальное интервью обычно содержит кусочки разных типов.
HR интервью.
Обычно проводится сотрудником HR отдела. Это короткое интервью, на котором оценивается общий уровень адекватности кандидата, проверяется заинтересованность кандидата в работе, определяется формат дальнейшего общения. Здесь, как и во всех других интервью, не только у кандидата спрашивают что-то, но кандидату даётся информация. Кандидату рассказывают о компании, о процессе собеседования, о том, что его ждёт дальше и чем всё это закончится.
Не стоит считать, что для кандидата всё очевидно. Собеседования в разные компании очень различаются и кандидат (особенно неопытный) может быть сильно удивлён, что ему сразу не сказали уровень зарплаты или что собеседования нужно будет проходить на английском и в вечернее время. Многие компании делают памятку (в напечатанном виде или на сайте), которая отвечает на основные вопросы. Если такой памятки нет, то, возможно, вам придётся самому ответить на вопросы, относящиеся к HR.
Техническое интервью.
Обычно, именно эта часть считается «настоящим» собеседованием. Не только технари, но, что удивительно, и управленцы считают оценку технических знаний единственно важной частью собеседования. Причина этого заблуждения проста: абсолютное большинство компаний не имеют людей с нужными навыками для оценки чего-то кроме технических навыков.
Техническое интервью часто совсем «не похоже» на интервью. Это может быть тест, тестовый проект, решение задач на кодирование или предоставление кода, написанного в прошлом. Есть много инструментов, которые могут помочь в оценке технических знаний кандидата. Но беседа живого эксперта с кандидатом не может быть заменена всеми этими вспомогательными средствами.
Кстати, английский язык – это тоже технический навык, и его оценка мало чем отличается от оценки умения писать на Java. Равно как, если вы собеседуете менеджера, то умение применить Scrum тоже относится к навыкам техническим.
Техническому интервью разработчиков посвящён следующий раздел этой книги.
Менеджерское интервью.
Я называю его менеджерским потому, что обычно его проводит нанимающий менеджер. Но его вполне может проводить и технический специалист, если его квалификация позволяет это.
Этот тип интервью предназначен для исследования личности кандидата. Собеседующий должен понять, насколько кандидат впишется в текущую команду, какие проблемы будут с ним, как можно использовать его сильные стороны. Высокий технический уровень кандидата совсем не означает, что он будет отличным работником в вашей компании. И на практике я часто видел, как прекрасный, но неправильно нанятый технический специалист, приносил гораздо больше вреда, чем пользы.
Менеджерскому интервью также посвящён целый раздел этой книги.
Офер.
Собственно предложение работы кандидату, которое также часто выливается в отдельное интервью. Более детально описано в главе 4.1 «Офер».
Не нужно путать тип интервью с целями интервью. Например, цель «Оставить хорошее впечатление о компании» должна быть частью любого интервью. Неправильно думать, что если вы оцениваете технический уровень кандидата, то достаточно сконцентрироваться на этом и не обращать внимание ни на что другое. Часто кандидат принимает решение о принятии офера, основываясь на уровне технического собеседования.
Также технический специалист не может игнорировать «менеджерскую» часть интервью. В итоге этот кандидат придёт в вашу команду, и вам придётся с ним работать. Эта работа может быть счастьем или мучением, и в ваших интересах узнать кандидата получше.
На практике примерно 20% времени технического интервью я трачу на «менеджерские» вопросы. Как кандидат относится к используемым в вашем проекте технологиям? Сможет ли кандидат изучить новые технологии? Будет ли он прислушиваться к вашим замечаниям по его коду? Все эти вопросы нужно выяснить.
Даже часть, относящаяся к оферу, не может быть полностью проигнорирована на техническим интервью. Например, если вы видите явный пробел в знаниях кандидата, который будет ему мешать, нужно это сказать ему (аккуратно) и получить подтверждение от кандидата, что он ликвидирует этот пробел в будущем.
Это может выглядеть вот так: «Я вижу, что вы имеете мало опыта в работе с многопоточностью. Наш проект требует хороших знаний в этой области. Если вы будете работать с нами, то вам придётся работать с многопоточностью постоянно. Готовы ли вы к этому? Как вы думаете, сможете ли вы в течение пары месяцев прокачаться в этой области? Как вы это сделаете?» Если кандидат примет офер, он должен хорошо понимать, на что он подписывается.
Если говорить конкретно о распределении времени, то для часового технического интервью я рекомендую начать с короткого рассказа о себе, проекте и компании (HR часть). Следующие полчаса лучше посвятить основной части интервью, техническим вопросам. После технических вопросов пятнадцать минут надо уделить вопросам менеджерским. И это оставит десять минут на вопросы кандидата, что будет продолжением HR части.
Если вы руководитель, то логичнее, наоборот, менеджерскую часть делать полчаса, а техническую – 15 минут, но порядок лучше оставить прежним: сперва техническая часть, потом менеджерская. Технические вопросы привычней для кандидата, вызывают меньше напряжения и являются подготовкой для менеджерской части.
Таким образом, типовая структура интервью следующая: Знакомство → Технические вопросы → Менеджерские вопросы → Ответ на вопросы кандидата
Очень важно отслеживать время, чтобы успеть всё. Затянувшееся знакомство с интересным кандидатом может не оставить времени в конце интервью на ответы на вопросы, а это неприемлемо. Обычно я выкладываю перед собой свои наручные часы, чтобы точно знать, успеваю ли я обсудить все вопросы.
Если какой-то вопрос отнимает больше времени, чем было задумано, то имеет смысл просто перейти к следующему. Иногда у вас и у кандидата есть время, чтобы провести интервью дольше запланированого, но часто вы оба подчиняетесь жёсткому графику, и такой возможности нет.
Глава 2 Техническое собеседование
Область IT состоит из технарей, и задачи перед ними стоят очень технические. Именно поэтому у нас настолько высоко ценятся эксперты, и именно поэтому компании прикладывают столь значительные усилия, чтобы оценить технический уровень кандидатов.
Конкретные вопросы на техническом интервью очень сильно зависят от используемых в проекте технологий, языка программирования и философии разработки, принятой в компании. Конечно, собеседование разработчика C++ для встраиваимых криптографических решений очень сильно отличается от собеседования разработчика приложений для анализа данных на языке R. Но принципы остаются одинаковыми.
В этой главе мы поговорим об этих принципах и рассмотрим примеры конкретных задач, которые я использую на собеседованиях.
2.1 Открытые вопросы
Обычно, для оценки технического уровня кандидату задают по списку очень узкие вопросы: «Когда вызываются статические конструкторы в C#?», или «Реализацией какого шаблона проектирования являются события?», или «Тип DateTime передаётся по ссылке или по значению?» Но этот подход не становится решением, а ведёт к появлению целого набора других проблем.
Если вопросы достаточно сложные, то кандидат может легко забыть конкретный ответ на конкретный вопрос. Ведь в условиях стресса на собеседовании мы легко можем забыть детали спецификации языка, правда? Поэтому приходится добавлять много вопросов на одну и ту же тему. Такое тестирование начинает отнимать всё больше времени, а результаты становятся всё менее и менее относящимися к реальной работе.
Самая же главная проблема такого подхода – кандидат замыкнётся, так как бомбардировка человека вопросами совсем не помогает наладить контакт. И кандидат быстро устанет от бессмысленных вопросов и сочтёт ваш подход непрофессиональным. И будет прав.
Но ведь любой разработчик определенно может сказать, насколько крут его собеседник после короткого разговора. Вы, возможно, сами не раз это видели в кулуарных разговорах на конференциях. Когда встречается эксперт, то уже через несколько минут становится очевидно, что он эксперт. Как же повторить этот трюк в условиях собеседования? Как сделать его управляемым?
Решением является отказ от списка узких вопросов в пользу беседы на технические темы. Собеседование должно проводиться в формате разговора. При этом не нужно спрашивать отдельные факты, а нужно оценивать зрелость кандидата и уровень в целом, исходя из того, насколько свободно он себя чувствует в разных областях. Для этого необходимо задавать довольно общие вопросы и получать от кандидата развёрнутые ответы.
Возвращаясь к примеру с кулуарными разговорами на конференции, можно заметить, что вряд ли кто-то когда-нибудь произвёл впечатление, вспомнив полный список параметров стандартной функции или перечислив все известные способы запуска отдельного потока вычислений. Но часто эксперт показывает свой уровень, выразив мнение о ближайшем будущем какой-то технологии или рассказав, как он сумел решить какую-то проблему в проекте. Поэтому в собеседовании стоит придерживаться открытых вопросов, не подразумевающих конкретные ответы, а подталкивающих кандидата к обсуждению какой-то темы.
Вот несколько примеров таких открытых вопросов:
– Какая самая серьёзная проблема вам встречалась в ваших проектах?
– Что бы вы хотели изучить в ближайшее время?
– Если бы вам достался на поддержку большой старый продукт с большим количеством кривого кода, то как бы вы стали исправлять в нём баги?
– Какие проекты вам нравятся больше всего?
– Какие технологии из тех, с которыми вы работали, вы считаете самыми бесполезными?
С этим подходом есть одна проблема. Несмотря на то, что кандидаты с презрением относятся к обычным «протокольным» вопросам типа «назовите точный тип первого параметра функции scanf()», открытые вопросы многих из них ставят в тупик. Такие вопросы кажутся слишком общими, не имеющими точного ответа, спорными. Многие разработчики с подозрением к ним относятся и молчат.
Разговорить кандидата и объяснить, что вы хотите услышать – это ваша задача. Например, вы решили поговорить о шаблонах проектирования. И задали несложный вопрос: «Какие проблемы с использованием шаблонов проектирования вы знаете или встречали на практике?» В ответ вполне реально получить не длинный ответ, а напряжённую тишину. И если вам кажется, что кандидат смотрит на вас непонимающим взглядом не потому, что он действительно не знает проблем шаблонов проектирования, а потому, что он не понимает, чего вы от него ждёте, то попробуйте задавать вопросы более развёрнуто, переформулируйте вопрос, приведите пример ответа или сделайте всё это разом.
Например, так: «Да, я понимаю, что мой вопрос слишком общий. Просто не бывает плюсов без минусов. Любая технология имеет какую-то цену и применима не везде. Многие книги рассказывают нам, что шаблоны проектирования – это классная штука, и это правда. Но мне хочется поговорить о проблемах, которые они рождают. Ведь всегда есть проблемы. Например, шаблоны надо учить и тратить на это время. В канонических книгах перечислены десятки шаблонов, а в одном проекте применяется ничтожный процент из них. То есть время, потраченное на изучение многих шаблонов потрачено зря. Может быть вы знаете ещё какие-то минусы шаблонов проектирования, которые мы могли бы обсудить?»
Такой развёрнутый вопрос стимулирует кандидата дать развёрнутый ответ. Кандидат может поспорить с вами и сказать, что даже если шаблон не применяется, то время, ушедшее на его изучение, всё равно нельзя назвать потраченным впустую, что изучение шаблонов развивает разработчика (назвав таким образом ещё один плюс). Или поговорить о том, что шаблоны проектирования учат структуре мышления, и у разработчика любая программа состоит из шаблонов проектирования, реализация которых задаёт некоторый доменно-ориентированный язык, на котором написана бизнес-логика приложения.
2.2 Уровни знания
Беседуя с разработчиками на разные темы я заметил, что уровень зрелости разработчика можно определить по набору тем, на которые он может вести беседу. Есть базовые знания, которые доступны разработчикам даже с небольшим опытом, а есть действительно сложные области, в которых разбирается только эксперт. Иерархия тем показана на рисунке 2.1.
Рис. 2.1: Уровни знания по технологии
Давайте рассмотрим какую-нибудь область, например, юнит-тесты и разложим знания разработчика в соответствии с этой иерархией:
Определения.
Сюда можно включить базовые понятия, которые получает junior-разработчик в самом начале изучения: «Что такое юнит-тест?», «Что такое тест-метод?», «Какие фреймворки для юнит-тестирования бывают?» Обычно не стоит тратить время на задавание этих вопросов. Если кандидат не знает ответы на них, то это скоро станет и так очевидно, а правильные ответы не скажут о разработчике ровным счётом ничего.
Плюсы.
Что дают нам юнит-тесты? Зачем мы их вообще используем? Ответы на эти вопросы даются в любой книге по юнит-тестам. Разработчик должен знать ответы на них, чтобы применять юнит-тесты осмысленно:
Они позволяют проводить автоматическое регресионное тестирование;
Без них трудно делать функциональное тестирование для многих программ (например, реализация какой-то библиотеки на C++);
Они являются своеобразной документацией (особенно, если они содержат комментарии).
Минусы.
О чём не пишут ни в каких книгах, так это о минусах технологий и подходов[3]. Но ведь каждый разработчик много раз сталкивался с проблемами новых прекрасных технологий. Managed code. Многопоточность. Микросервисная архитектура. NoSQL. Шкура опытных разработчиков покрыта шрамами, каждый из которых подписан этими названиями. Знание минусов – это то, что отличает матёрого разработчика от оптимистично настроенного новичка.
Например, для юнит-тестов:
Написание юнит-тестов требует много времени. А их поддержание требует времени ещё больше;
Стопроцентное покрытие юнит-тестами часто невозможно. Для бизнес-логики юнит-тесты хороши, но если много UI и взаимодействия со сторонними системами, то юнит-тесты могут быть почти бесполезны;
Запуск юнит-тестов требует времени, которое добавляется к каждому билду. Иногда это время становится недопустимо большим.
Философия.
Когда разработчик начинает понимать взаимосвязь между разными технологиями, их место в процессе разработки и своё место в этом процессе, он выходит на уровень философии. На этом уровне кандидат может рассказать, почему юнит-тесты стали неотъемлемой частью процесса разработки, как они связаны с Continuous Integration и Continuous Deployment, как можно снизить затраты на их создание и как можно доказать заказчику, что они нужны.
В своих собеседованиях я обычно в каждой теме пробегаюсь по уровням, игнорируя самый базовый уровень определений. Я открываю обсуждение вопросом: «Зачем нужна эта технология?» Если кандидат даёт чёткий и развёрнутый ответ, то следующим пунктом спрашиваю: «А какие проблемы есть с использованием этой технологии?» Очень опытные кандидаты часто, отвечая на эти открытые вопросы, сами выходят на уровень философских рассуждений, но им можно помочь, задав вопрос: «А как вы сами относитесь к этой технологии?» Похожий подход нужно по порядку применить ко всем областям, которые вы хотите обсудить. Я это называю «сканированием знаний» кандидата.
Не стоит ограничиваться только философскими вопросами. Разработчик может иметь высокий общий уровень, что даст ему возможность хорошо отвечать на высокоуровневые вопросы, но «плавать» в относительно простых темах. Однако же если разработчик быстро назвал основные плюсы технологии, основные минусы и описал, как эта технология вписывается в современный подход к разработке, то уровень его в этой технологии высок. Он мог пропустить что-то из-за невнимательности, или стресса, или своих убеждений, но даже если вы промучаете его ещё полчаса дополнительными хитрыми вопросами, то оценка уровня не изменится. Вы можете уточнить у кандидата, почему он не назвал что-то, но только если вы считаете пропущенное действительно очень важным.
Если вам нужно очень быстро (например, за 20 минут) прособеседовать мощного архитектора, то вполне достаточно задать один развёрнутый философский вопрос. Например: «Как современные практики и подходы к разработке позволяют разрабатывать код быстро и качественно?» Ответ, скорее всего, позволит вам определить уровень кандидата в целом. Хотя, конечно, будет лишён детальности.
Про то, как шесть проектов собеседовали Машеньку
Рекрутёры нашли новую кандидатку, Машеньку. Опыта у неё было немного, но резюме давало надежду, что она дотягивает до уровня Middle Developer, ну или хотя бы является твёрдым Junior’ом, которого можно быстро подтянуть.
Рынок кандидатов, как обычно, был почти пуст, а потребность в кандидатах была, как обычно, высокая. Поэтому новый разработчик нужен был сразу в шесть разных проектов.
