Всем привет! С вами снова я, Артём Харченков, руководитель разработки Crosstech Solutions Group. Ранее я рассказывал, как успешно пройти первый испытательный срок, а сегодня поделюсь опытом проведения собеседований глазами тимлида. Эта статья будет полезна как нанимающим менеджерам, так и соискателям, которые устраиваются на новую работу. 

Чтобы не быть голословным касательно своего опыта, приведу немного статистики: 

На текущий момент в компании лично я провёл больше 300 собеседований. Ещё суммарно около 100 провели мои тимлиды и другие собеседующие сотрудники. За это время в команду было нанято 35 человек, соответственно, в среднем, мы нанимаем одного из 9 приходящих на собеседования кандидатов. Дальше я подробно расскажу о подходах, которые применяю при найме специалистов в нашу команду. 

Зачем тимлид на собеседовании

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

Шаг первый. Подготовка и организация собеседования

Описание 

С этого начинается любой найм. Частая ошибка при составлении описания вакансии – это противоречащие требования. Например, когда в вакансии указывается, что нужно классно руководить командой и писать самый лучший в мире код. Тогда у кандидата возникает вопрос: «А кто в итоге вам нужен, тимлид или техлид?». 

Обычно достаточно указать 3-4 основных технологии или навыка, всё остальное – вторично.

Первичный отсев

Чтобы не тратить время на неподходящих кандидатов, вы можете сократить поток кандидатов, используя несколько приёмов. Тут может помочь рекрутер.

1. Заготовленные вопросы. Составьте 2-3 вопроса об опыте в технологиях и задачах, которые предстоит решать новому сотруднику. Попросите рекрутера задать их уже на ознакомительной беседе. Например,  вам необходим опыт работы с технологией Spring Cloud, минимальный набор модулей:  Eureka, Config Server и OpenFeign. Значит, на первом этапе рекрутер может попросить кандидата перечислить, с какими модулями тот работал. Если список совпадает с необходимым минимумом, то кандидат проходит на следующий этап. 

2. Опросник перед собеседованием. Перед собеседованием мы просим кандидата заполнить небольшую анкету, в которой он самостоятельно оценивает знания по каждой необходимой нам технологии  по шкале от 1 до 10. Это сразу даёт фундамент для сложности задаваемых вопросов, а заодно говорит о самооценке кандидата.

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

Организация собеседований. Три совета для руководителей

1. Сформируйте группы для собеседований, чтобы не выдергивать одних и тех же коллег из работы постоянно. Если у вас идёт большой набор, а на встречи ходят одни и те же сотрудники, то очень скоро они погрязнут в найме и не смогут успевать со своими задачами. Как сделали мы: создали чат на пятерых самых опытных разработчиков, которые ходили на собеседования по двое. У каждого из них не более двух собеседований в неделю – это достаточно, чтобы не сильно отвлекаться от работы, но в то же время можно провести в неделю до 10 собеседований, что в целом неплохо, ведь мы помним, что в среднем 9 собеседований = один найм. Любой рекрутер вам скажет, что закрыть вакансию в ИТ за неделю – классный результат. 

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

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

3. Закладывайте на собес не более 1,5 часов. Мы практикуем интервью в один этап, но, если мы понимаем, что не успеваем уложиться в одну встречу, назначаем вторую. Чаще всего одной встречи хватает, чтобы определить уровень специалиста. Из моего опыта второе собеседование требуется где-то в одном случае из пяти.

Шаг второй. На самом собеседовании

Первое впечатление важно

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

Есть одна вещь, которая сразу дает +20 к первому впечатлению. В начале собеседования мы всегда спрашиваем, ознакомился ли кандидат с нашим сайтом и знает ли он что-либо о компании. Этот, казалось бы, незначительный вопрос на самом деле подчёркивает важное: насколько ответственно человек подходит к выбору потенциального места работы. Если кандидат даже не прочитал о компании, в которую собирается проходить собеседование, это тревожный признак. Конечно, это не говорит о его непригодности, но, при прочих равных, сотрудники, которые осознанно выбирают вашу компанию, будут более заинтересованы и лояльны.

На что ещё обратить внимание 

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

