Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
Такой развёрнутый вопрос стимулирует кандидата дать развёрнутый ответ. Кандидат может поспорить с вами и сказать, что даже если шаблон не применяется, то время, ушедшее на его изучение, всё равно нельзя назвать потраченным впустую, что изучение шаблонов развивает разработчика (назвав таким образом ещё один плюс). Или поговорить о том, что шаблоны проектирования учат структуре мышления, и у разработчика любая программа состоит из шаблонов проектирования, реализация которых задаёт некоторый доменно-ориентированный язык, на котором написана бизнес-логика приложения.
2.2 Уровни знания
Беседуя с разработчиками на разные темы я заметил, что уровень зрелости разработчика можно определить по набору тем, на которые он может вести беседу. Есть базовые знания, которые доступны разработчикам даже с небольшим опытом, а есть действительно сложные области, в которых разбирается только эксперт. Иерархия тем показана на рисунке 2.1.
Рис. 2.1: Уровни знания по технологии
Давайте рассмотрим какую-нибудь область, например, юнит-тесты и разложим знания разработчика в соответствии с этой иерархией:
Определения.
Сюда можно включить базовые понятия, которые получает junior-разработчик в самом начале изучения: «Что такое юнит-тест?», «Что такое тест-метод?», «Какие фреймворки для юнит-тестирования бывают?» Обычно не стоит тратить время на задавание этих вопросов. Если кандидат не знает ответы на них, то это скоро станет и так очевидно, а правильные ответы не скажут о разработчике ровным счётом ничего.
Плюсы.
Что дают нам юнит-тесты? Зачем мы их вообще используем? Ответы на эти вопросы даются в любой книге по юнит-тестам. Разработчик должен знать ответы на них, чтобы применять юнит-тесты осмысленно:
Они позволяют проводить автоматическое регресионное тестирование;
Без них трудно делать функциональное тестирование для многих программ (например, реализация какой-то библиотеки на C++);
Они являются своеобразной документацией (особенно, если они содержат комментарии).
Минусы.
О чём не пишут ни в каких книгах, так это о минусах технологий и подходов[3]. Но ведь каждый разработчик много раз сталкивался с проблемами новых прекрасных технологий. Managed code. Многопоточность. Микросервисная архитектура. NoSQL. Шкура опытных разработчиков покрыта шрамами, каждый из которых подписан этими названиями. Знание минусов – это то, что отличает матёрого разработчика от оптимистично настроенного новичка.
Например, для юнит-тестов:
Написание юнит-тестов требует много времени. А их поддержание требует времени ещё больше;
Стопроцентное покрытие юнит-тестами часто невозможно. Для бизнес-логики юнит-тесты хороши, но если много UI и взаимодействия со сторонними системами, то юнит-тесты могут быть почти бесполезны;
Запуск юнит-тестов требует времени, которое добавляется к каждому билду. Иногда это время становится недопустимо большим.
Философия.
Когда разработчик начинает понимать взаимосвязь между разными технологиями, их место в процессе разработки и своё место в этом процессе, он выходит на уровень философии. На этом уровне кандидат может рассказать, почему юнит-тесты стали неотъемлемой частью процесса разработки, как они связаны с Continuous Integration и Continuous Deployment, как можно снизить затраты на их создание и как можно доказать заказчику, что они нужны.
В своих собеседованиях я обычно в каждой теме пробегаюсь по уровням, игнорируя самый базовый уровень определений. Я открываю обсуждение вопросом: «Зачем нужна эта технология?» Если кандидат даёт чёткий и развёрнутый ответ, то следующим пунктом спрашиваю: «А какие проблемы есть с использованием этой технологии?» Очень опытные кандидаты часто, отвечая на эти открытые вопросы, сами выходят на уровень философских рассуждений, но им можно помочь, задав вопрос: «А как вы сами относитесь к этой технологии?» Похожий подход нужно по порядку применить ко всем областям, которые вы хотите обсудить. Я это называю «сканированием знаний» кандидата.
Не стоит ограничиваться только философскими вопросами. Разработчик может иметь высокий общий уровень, что даст ему возможность хорошо отвечать на высокоуровневые вопросы, но «плавать» в относительно простых темах. Однако же если разработчик быстро назвал основные плюсы технологии, основные минусы и описал, как эта технология вписывается в современный подход к разработке, то уровень его в этой технологии высок. Он мог пропустить что-то из-за невнимательности, или стресса, или своих убеждений, но даже если вы промучаете его ещё полчаса дополнительными хитрыми вопросами, то оценка уровня не изменится. Вы можете уточнить у кандидата, почему он не назвал что-то, но только если вы считаете пропущенное действительно очень важным.
Если вам нужно очень быстро (например, за 20 минут) прособеседовать мощного архитектора, то вполне достаточно задать один развёрнутый философский вопрос. Например: «Как современные практики и подходы к разработке позволяют разрабатывать код быстро и качественно?» Ответ, скорее всего, позволит вам определить уровень кандидата в целом. Хотя, конечно, будет лишён детальности.
Про то, как шесть проектов собеседовали Машеньку
Рекрутёры нашли новую кандидатку, Машеньку. Опыта у неё было немного, но резюме давало надежду, что она дотягивает до уровня Middle Developer, ну или хотя бы является твёрдым Junior’ом, которого можно быстро подтянуть.
Рынок кандидатов, как обычно, был почти пуст, а потребность в кандидатах была, как обычно, высокая. Поэтому новый разработчик нужен был сразу в шесть разных проектов.
Чтобы не гонять кандидатку несколько раз и не давать преимущество ни одному из проектов, было назначено часовое интервью одновременно на все шесть проектов. Интервьюеры об этом не знали, поэтому были удивлены, когда в назначенный час в переговорке собралось восемь человек (некоторые проекты выставили двоих собеседующих).
Ещё сильнее была удивлена Машенька. Она была стеснительной девушкой и явно испугалась шумной толпы тимлидов. Она села на стульчик в центре комнаты, чувствуя тот же ужас, который испытывала недавно на защите диплома перед высокой комиссией.
Самый активный из интервьюеров начал:
– Ну что ж, расскажите нам, пожалуйста, для начала про принципы SOLID.
Кандидатка напряглась, собираясь с мыслями, но ответить ничего не успела, так как подключился второй тимлид:
– Да ладно SOLID. Здесь и старшие разработчики плавают. Лучше скажите, есть ли у вас опыт работы с базами данных?
– Нет, позвольте, – первый не сдавался, – для моего проекта знание SOLID является ключевым!
– А для нашего ключевым является знание БД! – второй либо любил спорить, либо не любил принципы SOLID.
– Да дайте же ей ответить что-нибудь! – вступился за девушку третий интервьюер.
Машенька уточнила:
– А про что отвечать, про SOLID или базы?
– SOLID! Базы! – указания прозвучали одновременно. Представитель одного из проектов мрачно встал и молча вышел из переговорки. В глазах Машеньки читался ужас.
Через пятнадцать минут дружеского переругивания был установлен порядок собеседования. Каждый успел задать один вопрос, некоторые даже два. Машеньке было очень трудно, так как темы менялись со скоростью света, наводящие вопросы противоречили основным и интервьюеры часто перебивали её и друг друга. Когда Машенька ушла, все тимлиды признались, что у них не получилось понять, что она знала.
Неизвестно, что подумала Машенька, но все остальные подумали одно и то же: «Больше – никогда!»
2.3 Задачки на собеседовании: FizzBuzz
При собеседовании специалиста вам нужно посмотреть, как он реально работает. Для тестировщика нужно дать ему что-то протестировать. Для мендежера – решить какую-то управленческую задачу. Для разработчика – дать ему написать код.
Зачем смотреть, как разработчик пишет код? Потому что написание кода очень сильно отличается от ответов на вопросы. При этом задействуются совсем другие знания, работают другие рефлексы. Можете перебрать в уме каких-то знакомых вам разработчиков, чтобы понять, что разработчики работают очень по-разному.
Вот, например, Вениамин накидывает код с неимоверной скоростью и дикой кучей ошибок. Он получает большое количество замечаний на ревью и от тестировщиков, но исправляет их тоже мгновенно. За всё время работы так и не утихают споры на тему, не быстрее ли писать код сразу нормально. Но команда дружно просит не давать ему на реализацию новую сложную функциональность. Вениамин – бог быстрого багофикса.
А вот Сергей программирует так, что его код можно спокойно сразу отдавать на поддержку маньяку-убийце. Сергей продумывает всё и вся, и тестировщики считают тикеты от него личным вызовом. Правда, лучше не просить его быстренько закрыть критичный баг. Сергей делает работу долго. Но качественно. Но долго.
Вы знаете, какие именно разработчики вам нужны. Поэтому вам нужно попросить кандидата написать что-то прямо на интервью. Это должна быть совсем небольшая задача. Реализовывать её лучше на бумажке, так как на бумажке это будет быстрее, и кандидат не будет отвлекаться.
Классическая задача, которую я использую – это FizzBuzz. Она формулируется следующим образом:
Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово «Fizz», а вместо чисел, кратных пяти – слово «Buzz». Если число кратно и 3, и 5, то программа должна выводить слово «FizzBuzz». Это программная реализация детской игры, в которой игроки должны по очереди называть числа или слова «Fizz», «Buzz» и «FizzBuzz» по тем же правилам.
Решение этой задачи простое и кандидат может написать его за минуту или две. В интернете есть куча обсуждений на эту тему и много разнообразных решений на разных языках. Вот пример такого решения на C#:
for(int i=1; i<=100; i++)
{
string output = "";
if (i % 3 == 0) output += "Fizz";
if (i % 5 == 0) output += "Buzz";
if (output.Length == 0) output = i.ToString();
Console.WriteLine(output);
}
Я смотрю, как кандидат подходит к решению этой задачи. Вот он написал в сторонке начало выходной последовательности, потом каким-то псевдокодом набросал решение, прокрутил вручную несколько итераций, отмечая ручкой текущую операцию, внёс пару исправлений, перепроверил и переписал всё на нормальном языке программирования. Потом пара вопросов от меня («А не сложно ли будет в вашем коде заменить 5 на 7?»), и мы можем идти дальше.
В интернете многие пишут, что эта задача просто раскрыла им глаза, что 90% соискателей в принципе не могут написать рабочий код или тратят на него больше 15 минут. На моей практике результаты не настолько печальные. Действительно, многие разработчики впадают в лёгкий ступор и тратят неразумное время на решение этой задачи даже с моими подсказками. Но таких мне встречалось не более 20%. Возможно, отбор рекрутёров в моих компаниях был лучше, чем в среднем по отрасли.
Я не принимаю на работу программистов, которые не справляются с такой задачей. В моих проектах от программистов требуется написание бизнес-логики, иногда довольно сложной, поэтому бессмысленно нанимать человека, который явно не способен реализовывать алгоритмы.
Можно, после провала с FizzBuzz, дать второе задание, аналогичное, чтобы подтвердить, что проблема действительно существует и не связана с этой конкретной задачей. Но в моей практике, когда программист не мог написать FizzBuzz, он не мог написать и вторую практическую задачу.
Есть очень много возмущённых отзывов на тему, что человек не может называться программистом, если он не может написать FizzBuzz. Я более спокойно отношусь к этому. Да, любой выпускник профильного ВУЗа должен уметь решить эту задачку. Да, решение этой задачи включает только очень базовые навыки программирования, и печально, что не все с ней справляются. Но надо признать, что есть много компаний, где от разработчика не требуется реализации хоть сколько-нибудь сложных алгоритмов.
