Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
Хороший интервьюер искренне интересуется другими.
1.4 Начало интервью
Итак, кандидат пришёл на интервью, вы обменялись парой приветственных слов и вам надо начинать интервью. Это очень важный момент, где вам придётся попотеть.
Самая главная проблема заключается в том, что кандидат вас опасается. Кандидат готов отвечать на ваши вопросы, но первоначальное отношение к вам, скорее всего, будет настороженное. Почему? Потому что в мире очень мало хороших интервьюеров, и кандидат знает, что все шансы за то, что интервью будет плохим.
В этом нет ничего личного. Просто в мире мало мастеров своего дела. Вспомните сколько вы видели таксистов, которые действительно могли бы считаться профессионалами своего дела. Ну или хотя бы не нарушали правила дорожного движения. Ну или хотя бы не совершали нарушения, за которые наказывают лишением прав.
Ладно-ладно, не подумайте, что я ненавижу таксистов, среди них есть отличные водители. Но можете вспомнить, например, сколько сил отнимает поиск хорошего мастера или надёжной СТО.
Проблема в том, что высокопрофессиональных людей мало. Так что кандидат совершенно справедливо подозревает, что перед ним плохой специалист. Раз вы читаете эту книгу, то вы стремитесь развиваться и к числу некомпетентных собеседователей не относитесь, но кандидат-то этого ещё не знает.
Причём кандидат находится в явно неравноправном положении. Конечно, известно, что в IT работники нужны компаниям больше, чем работникам нужна работа, но на стандартном интервью это не заметно. Обычно кандидат находится в подчинённом положении и должен отвечать на все вопросы интервьюера, который, как я уже говорил, часто просто некомпетентен.
Почти каждое интервью дарит кандидату очень неприятные сюрпризы. На моём опыте было:
– вместо собеседования мне предлагали 4 часа программировать на незнакомом мне языке (Как раз выдалась свободная неделя, на что бы её потратить?);
– мне заявляли, что я не мог придумать те решения, которые я даю, и что я где-то видел их раньше (А слабо придумать задачу с нуля, чтобы не было таких опасений?);
– над моим резюме смеялись (Теперь мне это кажется смешным.);
– мне говорили, что я слишком много общаюсь с американцами и что я говорю по-русски с акцентом (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. Так что если вы видите очень скромное описание основных навыков, то не стоит отбрасывать такого кандидата. Наш менталитет поощряет занижение собственных достижений. Возможно кандидат просто очень скромный.
Собеседуя кандидатов, нужно этот момент учитывать. Если разработчик говорит, что какую-то технологию он знает не очень, то это может означать, что он просто никак докторскую по этой теме закончить не может.
Новички же сильно переоценивают свои знания. Вместо общих вопросов об уровне владения технологиями, лучше задавать конкретные: Был ли опыт использования этой конкретной технологии в реальном проекте? Какие сложности встречались и как они были преодолены? Чем нравится и чем не нравится эта технология?
