Регулярно мы видим в интернетах множество размышлений или криков души на тему содержания собеседований в IT. Мол, и интервьюировать не умеют, и задачи дают не релевантные, и вопросы бессмысленные, и, вообще, собесы в IT это ритуал и карго-культ. Сидит там интервьюер и думает: «чего бы такое ещё спросить», самоутверждается, а решение принимает в итоге наобум и по первому впечатлению. 

В то же время компании в своих блогах пишут, как они за все хорошее, против всего плохого. 

Если коротко, то я тоже считаю, что среднестатистический собес – это бессмысленный трэш, и сам я иногда провожу их неудачно.  Раньше вообще проводил «как все» – то есть отвратительно. Затем, задумался.  А что, если я постараюсь осмыслить, зачем я провожу интервью и почему задаю те вопросы, которые задаю? Может быть, мне будет проще отбирать релевантных кандидатов? Или я хотя бы смогу сэкономить немного времени, убрав из процесса что-то лишнее?

Добрый день. Меня зовут Михаил Толстой. Я работаю ведущим руководителем проектов в Ozon Tech и пишу в телеграм-канал «М-м-м, Толстой».

Вагона терпения описывать в один присест всё-всё-всё, что я пробовал, у меня нет (и едва ли у вас было время столько разом читать) – поэтому ловите сперва разбор самого одиозного из элементов технического интервью – live-кодинга. 

По какой схеме пойдет дальнейшее повествование: 

1. как было; 

2. что я думаю; 

3. что я попробовал; 

4. нюансы и ответвления; 

5. что вышло; 

6. промежуточный итог. 

Как было 

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

Ты сразу же задаешься вопросом «А как это делается?» и начинаешь выдавать комбо из того, что делают твои коллеги (ну они ж умные) и того, как собеседовали тебя. Дедовщина. Служи, как дед служил. 

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

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

Кандидат же насилует себя литкодом (или не насилует, а просто мычит, когда получает задачу на подсчёт фигурных скобочек) 

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

Почему так происходит...

Что я думаю 

Итак, порассуждаем, зачем на собеседовании задавать вопросы и задачи? 

Чтобы на основании ответа понять, подходит ли кандидат на позицию. Обладает ли он требуемыми навыками. 

«Обладает ли требуемыми навыками» – имхо, эта фраза располагает и дальше мыслить в канцелярите.  Ты начинаешь в описании вакансии указывать требования в общих терминах, чтобы звучало ухххх, на все 300к/наносек. «Уверенное владение», «экспертные знания», и прочий «опыт работы с Х». В итоге на вакансию откликаются самые самоуверенные, а не те, кого, ты на самом деле жаждешь найти. 

Попробуем быть проще. Переформулируем вопрос:

А умеет ли кандидат делать то, что ему, собственно, придется делать на работе? 

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

— Будет ли он писать код? 

— Конечно, да 

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

— Он должен писать алгоритмически сложный код? 

— Примерно никогда 

— А какой код он будет писать? 

— Ну, как у нас тут. 

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

— А как он будет писать код? 

— Как и мы в IDE… 

Почти все, с кем я общался, считают, что разработчик должен уметь пользоваться инструментарием. Но почему инструментарий – это только утилита греп или kubectl?! Он в IDE сидит 90 процентов времени, может неплохо было бы уметь ей пользоваться? 

— Да он ничего не может без автокомплита! 

— А с автокомплитом он может то, что требуется? 

Забивать гвозди микроскопом – это не только про инструменты и фреймворки. Это ещё и про людей. Вам нужен человек, который в конкретной команде будет выдавать определенный результат. Вам правда важно, будет ли он гуглить как называется тот или иной метод? А если не важно, то зачем подвергать стрессу кандидата и «разрешать выдумывать нужные методы»? 

— А как он будет проверять написанное? 

— Ну мы пишем тесты, и он тоже будет. 

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

Вы же планируете платить ему за это, почему бы не проверить? 

