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

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

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

Для начала следует понять основной принцип секции живого кода. Он, как и вообще у всего собеседования, элементарен - проверять именно рабочие навыки кандидата и создавать кандидату как можно меньше стресса. Например, точно не стоит писать код на листочке и компилировать в уме, а самый быстрый современный способ написать какую-то сортировку – просто набрать в интернете наименование этой сортировки, скопировать и проверить. И не надо писать, что вот лично ты никогда решений в интернете не искал и про stackoverflow.com в первый раз слышишь, ага.

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

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

Даем кандидату вводную – вот ты пришел работать, есть задача (написана и помещена в трекер). Решай. В задаче можно дать ссылку на репозиторий с проектом.

Кандидат шарит экран, читает задачу, берет ссылку, клонирует проект себе. Если кандидат такую работу делал, он быстро справится.

Дальше спрашиваем, что это за проект. Сеньор и выше сразу полезут в POM, Readme.txt и jaml, остальные – в код. Беседуем о том, что видим, прям буквально – что вижу, то и рассказываю.

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

Код запустился. Как нам проверить его работу? Есть ли постман, можно ли применить? А без постмана можно? Есть одно "но" - в коде не должно быть подвохов, он реально должен работать. Можно специально создать некие ошибки проектирования - например напихать всё в один класс, и поговорить об этом.

Далее выполняем поставленную ранее задачу, то есть пишем собственный код. Как видите, пишем в IDE, можно глянуть в интернет или привлечь индусов, если необходимо, никаких ограничений, всё, как на работе. Главное чтобы задача была решена четко и в срок.

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

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

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

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