Классно, когда кандидат рассказывает, что он самостоятельно изучал, чем интересовался, чтобы повысить свои профессиональные навыки. Это говорит о стремлении человека развиваться и об общем его интересе к ИТ-отрасли.
Особенно я люблю фрилансеров и тех, кто работал на проекте в одиночку. По моему опыту, такие сотрудники часто показывают себя более самостоятельными, а ещё они лучше понимают работу коллег смежных позиций. Дело в том, что когда человек несёт полную ответственность за проект, он сильно прокачивается в разных областях (у него другого выхода нет!). А это значит, что вы практически на 100% застрахованы от «полного провала» с его стороны. Такой специалист может не знать лучших практик и подходов к проектированию или не применять паттерны программирования, но он точно разберётся в ваших правилах и методах работы, потому что умеет добывать нужную информацию самостоятельно.

Проверка теоретической базы

Важно проверить не знание определений, а то, насколько человек знаком с технологией и понимает область её применения. Как правило, чем лучше человек ориентируется в теме, тем более простыми словами он может её объяснить.
Впрочем, не исключено, что на ответ может повлиять волнение. Для этого я рекомендую сначала задавать вопросы попроще, и потом постепенно повышать сложность, чтобы откалибровать уровень знаний кандидата. Когда мы задаем чуть более сложные вопросы, чем предполагает позиция, мы смотрим, как человек ведет себя в ситуации, когда не знает прямого ответа. Он может пытаться рассуждать и задавать дополнительные вопросы или же просто сказать, что с данной технологией не сталкивался и «опустит руки». Возможно, он вообще начнёт говорить несуразицу с умным видом, пытаясь изобразить эксперта, такие ситуации тоже случаются. Главное, не перестараться с подобными вопросами – в этом случае кандидат может потерять веру в себя или подумать, что ваши требования слишком завышены. Тут важно внимательно смотреть на реакцию собеседуемого. 

Другой момент – обращать внимание, точно ли отвечает человек на тот вопрос, который был задан. Иногда бывает так, что человек сознательно отвечает на другое, скрывая своё незнание.
Если человек указывает технологии, которые использовались в его команде, но которые он сам не трогал – это не ок. Мы ведь смотрим резюме человека, а не его команды. Такой подход ещё может быть допустим для руководителей или тимлидов, но не для программистов. Спрашивайте по всем технологиям, которые упоминаются в резюме кандидата – раз он их написал, значит он должен быть готов говорить на эту тему. По моему опыту в 50% люди пишут технологии, которые даже в глаза не видели. Например, сотрудник может указать в резюме фреймворк безопасности Spring Security. Но настраивал его при этом архитектор проекта, а он сам просто «стоял рядом». Такая проблема встречается у многих современных ИТ-специалистов. Я считаю, что за каждую технологию, указанную в резюме, человек должен пояснить ?

Лайфхак: 

Рекомендую заранее заготовить карту областей знаний, о которых вы планируете спросить кандидата. Вы можете использовать условные оценки от 1 до 5 баллов по каждому из ответов, либо просто писать комментарии текстом – это неважно. Главное, чтобы вы отразили в карте все важные для вас технологии и темы. Можете тезисно для себя пометить, что именно хотели бы спросить или что хотели бы услышать в ответ.

Пример карты областей знаний с оценками по ней:

Проверка практической базы

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

Поэтому на собеседовании мы используем код ревью в режиме онлайн – в этом случае кандидату не нужно писать код, но мы можем оценить его практические навыки. Мы показываем кандидату заранее заготовленный кусочек кода (обычно это пара классов и 1-2 функции по 20 строк), в котором он должен найти ошибки и неточности. Мы не используем особо сложные и замороченные паттерны, а приводим более-менее жизненные примеры. Ошибок мы делаем несколько типов: довольно очевидные, средние и совсем не очевидные. По количеству неточностей, которые обнаружит кандидат, можно судить о его внимательности и способности к чтению чужого кода. А это напрямую влияет на способность и скорость человека разобраться в вашем проекте и самому писать качественный код.

Кстати, если у человека есть примеры его кода в открытом доступе (обычно это только джуны, у мидлов и выше уже NDA и пет-проектов нет) — это хорошо. Можно также ознакомиться и с этими работами.

Что делать не стоит

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

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

А если собеседование проходит онлайн, как защититься от обмана?

Например, как спастись от использования кандидатом ChatGPT? ? Тут есть несколько нюансов.

1. Попробуйте самостоятельно использовать ChatGPT для проведения код ревью перед встречей. Чат выдаст ошибки в коде в определённой последовательности — скорее всего, если кандидат будет использовать ИИ, то будет отвечать в том же порядке и с примерно теми же формулировками.

2. Ещё один способ застраховаться от помощи нейронки – предоставлять код без возможности его скопировать. Например, картинкой.

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

Польза общих вопросов

Хоть я и не люблю типовые заготовленные вопросы по типу «Кем вы видите себя через 5 лет», некоторые из них могут оказаться полезными. Расскажу на примере. 

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

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

