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

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

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

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

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

Погружённость в проект

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

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

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

Софт-скиллы

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

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

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

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

Можно, конечно, возразить, ссылаясь на Стива Джобса или Марка Цукерберга, которые стали успешными до завершения ВУЗов. Но вспомните всех своих сокурсников, которых выгнали из универа, много ли среди них Цукербергов? Итак, следующий плюс в софт-скиллах – это вышка.

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

Еще важный вопрос - причина увольнения с последнего места работы. Едва ли кто-то искренне признается, что его попросили уволиться, потому что не справлялся с работой. Но если в результате дискуссии на эту тему всплывут противоречивые факты, то пусть это будет для вас триггером. Можно провести расследование, к примеру, связаться с бывшим руководителем или его коллегами, или даже бывшими клиентами. Кстати, просить номер предыдущего руководителя – вполне нормальная практика.

Хард-скиллы

А вот и самое главное. Давайте смотреть по пунктам:

1. Четко определите навыки, которые нужны для вашего проекта или понадобятся в ближайшее время

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

Безусловно, опыт работы в смежных технологиях можно засчитывать в плюс. Например, если человек 6 лет работал на PostgeSQL, то для него не составит большого труда перейти на Oracel. Но если человек никогда не работал с БД мы не можем быть уверены, что он быстро в ней разберется. Более того, в технологиях много моментов, понимание которых приходит только с опытом. Скорей всего, в течении длительного времени, кандидат будет совершать неизбежные для новичка ошибки.

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

2. Как проверить компетенцию в заявленных скиллах?

На мой взгляд неэффективно проводить собеседование в виде школьного экзамена «вопрос – ответ». В такой методике есть вероятность того, что кандидат просто знает ответ на вопрос, но не понимает саму суть проблемы. К примеру (сейчас речь пойдет о Java) я часто спрашиваю у кандидатов что нужно сделать с объектом, чтобы использовать его в качестве ключа в HashTable. Многие говорят переопределить hashCode и equals. На вопрос «почему» многие скажут, потому что у них есть контракт. Но вот куда более интересный вопрос – это как сделать так, чтобы метод HashMap.get начал работать с линейной сложностью. Вообще намного эффективнее проводить интерактивное собеседование. Чтобы убедиться, что кандидат реально понимает, как все устроено, помогут наводящие вопросы.

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

Но вместе с тем, слишком сильно облегчать задачу не надо. Изначально вопрос я советую задавать сложным языком. Если кандидат не понимает, о чем речь, то разъясните. Если понял сложную терминологию, то это демонстрирует его эрудированность и дает право полагать, что он читает литературу по теме. К примеру (сейчас речь пойдет о JavaScript) можно спросить: «Как ты думаешь почему стейты должны быть иммутабельные?» если кандидат отвечает на этот вопрос, то это микроплюсик за сложность. Если не понимает вопрос, то его непременно нужно перефразировать.

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

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

Многие скажут добавить поле user_id в таблицу car, но некоторые сразу предложат создать связующую таблицу так как после добавления поля user_id мы нарушаем одну из форм нормализации БД, создавая в таблице поле, которое не определяет уникальность строки. Далее эту задачу можно усложнять, попросить сохранять историю смены владельцев, спросить, как осуществлять поиск по модели автомобиля, если в таблице 2-4 млн. записей, а если 20. Всегда спрашивайте, почему кандидат пришел к такому выводу. Даже если он дал такое очевидное решение, как добавление поля user_id, обязательно спросите почему так. Есть вероятность, что он не сможет ответить и лично для меня это будет минусом. Обсуждая задачи, вы можете легко лавировать внутри этой темы охватывая много аспектов.

В какой-то момент для нас стало важным, чтобы у кандидата был опыт проектирования REST-контроллеров. Мы проверяли это не сложной задачкой: «Вам нужно спроектировать API которое будет принимать ФИО и возвращать адрес». Больше не даем никаких вводных, ожидаем от кандидата решения: какой метод нужно имплементировать что возвращать, какие могут быть ошибки. Эта задачка выглядит просто, но дьявол кроется в деталях, не все кандидаты говорят, что метод будет возвращать массив адресов, потому что в мире много полных тёзок. Далеко не все задаются вопросом приватности персональных данных: а что делать если мы нашли два адреса по одному ФИО? Мы теперь точно знаем, что один из этих адресов принадлежит другому человеку, можем ли мы показать эту связку?

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

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

3. Алгоритмическая секция

Если речь идет о программисте, то его способность решать алгоритмические задачи безусловно является огромным плюсом, но это не определяет его как специалиста, в котором нуждается ваш проект. Способность хорошо решать алгоритмы – это не божья благодать, а результат изучения. К примеру, если вы никогда не изучали алгоритм knapsack 01 или другие алгоритмы DP то мало вероятно, что вы сможете решить эту задачу.

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

Важно понимать, что, если кандидат легко решил алгоритмическую задачу на собеседовании – это говорит о том, что он решал подобную задачу и еще не забыл это. Конечно, люди, которые с лёгкостью грокают алгоритмы, впечатляют, но проверка этих навыков требует своего дополнительного часа, а значит минус 70-80 минут вашего времени. Умножьте эти цифры на количество кандидатов и на количество специалистов, которые вам нужно собеседовать в год, и вы получите годовые затраты на определения этого навыка.

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

4. Обязательно поинтересуйтесь читает ли ваш кандидат профессиональную литературу

Многие люди не читают книги ссылаясь на то, что есть другие источники данных. Это однозначно так, но, думаю, не стоит здесь раскрывать тему того, почему важно читать профессиональные книги. Если кандидат не читает книги - это однозначный минус.

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

P.S.

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