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

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

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

Содержание

• Какой у меня опыт собеседований и как я пришёл к правилам ниже?

• Собеседование, которое поменяло мой подход к собеседованиям

• Правило 1. Качественное собеседование — единственный способ реально проверить навыки кандидата (а накрутка опыта стала стандартом индустрии)

• Правило 2. Вакансия должна быть написана без пафоса и понятным языком

• Правило 3. Под каждую позицию нужно определить, какие требования реально нужны и убрать те, которые нужны "теоретически"

• Правило 4. План собеседования должен быть подготовлен заранее, никакого "сориентируюсь по ходу дела"

• Правило 5. Собеседование нужно начинать со "смоллтока" и простых вопросов, чтобы снизить беспокойство кандидата

• Правило 6. Нужно давать фидбек. Детальный конструктивный фидбек

• Правило 7. На собеседовании должен присутствовать тот, кто будет непосредственным руководителем кандидата

• Заключение

Какой у меня опыт собеседований и как я пришёл к правилам ниже?

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

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

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

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

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

Собеседование, которое поменяло мой подход к собеседованиям

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

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

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

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

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

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

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

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

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

Правило 1. Качественное собеседование — единственный способ реально проверить навыки кандидата (а накрутка опыта стала стандартом индустрии)

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

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

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

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

Правило 2. Вакансия должна быть написана без пафоса и понятным языком

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

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

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

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

• пишу простым языком, что делает компания;

• что нужно будет делать сотруднику с примерами задач;

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

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

Приведу пример вакансии, которую мы переписали с моим знакомым, чтобы закрыть позицию:

Ключевые изменения:

• убрали то, что подразумевается по умолчанию (всё, что касается навыка "нормально писать код") или вообще не нужно (например, брокеры сообщений);

• упростили описание компании, привели конкретные примеры задач;

• вписали, что действительно нужно с акцентом на софт скиллы, которые критичны для этой позиции.

После переписывания текста, субъективно, начали откликаться более опытные разработчики, которые могут и им интересно "затащить проект с нуля". А разработчики, которым комфортнее в рамках выстроенных процессов, наоборот, стали реже откликаться.

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

Правило 3. Под каждую позицию нужно определить, какие требования реально нужны и убрать те, которые нужны "теоретически"

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

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

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

• Миддл для позиции Х должен знать фреймворк А, уметь хорошо писать код и дружить с SQL. Но нестрашно, если не расскажет о трейдоффах микросервисов относительно монолита (ведь это решит техлид/синьор). А техлиду, как раз, нужно иметь навык "не раздуть стоимость инфраструктуры Kubernetes'ом на этапе MVP с 10 000 MAU".

• Синьор для позиции Y должен дружить с разными подходами к кэшированию, быть в состоянии настроить шардирование или оптимизировать реплику MySQL на чтение. Но без разницы, если не слышал про бинарное дерево и чем отличается LinkedHashMap от TreeHashMap. В зависимости от позиции можем подзабить на софты.

• Тимлид для позиции Z должен уметь вытягивать требования из заказчика и разруливать конфликты. Чтобы потом декомпозировать задачи для разработчиков (допустим, product manager'а в проекте вообще нет). А фреймворк Х может знать средне, не уметь написать CTE запрос в PostgreSQL за 5 минут без ChatGPT и не знать точного определения CAP теоремы (для этого есть сеньоры / техлиды).

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

Правило 4. План собеседования должен быть подготовлен заранее, никакого "сориентируюсь по ходу дела"

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

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

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

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

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

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

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

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

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

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

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

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

Правило 6. Нужно давать фидбек. Детальный конструктивный фидбек

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

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

• в чем вам понравились знания человека;

• что не подошло под позицию;

• что бы вы порекомендовали улучшить.

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

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

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

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

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

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

• Если вы нанимаете — значит вы и занимаетесь менторством. Когда даёте обратную связь и подсвечивает зоны роста... вы учитесь давать конструктивную обратную связь своим сотрудникам. Это прямая задача руководителя, которая помогает расти команде в целом.
  

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

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

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

Правило 7. На собеседовании должен присутствовать тот, кто будет непосредственным руководителем кандидата

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

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

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

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

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

Заключение

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

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

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

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

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

• Постмортем: 4 мои ошибки во время отражения DDOS атаки (спойлер — выкуп в $250 мы все-таки не заплатили)

• 3 способа продвижения пет-проектов (почти) без бюджета на конкретных примерах

• Посмотрим с другой стороны: а какая польза от корпоративных блогов, ссылок на Telegram каналы и запрета на дизлайки?