Техническое собеседование синиора

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

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

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

Пару слов о собеседовании на младшие позиции

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

То, что я попробовал, и что не сработало.

Как и в разработке, периодически проводите ретроспективу, оценивайте ваш процесс и улучшайте его

Собеседования вне переговорки. Место проведения собеседования формирует первое впечатление о Вашей компании. Не стоит проводить его на своем рабочем месте , в коридоре, на кухне и т.д.
Абстрактные вопросы и вопросы о тонкостях технологии, которые вам не нужны, примерно следующие ( синиор точно должен знать вот это, к примеру): “Как там внутри работает сборщик мусора?”, хотя Вам еще ни в одном проекте не приходилось с этим сталкиваться. Или академические знания, вроде деревьев, алгоритмов и так далее. Да, никогда не знаешь, когда с этим столкнешься, но не стоит у кандидата требовать подобного опыта. Вам нужно понять, есть ли у кандидата достаточно опыта, чтобы войти в Ваш проект в течение следующих 2-х недель и начать выполнять поставленные задачи. Насколько он способен/увлечен/обучаем, чтобы справиться с возможными челленджами.
Плохой код на бумаге. Это когда показывают часть кода и просят рассказать, что в нем не так. Казалось бы, идеальный способ узнать о кандидате сразу много, но по факту это не работает. Причины, по которым кандидат не справится, не обязательно говорят об отсутствии нужных знаний, а скорее об отсутствии опыта в ревью чужого кода, стрессе, субъективности примера, непривычной подсветке кода и т.д.. Кроме того такое задание займет довольно много времени, и скорее всего это будет чуть ли не единственным из того, что вы успеете спросить в интервью.
Собеседование по анкете. Список заранее подготовленных вопросов должен быть обязательно. Во время собеседования следует вести протокол ответов, чтобы потом не сомневаться в заключениях. Но это не должно выглядеть как линейный список вопросов - ответов. Не должно быть однозначных ответов: “Знаю/не знаю”. Необходима конструктивный диалог. Дайте кандидату возможность самому рассказать о себе, пусть он немного расслабится, за это время постарайтесь понять, в чем кандидат уверен, начните с этого и уже потом ведите интервью в нужном направлении.
Не следует думать, что цель собеседования - только найм или отсев кандидатов. Собеседование - это помимо всего прочего представление Вашей компании, оно влияет на Ваш бренд.К примеру, кандидат может не подойти Вам в данный момент. Но это не значит, что в будущем ситуация не изменится. У кандидата должно остаться хорошее впечатление о компании. О собеседовании он может рассказать своим знакомым разработчикам. Это все HR бренд Вашей компании. Нужно следовать следующим пунктам:
- Не должно быть “Я умный - ты дурак”.
- Делитесь опытом, рассказывайте больше, показывайте свои варианты решения и аргументируйте их преимущества.
- Чаще упоминайте свои лучшие проекты и приводите примеры из них.
- Кандидат должен уйти уставшим, вымотанным, но довольным, потому что он пообщался с сильным “спецом”, получил новые знания, новый опыт.
- По возможности похвалите кандидата.

Кто такой синиор?

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

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

Описание позиции

Примечание: Это техническое описание позиции. Оно несколько отличается от описания вакансии. В нем нет профиля вакансии (кто кому подчиняется, зоны ответственности, место в компании) и компетенции ( соответсвие "духу компании" и т.д.)

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

Огромный опыт, который позволил выйти на новый уровень в разработке программного обеспечения
Думает бизнесом и решениями, а не кодом. Стремится всегда помочь найти баланс, видит обе стороны и подсказывает, как изменить функционал, чтобы решить проблему
Troubleshooter проекта. Смотрит на проблему не только с точки зрения кода, соответственно видит решение проблемы, а не фикс бага.
Заранее видит проблемы на проекте, которые есть сейчас и которые могут возникнуть в будущем. В отличие от мидла, не рвется их немедленно решать, а здраво все обдумает и оценит, предоставит оптимальное решение и рекомендации для клиента.
В написании кода на первом месте дисциплина, проработка решения и только потом кодирование, если решит им заниматься. До написания любого кода решение максимально продумано. То же при починке багов. Дисциплинированный подход, без гадания, тыкания и попытки скомпилировать код в голове. Сбор данных, составление гипотез, составление критериев проверки гипотез, проверка гипотез, Фикс бага или снова по кругу.
Занимается усовершенствованием процессов и технологий, которые использует команда.
Огромный опыт рефакторинга приложений. Знает много “фишек” и трюков, которые позволят улучшить качество кода и не сломать при этом остальное приложение.
Огромный опыт оптимизации приложений. Способен найти проблему на любом уровне, не только в коде, но и в инфраструктуре.

Это всего лишь мое описание позиции, очень ВАЖНО не взять готовое у меня или другой компании, а составить свое, соответствующее Вашим требованиям.

До обсуждения вопросов, которые стоит задавать, хочу затронуть одну, САМУЮ ВАЖНУЮ тему. НЕ спешите делать выводы о кандидате до конца всего собеседования. Довольно часто первые ответы на вопросы, которые не совпали с ожидаемым ответом, влияют на остальное собеседование. Вроде: “ Да зачем он вообще пришел на собеседование, если не знает такой элементарщины, только время зря потратим”. Есть много причин, по которым кандидат может растеряться и не ответить. Если интервьюер действительно заинтересован в найме умного, скилованного коллеги - он будет продолжать пытаться строить диалог, пока не попадет в точку соприкосновения, в которой кандидат уверен, в которой проявит себя, после чего расслабится и спокойно раскроет себя в оставшихся вопросах.

Памятка интервьювера

Следите за таймингом. Вы должны успеть пройти по всему списку вопросов. В той области, где кандидат имеет хороший опыт беседа может затянуться, интервью закончиться а у Вас останется ложноположительное мнение о кандидате. Цель интервью выявить все сильные и слабые стороны.
Не составляйте мнения сразу. Ведите лог ответов, давайте заключение на следующий день или хотя бы через пару часов.
Не забывайте, что это именно Вы устанавливаете правила беседы.
Вседа добивайтесь ответа на четкий вопрос: "Что? Где? Как? Почему?". Задавайте уточняющие вопросы, вдавайтесь в суть.
Если кандидат неверно понял вопрос и начал рассказывать о другом, смело прерывайте и уточняйте вопрос.
Каждый интервьювер несет ответсвенность за свои слова перед компанией.

Какие вопросы задавать?

Ниже представлен большой список вопросов, на основе которых вы можете построить свое интервью. Не факт, что они нужны Вам все сразу. Более того, собеседование не стоит превращать в опрос по анкете. Попросите кандидата самому начать рассказывать о себе, и, когда поймаете точку соприкосновения, начните задавать ситуативные вопросы. “А если вот так?” “А мы вот подобное делали, только вот так”. Дальше уже будет проще вести интервью в нужном русле.

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

Одни и те же вопросы, задаваемые разным кандидатам помогут стандартизировать Ваш процесс найма, более объективно сравнивать кандидатов.

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

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

Решение задачи должно быть простым, уровня джуниора, на 5-10 строк кода.
Задача должна решаться аналитически, не требуя знаний определенного алгоритма
Решение должно быть спорным с точки зрения идеального программирования

Эта задача не покажет Вам, что кандидат точно синиор, Но может указать, что он точно таковым не является.

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

Для синиора нет понятия - идеальный код, есть понятие - бизнес- задача, которую нужно решить, потратив ПРИЕМЛЕМЫЕ РЕСУРСЫ.

Мой пример задачи на руби - расширить тип данных массив, добавить в него метод map_2x, который будет возвращать массив, каждый элемент которого умножен на 2.

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

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

Технические вопросы

Со своими разработчиками составляете вопросы по текущему стеку, чтобы узнать, насколько кандидат в него попадает и насколько глубоко он его знает. Очень важно, чтобы эти вопросы составлял не один разработчик, а несколько. Вопросы не в рамках “знаешь/ не знаешь”, а именно на основе опыта. Нужно докапываться до ответов, пробираться в суть, чтобы избежать прохождения собеседования манипулятором.

Особенности языка, мета- программирование, особенности компилятора и так далее. В каждой технологии есть свои сложности, и нужно оценить, насколько кандидат с ними сталкивался и умеет ли их использовать.
Особенности фреймворка или библиотек.
Особенности СУБД, которые используются - индексы, оптимизация запросов, оптимизация и настройка самой СУБД и так далее.
Разработка API и взаимодействие с другими приложениями.
Умение профилирования приложения, поиск узких мест.
Покрытие кода тестами - TDD, BDD.
Знание и понимание того, как основные используемые инструменты, протоколы и так далее работают под капотом.

Беседа должна быть обменом опыта. Расскажите, как Вы решаете те, или иные задачи. Выясните, сталкивался ли с ними кандидат и как он их решал. Обсудите эти решения, отметив, какие в них плюсы и минусы.

Можно спросить про паттерны и SOLID - принципы, если актуально для Вашей компании. Опять же не в рамках “знаешь/ не знаешь”, а именно на основе опыта. Прямо скажите,, что можно подсмотреть в любые материалы, но объяснить своими словами и рассказать о примерах из своего опыта.

Добавляйте расслабляющие вопросы, например: есть ли любимая сторонняя библиотека и почему именно она. Поделитесь своей любимой библиотекой.

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

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

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

Мои любимые вопросы:

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

Философские вопросы

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

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

Командная работа

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

Менторили ли Вы младших разработчиков в команде?
Какие методологии использовали при разработке?
Опишите жизненный цикл задачи, к которому привыкли. Который считаете правильным?
Были ли у Вас конфликты в команде, как их решали?
Представьте, что вы дали эстимейт на задачу 8 часов, а через 4 часа разработки осознали, что ВОЗМОЖНО сделаете эту задачу еще за 8 часов. Релиз завтра - Ваши действия?

Лидерские качества и управление командой

Очень повезет, если кандидат не только умеет решать задачи клиента, но и развивать команду и управлять ею.

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

Послесловие

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

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

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

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