Регулярно мы видим в интернетах множество размышлений или криков души на тему содержания собеседований в IT. Мол, и интервьюировать не умеют, и задачи дают не релевантные, и вопросы бессмысленные, и, вообще, собесы в IT это ритуал и карго-культ. Сидит там интервьюер и думает: «чего бы такое ещё спросить», самоутверждается, а решение принимает в итоге наобум и по первому впечатлению.
В то же время компании в своих блогах пишут, как они за все хорошее, против всего плохого.
Если коротко, то я тоже считаю, что среднестатистический собес – это бессмысленный трэш, и сам я иногда провожу их неудачно. Раньше вообще проводил «как все» – то есть отвратительно. Затем, задумался. А что, если я постараюсь осмыслить, зачем я провожу интервью и почему задаю те вопросы, которые задаю? Может быть, мне будет проще отбирать релевантных кандидатов? Или я хотя бы смогу сэкономить немного времени, убрав из процесса что-то лишнее?
Добрый день. Меня зовут Михаил Толстой. Я работаю ведущим руководителем проектов в Ozon Tech и пишу в телеграм-канал «М-м-м, Толстой».
Вагона терпения описывать в один присест всё-всё-всё, что я пробовал, у меня нет (и едва ли у вас было время столько разом читать) – поэтому ловите сперва разбор самого одиозного из элементов технического интервью – live-кодинга.
По какой схеме пойдет дальнейшее повествование:
как было;
что я думаю;
что я попробовал;
нюансы и ответвления;
что вышло;
промежуточный итог.
Как было
Когда я только начинал свою карьеру, никакого морального права оценивать ребят с улицы у меня не было. А потом в один прекрасный день ты уже миддл-инженер и тебя направляют мучить кандидатов. Ну или как минимум соучаствовать в этом мучении. Лычка сеньора уже автоматом превращает тебя в палача.
Ты сразу же задаешься вопросом «А как это делается?» и начинаешь выдавать комбо из того, что делают твои коллеги (ну они ж умные) и того, как собеседовали тебя. Дедовщина. Служи, как дед служил.
И вот уже ты сам просишь людей написать что-то на доске/ на листке / в нотпаде или в веб-приложении для лайвкодинга.
И ты не останавливаешься – грейды растут, а подход не меняется, кандидата просят по-быстрому повертеть строки из гласных, полазать по разноцветным деревьям, что-то мутное поскорить и найти самый палиндромный палиндром.
Кандидат же насилует себя литкодом (или не насилует, а просто мычит, когда получает задачу на подсчёт фигурных скобочек)
И часы жизни спускаются на скрип пера по бумаге, чтобы написать то, что никогда не скомпилится.
Почему так происходит...
Что я думаю
Итак, порассуждаем, зачем на собеседовании задавать вопросы и задачи?
Чтобы на основании ответа понять, подходит ли кандидат на позицию. Обладает ли он требуемыми навыками.
«Обладает ли требуемыми навыками» – имхо, эта фраза располагает и дальше мыслить в канцелярите. Ты начинаешь в описании вакансии указывать требования в общих терминах, чтобы звучало ухххх, на все 300к/наносек. «Уверенное владение», «экспертные знания», и прочий «опыт работы с Х». В итоге на вакансию откликаются самые самоуверенные, а не те, кого, ты на самом деле жаждешь найти.
Попробуем быть проще. Переформулируем вопрос:
А умеет ли кандидат делать то, что ему, собственно, придется делать на работе?
Тогда логичным кажется, чтобы он на собеседовании показывал что-то максимально похожее на его работу.
— Будет ли он писать код?
— Конечно, да
Окей, на этом этапе какой-то кодинг в процессе отбора получается необходим. Простите, все, кто ждал, что я предложу выкинуть этот этап совсем.
— Он должен писать алгоритмически сложный код?
— Примерно никогда
— А какой код он будет писать?
— Ну, как у нас тут.
Если вы хотите, чтобы новый член вашей команды писал быстро код, как пишете его вы, то и задача пусть будет похожа. Вы занимаетесь перекладкой джейсонов, так может стоит проверить может ли кандидат их перекладывать?
— А как он будет писать код?
— Как и мы в IDE…
Почти все, с кем я общался, считают, что разработчик должен уметь пользоваться инструментарием. Но почему инструментарий – это только утилита греп или kubectl?! Он в IDE сидит 90 процентов времени, может неплохо было бы уметь ей пользоваться?
— Да он ничего не может без автокомплита!
— А с автокомплитом он может то, что требуется?
Забивать гвозди микроскопом – это не только про инструменты и фреймворки. Это ещё и про людей. Вам нужен человек, который в конкретной команде будет выдавать определенный результат. Вам правда важно, будет ли он гуглить как называется тот или иной метод? А если не важно, то зачем подвергать стрессу кандидата и «разрешать выдумывать нужные методы»?
— А как он будет проверять написанное?
— Ну мы пишем тесты, и он тоже будет.
Попросите человека написать тест с использованием знакомого ему фреймворка. Лично я в своем опыте вижу корреляцию между перформансом специалиста и тем, насколько резво и легко он пишет несложные тесты.
Вы же планируете платить ему за это, почему бы не проверить?
Что я попробовал
У меня есть несколько простых задач. Часть специфична для языков, библиотек и кейсов (ну и опыта кандидата).
Но есть и универсальные.
Моя любимая — «удаление троек».
На вход подается коллекция целых чисел.
Напишите метод, который удаляет из коллекции все тройки, для всех нечётных чисел, вызывает метод с побочным эффектом (пусть это будет печать в консоль), удаляет все семёрки, умножает всё на 2 и возвращает коллекцию-результат.
Я подожду пока вы досмеётесь. :)
Итак, приходит кандидат, я прошу его запустить свою IDE, свой сетап в котором ему удобно и привычно. Предупреждаю, что задача без подвоха, и скидываю условие.
Я проверяю как он его читает. Мне интересно, какие вопросы он задаст.
Как он выстроит коммуникацию?
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял».
Плюс: что предупредил о намерении.
Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.
Кто-то решает уточняет должны ли действия происходить в том же порядке что и описано в задаче, является ли множество упорядоченной последовательностью шагов.
Кто-то сразу приводит пример входа и выхода (устный TDD получается)
Кто-то уточняет что подразумевается под коллекцией результатом. Новая ли коллекция, какие для нее есть условия и ограничения. Что за коллекция подается на вход.
Кто-то просто молча начинает писать.
Подумайте заранее, кто впишется в конкретно ваш коллектив?
Или вам все равно, как человек работает, лишь бы был результат? Такое тоже может быть.
И дальше я смотрю, что будет. Ожидаемый результат – это быстрое без тормозов использование стандартных и/или любимых библиотек и алгоритмов.
Приходит Java-девелопер за триста и начинает, мыча, for-циклы крутить. Окей – нет стримов в анамнезе, но может какие-то библиотеки помогаторные? Пусть подключит тогда! Ну или вот такой опыт у него… Во-первых, мы это узнали вообще. Во-вторых, вдруг он так пишет быстро. Быстрее, чем ты на своих цепочках методов в Scala.
Затем я предлагаю проверить решение. Хотя и предпочитаю кандидатов, которые сами об этом заговаривают и или задают вопросы или сразу пишут автоматическую проверку.
Если кандидат начинает писать тест-кейсы в мейне, я спрашиваю его, как он проверяет свой код на текущем месте работы. Прошу создать тестовые файлики и смотрю, как он использует тест-фреймворк, ассерты, и как он тесты вообще запускает.
Конечно, мы все дописываем тесты чаще, чем подключаем тестовые библиотеки, поэтому в настройке IDE я не жду скорости молнии. Но странно нанимать человека, который не может подключить тест-систему…
Нюансы и ответвления
Дьявол в деталях.
Разумеется, ситуации в разных командах и компаниях разные. Тем более, нужно быть честными с самим собой и чётко понимать, что именно вам нужно от кандидата.
– Но мне нужен программист, который справляется с более сложными заданиями!
– А как вы это поняли?
Некоторое количество моих знакомых улучшили свой найм, когда провели ревизию своих сложных задач.
Такие задачи и правда бывают. Даже занимаясь «перекладкой джейсонов», бывает нужно и деревце обойти или мапы потранспонировать. А иногда продукт действительно не простой, и надо что-то на специфических конструкциях языка поделать или учесть какую-то хитрую особенность API.
— Какая задача покажет, что он сможет писать такой же сложный код как у нас?
— Та, для которой вы писали этот сложный код.
Постарайтесь найти ваши реальные сложные куски кода и приведите их к формату задачи на собеседование! Идеально было бы помнить:
как ваши текущие инженеры это решали;
были ли обсуждения;
помощь коллег;
сколько дней или итераций ревью съел кусочек кода.
Может быть на самом деле вам и не нужно, чтобы кандидат решал эту задачу в одно жало и за 40 минут.
Как вариант, проэмулируйте с ним парное программирование – определите, что и по каким ответам он должен понять. Проверьте, сможет ли он эффективно с вами коммуницировать.
А если вам правда надо писать с листа именно такие штуки – ну их и проверяйте.
– Ой, у нас легаси, с ним надо разбираться, мы сами эту дичь не писали.
– Значит и он не будет.
Очень часто задача не написать фреймворк или алгоритм, а разобраться в существующем коде, чтобы найти ошибку или порефакторить его, не сломав. Иногда можно собрать тестовый проект и предложить кандидату выкачать его в свою IDE, подключить и посмотреть, как он работает с исходниками, как он будет реагировать на вашу кодовую базу.
Но мы сейчас так уйдем от основной темы статьи.
Что получилось
Я собеседовал этими тройками программистов на Java, Scala, C++, Python and Javascript. Сеньоров-помидоров, ми-ми-миддлов и джунов, – всех с разными ожиданиями, разумеется.
Поскольку хороший кандидат уровня миддл и выше справляется с этим быстро, то остается время «помять задачу», обсудить число проходов, как оно вообще под капотом (если не на голых циклах человек решение родил). Обсудит�� особенности тестовых фреймворков. Ну или можно дать еще одну задачку. Поразительное количество человек валились, мямлили что-то неадекватное, не умели собрать и запустить свою программу. Что уж говорить о подходе к тестированию.
А если бы задача была сложная – надо бы было дать кандидату время, потом еще пожалеть его, вдруг он не додумался по какой-то причине.
А если кандидат не справляется с тройками, то я очевидно не готов с ним работать. Вежливо сворачиваемся, общаемся и пытаемся разойтись в хороших отношениях на бодрой ноте. 8 таких интервью экономят полный рабочий день.
Если же кандидат справляется с подобной и/или более специфической задачей, похожей на его будущий труд, то я увидел всё что хотел, остальное я добью другими вопросами и другим форматом.
Знакомство с лучшими из работавших у меня инженеров, началось с удаления троек, и кучу людей я успешно этими же тройками отсеял. И ни разу у меня не было претензий к написанию кода, потому что я стал проверять то, за что собираюсь платить.
Промежуточный итог
Проанализировав работу, которую придётся выполнять вашему будущему коллеге или подопечному, вы можете разговаривать с ним более честно и меньше теряться в сомнениях «на собесе он ок, а каково будет с ним работать». Собеседование можно свернуть раньше, увидев тот или иной красный флаг, и честно его обсудить.
Кандидат при этом может получить релевантный фидбек.
Рассказ о вашем собеседовании может настроить сарафан на более подходящий поток.
Первый рабочий день принесет вам значительно меньше сюрп��изов.
Впечатления о человеке (на основании впечатлений вы и решаете «брать или не брать») больше похожи на впечатления от его настоящей работы.
Нашёл ли я серебряную пулю? Конечно, нет! Как минимум потому, что мы нанимаем человека, инженера, а не просто машину по написанию кода. А проверить личные качества и софты — это ещё более сложная задача.
Но, надеюсь, описанный выше подход, позволит выиграть на эти проверки немного времени и ресурсов.
В следующих частях мы посмотрим, что ещё мы можем проверить и обсудить с кандидатом, чтобы повысить шансы нанять именно того, кого нужно.
Желаю вам работать с людьми, подходящими для своих позиций!
