Как я провожу собеседования

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

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

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

Оптовая закупка

Я являюсь сторонником подхода, когда команда, ее состав, рабочий тонус, внутренняя инженерная культура - это ответственность тимлида. У тимлида должна быть возможность тонкой настройки. Тимлид должен иметь представление, образно говоря, сколько "лучников", "мечников" и "кавалеристов" ему нужно для решения задач. Тимлид должен чувствовать баланс и четко понимать, что разработчики - могут быть очень разными, но каждый может быть полезен по своему. Кто-то хорошо держит ритм и предсказуем. Кто-то сложен и независим, но чаще других выдает действительно хорошие идеи и мыслит глобально. Кто-то, как рыба в воде, чувствует себя в сложной и важной для проекта, предметной области. А кто-то полный рас*дяй, но отлично выступает на конференциях. Каждый должен быть на своем месте и с каждым нужно работать немного по своему.

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

Так вот, самые интересные кандидаты, по моему опыту, ВСЕГДА в чем-то немного не вписываются. Таким образом, подход "оптовых закупок", с одной стороны, не дает возможности тимлидам строить команду согласно собственным критериям, а с другой - слишком часто оставляет за скобками действительно опытных и самых интересных кандидатов, и способствует доминированию посредственностей.

Память ≠ Знание

Принято ценить хорошую память. Человек-ходячая-энциклопедия, часто, автоматически, считается интеллектуалом (а это далеко не всегда так). Вот только способность ЗАБЫВАТЬ что-то - это, также, очень важная и недооцененная фича нашего мозга. Именно она, во многом, определяет такое важное свойство, как нейропластичность - способность нейронов переобучаться, а значит, адаптироваться к новым условиям и искать новые решения.

Слишком часто на интервью пытаются проверять насколько хорошо кандидат ПОМНИТ какие-то мелочи или детали стека. Вот только хорошие и опытные разработчики, уже забыли больше, чем новички когда-либо знали. Это нормально и это хорошо. Восстановить знания и напомнить себе что-то - гораздо проще, когда ты на опыте постиг базовые принципы.

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

Инженерная культура

А вот с проверкой (как и с пониманием) принципов у самих тех-интервьюеров часто бывают сложности. И что делать в такой ситуации? Мой ответ - убедиться, что у человека есть какие-то принципы вообще, что у него сформированы свои представления о инженерной культуре и своем месте в ней.

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

Кирпич в голове

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

В таком случае, важно убедиться, что кандидат принципиально способен пересматривать свое мнение. Как минимум - конструктивно полемизировать на любую тему, без исключения.

Профессиональный кругозор

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

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

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

Импакт от ИИ

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

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

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

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

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

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

Доказательство превосходства

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

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

Мой совет интервьюерам - сдерживайте себя. Попробуйте поставить себя на место кандидата.

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

Страхи

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

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

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

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

Готовьтесь к интервью

Готовиться к интервью должен не только кандидат. Если вы тех-интервьюер - потрудитесь потратить хотя-бы минут двадцать перед встречей. Изучите резюме. Посмотрите GitHub. Пролистайте блог, твиттер (или как он там сейчас называется), если он есть. Заранее подумайте, какие вопросы могут быть уместны именно для этого человека, а не для абстрактного "фронтендера с тремя годами опыта".

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

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

Персональный бренд

Я, безусловно, не имею в виду глянцевую обертку, когда говорю о персональном бренде. Мне, в первую очередь, важно наблюдать за тем, как человек организует свое публичное пространство. GitHub-профиль, личный сайт, блог, ответы на Stack Overflow, статьи, доклады - все это, в совокупности, может рассказать о кандидате гораздо больше, чем формализованное резюме.

Обратите внимание на то, пишет ли кандидат осмысленные README к своим проектам. Есть ли тесты. Насколько аккуратен код в pet-проектах, где никто не стоит над душой. Это та самая "инженерная культура в естественной среде обитания" - когда человек делает качественно не потому, что так требует процесс, а потому, что по-другому не умеет. Но делайте скидку на факультативный характер подобных материалов.

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

Экономим время

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

Мой подход: одно полноценное техническое интервью, длительностью около часа, в формате живого диалога. Если мне этого недостаточно для вынесения решения - значит проблема во мне, а не в количестве раундов. И дело вовсе не в том, что я такой весь из себя проницательный, просто я понимаю, что количество случайностей и факторов, на которые у нас нет влияния - нивелируют любые попытки добиться большей точности оценки. Ваша оценка - всегда субъективна, но она, также, чаще всего, достаточна. Добавление раундов, как правило, не добавляет новой информации - оно лишь плодит субъективные мнения людей, которые видели кандидата по 15 минут и склонны судить по первому впечатлению (как и вы сами).

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

Ломаем лед

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

Я обычно начинаю с чего-то неформального. Спрашиваю о чем-то, что увидел при подготовке - о его pet-проекте, о статье, о каком-то дополнительном опыте. Это сразу показывает, что вы потратили время на подготовку (см. выше), и переводит разговор в режим диалога, а не допроса.

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

Стек мечты

Один из моих любимых вопросов: "Если бы ты начинал проект с чистого листа, без ограничений - какой стек бы выбрал? И почему?"

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

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

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

Анти-паттерны (Вредитель)

Один из моих фирменных приемов. Иногда, разговор гораздо легче склеить вокруг того, как делать не надо. Покажите кандидату примерный фрагмент кода и спросите: "Что здесь не так? Что бы ты изменил?" Или, еще проще: "Расскажи о самом ужасном коде, который тебе доводилось видеть. Что именно было плохо?".

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

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

Вместе решаем проблему

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

Более того, сформулировать саму проблему, также, можно вместе. Это показывает кандидату, что вы не ждете от него заготовленных ответов.

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

По сути, вы моделируете реальный рабочий процесс. И лучшего теста на то, каково будет работать с этим человеком бок о бок, просто не существует.

Анализ результатов

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

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

И еще: анализируйте не только кандидатов, но и себя.

Поиск кандидатов и первичный скрининг

Лучшие кандидаты, как правило, не ищут работу. Они уже работают, и довольно неплохо (как минимум, раньше было так). Это значит, что пассивное ожидание откликов на вакансию - заведомо неоптимальная стратегия. Активный поиск, нетворкинг, рекомендации от команды - все это работает значительно лучше. И проблема здесь в том, что никакой внешний рекрутер за вас эту работу сделать не сможет. Ему гарантированно не хватит компетенций. Соответственно, все участники процесса должны твердо осознавать, что временные затраты могут оказаться существенными и их необходимо закладывать при планировании.

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

Один из лучших источников кандидатов - профессиональные сообщества. Open-source проекты, тематические конференции, митапы, профессиональные чаты - вот это все.

Автоматизация

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

А вот автоматизация оценки кандидатов - это скользкий путь.

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

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

И если вы дочитали до этого места - значит, вам не все равно. А это уже половина дела.