Что я попробовал 

У меня есть несколько простых задач. Часть специфична для языков, библиотек и кейсов (ну и опыта кандидата). 

Но есть и универсальные. 

Моя любимая — «удаление троек». 

На вход подается коллекция целых чисел. 

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

Я подожду пока вы досмеётесь. :)

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

Я проверяю как он его читает. Мне интересно, какие вопросы он задаст.

Как он выстроит коммуникацию? 

Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял».
Плюс: что предупредил о намерении.
Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.

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

Кто-то сразу приводит пример входа и выхода (устный TDD получается)

Кто-то уточняет что подразумевается под коллекцией результатом. Новая ли коллекция, какие для нее есть условия и ограничения. Что за коллекция подается на вход.

Кто-то просто молча начинает писать.

Подумайте заранее, кто впишется в конкретно ваш коллектив? 

Или вам все равно, как человек работает, лишь бы был результат? Такое тоже может быть.

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

Приходит Java-девелопер за триста и начинает, мыча, for-циклы крутить. Окей – нет стримов в анамнезе, но может какие-то библиотеки помогаторные? Пусть подключит тогда! Ну или вот такой опыт у него… Во-первых, мы это узнали вообще. Во-вторых, вдруг он так пишет быстро. Быстрее, чем ты на своих цепочках методов в Scala.

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

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

Конечно, мы все дописываем тесты чаще, чем подключаем тестовые библиотеки, поэтому в настройке IDE я не жду скорости молнии. Но странно нанимать человека, который не может подключить тест-систему…

Нюансы и ответвления 

Дьявол в деталях.

Разумеется, ситуации в разных командах и компаниях разные. Тем более, нужно быть честными с самим собой и чётко понимать, что именно вам нужно от кандидата. 

– Но мне нужен программист, который справляется с более сложными заданиями! 

– А как вы это поняли? 

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

Такие задачи и правда бывают. Даже занимаясь «перекладкой джейсонов», бывает нужно и деревце обойти или мапы потранспонировать. А иногда продукт действительно не простой, и надо что-то на специфических конструкциях языка поделать или учесть какую-то хитрую особенность API.

— Какая задача покажет, что он сможет писать такой же сложный код как у нас? 

— Та, для которой вы писали этот сложный код. 

Постарайтесь найти ваши реальные сложные куски кода и приведите их к формату задачи на собеседование! Идеально было бы помнить:

• как ваши текущие инженеры это решали;

• были ли обсуждения;

• помощь коллег;

• сколько дней или итераций ревью съел кусочек кода.

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

Как вариант, проэмулируйте с ним парное программирование – определите, что и по каким ответам он должен понять. Проверьте, сможет ли он эффективно с вами коммуницировать. 

А если вам правда надо писать с листа именно такие штуки – ну их и проверяйте. 

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

– Значит и он не будет. 

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

Но мы сейчас так уйдем от основной темы статьи. 

Что получилось 

Я собеседовал этими тройками программистов на Java, Scala, C++, Python and Javascript.  Сеньоров-помидоров, ми-ми-миддлов и джунов, – всех с разными ожиданиями, разумеется. 

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

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

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

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

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

Промежуточный итог 

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

Кандидат при этом может получить релевантный фидбек. 

Рассказ о вашем собеседовании может настроить сарафан на более подходящий поток. 

Первый рабочий день принесет вам значительно меньше сюрпризов. 

Впечатления о человеке (на основании впечатлений вы и решаете «брать или не брать») больше похожи на впечатления от его настоящей работы. 

Нашёл ли я серебряную пулю? Конечно, нет! Как минимум потому, что мы нанимаем человека, инженера, а не просто машину по написанию кода. А проверить личные качества и софты — это ещё более сложная задача. 

Но, надеюсь, описанный выше подход, позволит выиграть на эти проверки немного времени и ресурсов. 

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

Желаю вам работать с людьми, подходящими для своих позиций!