Ниже приведу список хороших общих вопросов, которые можно задать кандидату. Здорово, когда вы задаёте их ситуативно, а не просто по порядку. Например, если кандидат в рассказе о себе упомянул о каком-то рабочем конфликте, вы можете задать ему вопрос: «Кстати, а у вас были конфликты с кем-то на работе? Как они решились?»

Итак, вот список:

• Почему уволились / хотите уволиться с текущего места работы? 

• На что будете ориентироваться при принятии решения? Что важно в компании для вас? 

• Что вы считаете своими достижениями на текущем месте работы? 

• Были ли у вас конфликты с кем-то? Как они решились? 

• Что вам не нравилось в вашей последней работе? 

• Вы не знаете как выполнить задачу (мало данных, нагуглить не получается), упёрлись в тупик. Как будете действовать? 

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

• Можете ли вы описать момент, когда ваша работа была подвергнута критике? 

• Можете ли вы вспомнить задание, которое было слишком трудным для вас? Как вы решили проблему? Были ли задачи, с которыми вы не смогли справиться? 

• Можете ли вы описать свою стратегию на первые 3 месяца работы у нас? 

Список личностных вопросов:

• Почему вы выбрали эту профессию? Что вам в ней нравится, а что нет?

• Чем из того, что вы сделали в жизни вы гордитесь больше всего?

• Чем вы занимаетесь в свободное от работы время?

И список сценарных вопросов:

• Что вы будете делать, если аналитик описал требования по вашей задаче, а вы видите решение лучше?  А если аналитики не соглашаются с вами?

• Что вы будете делать, если тестирование не видит всех кейсов для вашей фичи, которые надо проверять?

• Что вы будете делать если ваша фича должна была затронуть только бэк, но затронула ещё смежные области и/или фронт?

Финал собеседования

Если по результатам собеседования кандидат вам понравился, то ваша следующая цель – заинтересовать его выбрать именно вашу компанию. Расскажите о вас максимально подробно и красочно: про команду, адаптацию в компании, процессы, бизнес-задачи. Дайте максимально допустимое NDA количество информации, посвятите рассказу о вас хотя бы 7-10 минут. Постарайтесь «продать» вакансию кандидату, ведь на собеседовании не только вы выбираете кандидата, но и кандидат вас. Тут важно подготовиться заранее, может даже подготовить презентацию. 

О чём говорить не стоит:

• упоминать legacy-код и вообще слово “legacy”. Никто не любит устаревшие технологии и спагетти-код, который нужно поддерживать. Если у вас действительно такой проект, то скажите об этом прямо. Но лучше рассказать об этом в ключе, что бывшие сотрудники на нём решали бизнес-задачи с актуальными именно на тот момент технологиями. Это будет правдой, но звучит уже не так грустно;

• говорить, что проект не особо интересен или нужен компании. Здесь без комментариев – это демотивирует;

• говорить, что проект на поддержке. Обычно это воспринимается кандидатами, как «никакого развития, только сидеть и фиксить баги». Если это так, то расскажите про бизнес-ценность, который несёт этот проект. Скажите, что именно этот проект приносит прибыль компании, за счёт которой могут развиваться другие направления.

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

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

Шаг третий. А что дальше?

В любом случае давайте обратную связь кандидату. Можно делать это через рекрутера. Делайте это, даже если ваше решение оказалось отрицательным. Хорошим тоном считается подсвечивать, чего кандидату не хватило для успешного прохождения интервью. Но, честно говоря, это уже зависит от вашего желания и свободного времени. Идеально, когда вы даёте рекомендации, что кандидату необходимо подтянуть. В этом случае у соискателя остаётся позитивное впечатление и польза от интервью при любом раскладе: либо новая работа, либо полезная обратная связь с точками для роста. Люди это ценят. Всегда есть вероятность, что через 1-2 года кандидат вернётся на повторное собеседование и пройдёт его успешно.

Ведите свой “backup talent pull”

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

Вместо итогов

Я уже несколько лет использую подходы, которые изложил выше. Конечно, бывали и ошибки: трое из 35 нанятых нами сотрудников оказались слабее, чем они показали себя на собеседовании. То есть примерно 9 из 10 нанятых кандидатов оказываются подходящими для позиций, на которые они были взяты. Считаю это хорошим результатом, и отдельно благодарен команде за эффективную систему найма.

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

Удачного найма и собеседований!

Подписывайтесь на телеграмм канал и группу ВКонтакте Crosstech Solutions Group, чтобы быть первым в курсе событий!