Мои 7 правил при собеседовании разработчиков

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

Пару недель назад меня попросили помочь на техническом собеседовании для Senior/Lead backend-разработчика и поделиться опытом. В процессе я формализовал несколько правил, которых придерживаюсь при проверке кандидатов. Чем я и хочу поделиться.

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

Содержание

Моя специализация — это Full-Stack разработка на Go (раньше Java). За последние 4 года я провёл ~150 собеседований и закрыл 12 позиций. В основном Middle / Senior backend разработчики и несколько фронтендеров (React, NextJS). Присутствовал при найме PMов, сотрудников поддержки, тестировщиков. Кстати, у меня есть канал, где я рассказываю о своей работе.

Впервые я попал на собеседование в роли собеседующего по принципу “ты же опытный разработчик, ты и собеседуй”. И я, без понимания, а как собственно-то собеседовать, пытался. Сначала гуглил вопросы по типу "ТОП-100 вопросов для Java разработчика" и пытался мучить ими кандидатов, импровизируя по ходу дела. Пытался повторять то, как меня собеседовали в разных местах. Туда же шли задачки с LeetCode, разговоры про устройство HashMap, байт-кода и другие оторванные от реальной работы вещи. Пытался докидывать специфические кейсы из своего опыта, которые в работе редко встречаются.

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

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

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

Однажды я попал на собеседование на позицию Senior Go разработчика к Ивану. Собеседование было в два звонка по часу и состояло из 5 логически разделенных блоков.

Я очень удивился, что мне не задавали вопросы про хардкорную техничку, которая не используется в работе. Не было алгоритмов. Не было ничего шаблонного, к чему я привык. Проверялись реально те навыки, которые у меня были и которые были бы полезны проекту. При этом всём — это была самая детальная проверка скиллов, которую я видел.

После собеседования я даже уточнил, а почему не было вопросов про планировщик, конкурентность, да и в целом глубоко не копали внутрянку Go. Ответ был (чуть вырванный из контекста, деталей все-таки больше):

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

Несмотря на мой отказ, через пару дней со мной связались и дали детальный фидбек. Причём не в формате “знал плохо”, а “на позицию ты подходишь, но вот куда смотреть, чтобы расти дальше”.

Даже нашёл сообщение с обратной связью:

В общем, так я увидел “как надо”. С каким впечатлением должны уходить те, кого собеседуют. Как выглядит реальная проверка знаний. И начал перестраивать свой процесс собеседований. А с Иваном мы продолжили общаться и он даже стал моим ментором в вопросах тимлидства / СТО.

Теперь перейдем к моим правилам, которых я использую как ориентир.

По тем или иным причинам рынок поменялся. Накрутка опыта была всегда, но сейчас это почти что тренд. Хорошо это или плохо — не мне решать. Я бы сказал, мне без разницы. Но эта тенденция есть и она ещё сильнее заставляет учиться нормально собеседовать.

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

Требуемые навыки зависят от позиции: не нужно требовать от junior'a системный дизайн, от хардового MLщика умение вытаскивать продуктовые требования из заказчика, а от middle-фронтендера знать нюансы устройства V8 (за редким исключением, когда это реально требуется).

Разумеется, к собеседованию я сам готовлюсь серьезно. Не подготовился — нанял не того, не с теми скилламм и не решил задачи бизнеса (а скорее создал себе головную боль и потратил много денег).

Довольно долго я писал вакансии заумным языком, добавляя побольше официоза. Мне почему-то казалось, что это делает меня и компанию солиднее. Со временем понял, что единственный результат — кандидаты не особо понимали, чем занимается "прорывная e-commerce" или "fintech" компания.

Ещё я вписывал в требования все умные слова, которые знал: Agile, DRY, SOLID, коммуникабельность, стрессоустойчивость, уровни изоляции, опыт с высокими нагрузками и т.д. По моей задумке, так откликнутся только те, кто всё это знает и умеет (ведь реально я проверять такие пункты не умел).

Опять же, со временем я понял, что наличие умных аббревиатур вообще не влияет на поток кандидатов. Обычно на них никто не обращает внимание, потому что примерно похожие аббревиатуры есть в ~80% вакансий. Общепринятые навыки нужно писать не в вакансии, а (внезапно) проверять на собеседовании.

Теперь я стараюсь не усложнять:

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

Кстати, лайфхак для Senior+ позиций: начинайте поиск с профильных чатов и через знакомых, а не хх.ру. Так выше шанс найти опытных ребят, которые не ищут работу прямо сейчас, но могут откликнуться на классную вакансию.

Как я писал выше, довольно долго я проверял разработчика "на всё". Теперь, перед тем, как искать разработчика, я выписываю, что действительно требуется для текущей позиции (ещё раз спасибо Ивану, что объяснил мне это). А затем отдельно продумываю, что не нужно и какие скиллы допустимо иметь на более низком уровне. Или не иметь вообще.

От разных разработчиков нужны разные скиллы (как харды, так и софты), которые нужно проверять по-разному. Если обобщить: к каждой позиции свой набор требований и не нужно проверять сверх них. Лучше хорошо проверить нужные навыки, чем средне-плохо все.

Навскидку, пару общих примеров:

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

Перед собеседованием у меня всегда выписан список вопросов и возможные пути развития диалога. Всегда разные планы под разные позиции (даже если должность формально одна). Незапланированная импровизация меня обычно приводила к бессистемности.

Всегда есть список вопросов на втором мониторе по резюме кандидата и то, что я должен выяснить про его опыт. Есть список задач по софтсиллам (если это Senior+ позиция и они требуются для вакансии).

Если есть задачи на лайвкодинг — подготовлена вкладка и код. Причём обязательно 2 сайта с редакторами на случай, если первый не заработает у кандидата из-за VPN / локации.

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

Если даю алгоритмы (изредка это действительно нужно)— они всегда разобраны с моей стороны, я знаю какие решения даже в теории возможны и в любой момент я готов подсказать / обсудить нюансы.

Важно: нельзя давать то, что сам не понимаешь или не встречал в работе. Например, мне были нужны алгоритмы только 1 раз в жизни под специфический проект с трейдингом.

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

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

Перед тем, как переходить к собеседованию — пообщайтесь 2-5 минут на отвлеченные темы. Спросите, как себя человек чувствует, не устал ли (особенно, если это вечер пятницы). Начните с лёгких вопросов, на которые кандидат точно ответит и почувствует уверенность в себе. Нужно несколько минут, чтобы разговориться, привыкнуть к собеседующему (особенно, если их несколько).

Если видите, что человек волнуется — проговорите, что это нормально. Объясните, что вы понимаете, какой это стресс, ничего страшного не происходит и напомните, как вы бывали в такой же ситуации. Это банально, но проговаривание — помогает людям (кстати, понимание таких моментов называется “эмпатия”).

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

Больная тема в найме, особенно с большим потоком кандидатов. Наверное, после ~70% собеседований я не получил нормальную обратную связь. Встречал или "решили продолжить с другим кандидатом", или "вы не подходите на позицию \ грейд по итогам собеседования". Без деталей и конкретных рекомендаций, что именно улучшать.

Если вы провели собеседования, к вам пришёл человек и потратил 1-2 часа времени — дайте фидбек. Не зависимо от того, наняли ли вы человека или нет. Фидбек — это:

А не просто отписка "вы не подошли" или "мы остановились на другом кандидате".

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

Затем распишите, что стоит “улучшить”. Это то, что требуется для вашей вакансии, но не хватило у кандидата. Например, на позиции нужно уметь шардировать данные, а кандидат не знал про хэши и способы шардирования в вашей БД. Или у вас финтех проект, а человек плохо знает про шифрование и его виды, не работал с округлениями и т.д.

Если человек подошёл, но другой кандидат оказался лучше или не сошлись зарплатные ожидания — так об этом и говорите. Сказав, что именно сравнивали и на что ориентировались.

Повторю: в обратной связи важно говорить именно про навыки, требуемые под конкретную позицию. А не абстрактные советы в духе “качать алгоритмы” или “разобраться в нюансах устройства JVM”, когда на должности нужно пилить CRUD’ы.

Обратная связь для кандидата нужна, прежде всего, собеседующему. Вот почему:

Если кандидат опытнее вас и вы не можете сказать ему, что улучшить — так об этом и скажите. При этом подсветите все сильные моменты, которые вам понравились.

Этот пункт связан с такой субъективной вещью, как "совпадение по характерам".

Как правило, вы нанимаете человека, с которым проработаете в среднем 1-3 года. Бывает такое, что может быть несовпадение по характерам. Например, кандидат сильно опытнее руководителя и явно давит этим. Или человек сильно токсичит и руководитель понимает, что работать с таким человеком тяжело (или человеку с таким руководителем, хе-хе).

Это адекватная причина отказать, если есть понимание, что продуктивность коммуникаций снизится. Но обязательно дайте честный фидбек. Объясните, что по навыкам у человека всё хорошо и причина субъективная.

Пусть считает, что вы или нанимающий неправы, чем сомневается в себе (раз я принял субъективное решение — ответственность тоже на мне).

Но чтобы принимать решения на субъективных ощущениях — нужен тот, кто будет работать с человеком. Если вы нанимаете не к себе в команду, вы не можете выдвигать такие суждения. Фильтр “попой чувствую, что что-то не так” на культурное соответствие — не работает.

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

Для меня они must have и, внедрив их, качество моих собеседований улучшилось. Я увидел отдачу в результативности разработчиков, стал более уверен в найме. Количество сильных специалистов, которые попадали ко мне в команду выросло.

Если считаете, что что-то стоит добавить — буду рад вашим комментариям и предложениям. Если статья вам понравилась или оказалось полезной, поставьте, пожалуйста, лайк. Это мотивирует писать объемные статье и рассказывать конкретику из своего опыта.

Ну и, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами. В том числе о проблемах, которые возникают. Там же я выкладываю ссылки на новые статьи.

Другие мои статьи: