Я более десяти лет жизни писал код в одной российской компании и активно собеседовал-нанимал людей. За это время успел пообщался с четырьмя сотнями кандидатов. На моих интервью было все – от алгоритмических задач до разговоров о «жизни». Но форма вторична – я рассматриваю интервью как инструмент для проверки совпадения с кандидатом по культуре. И все эти десять лет в моей компании менялся подход к оценке программиста на интервью и менялась культура.
Любое собеседование адекватно компании, которая его проводит. Даже если от собеседования «бомбит» и «подгорает» - проблема в кандидате, а не в компании. И как кандидат я очень рад такому простому фильтру для отбраковки не подходящих мне компаний. Но и компания тоже преследует свои цели – сохранение и изменение своей культуры за счет найма «правильных» людей. Проверка технических навыков тоже важна, но важнее нанимать людей, с которыми можно работать.
Далее я хочу рассмотреть в формате моей истории разные способы оценки программиста на техническом интервью. У меня нет цели рассказать обо всех методиках оценки компетенций. Мой обзор методов оценки будет не полным, эгоцентричным и предвзятым. Также часть моего рассказа будет собрана из историй про другие компании. Это не будет рассказ как все на самом деле обстоит-обстояло, и прошу считать эту историю чистым вымыслом.
Интерлюдия
Ты искал свободу без границ
// 12 обезьян
В 2012 году я был опытный разработчик в городе Иркутске и имел опыт управления людьми. Я работал в индустрии 9 лет и уже проводил собеседования. Основной метод оценки компетенций был – разговор с кандидатом об опыте. Обычно интервью длилось не более двух часов – проверялась применимость опыта кандидата и совпадение подходов к решению задач. И было мнение – что «неподходящего» кандидата всегда можно уволить на испытательном.
Рядом в индустрии вовсю практиковали проверку кандидата на испытательном сроке. Активно увольняли тех, кто «не тянул». Я сам один раз попал в такой жесткий фильтр. Спустя 12 недель после выхода меня попросили сделать презентацию моей работы команде. А потом «выгнали» в коридор и стали совещаться. Дым из трубы пошел белый и я остался в компании. Но так «везло» не всем, и беспечность некоторых кандидатов меня поражала.
Я до сих пор считаю – это кандидату важно куда он идет работать. Для компании по большей части все равно, главное нанять с виду адекватного человека и проверить его в «бою». Поэтому кандидату важно на собеседовании задавать вопросы - понимая с кем придется работать и круг свои обязанностей. Сам я в то время активно практиковал 12 вопросов от старика Джоэла.
Первичный фильтр
Вдаль смотрел дожидаясь вестей.
// Ничей
В 2012 году переехал в Санкт-Петербург с идеей за две недели найти работу. Заполнил опросник проверки адекватности на сайте у моего будущего работодателя. Прикрепил резюме и пошел собеседоваться в другие компании. В опроснике было несколько вопросов про синтаксис языка программирования и задача вида - что выведет этот код:
public class JoyOfHex {
public static void main(String[] args) {
System.out.println( Long.toHexString(0x100000000L + 0xcafebabe));
}
}Такой способ оценки кандидата проверяет умение использовать поисковые системы и компилировать в голове нужные ответы. А еще можно запустить код в IDE. В дальнейшем я имел возможность убедиться в неадекватности такого первичного фильтра, когда сам собеседовал прошедших его людей. Получается мы проверяем одни критерии, а на собеседовании требуем от кандидата совсем другое. Это замечают опытные кандидаты и раздается очередной звонок неадекватности компании.
Такой фильтр может иметь внутри себя неточности и двойное толкование ответов. Можно воспринимать это как умный вариант раздражающей всей капчи. Я такое очень осторожно использовал для «отбраковки» стажеров, для опытных людей не вижу в этом смысла. Никакой проверкой на культуру тут не пахнет, и если ответы на вопросы занимаю более десяти минут, то я пройду мимо.
Первый удаленный контакт
Вдруг раздастся гром небесный
// Позвони мне, позвони
Спустя неделю я по телефону рассказывал своему потенциальному руководителю:
какие методы есть в классе Object;
что такое inversion of control;
чем singleton отличается от prototype;
...
Это отличный формат для первого скрининга, особенно если вам не жалко времени ваших программистов на оценку потока. В теории можно сразу после этого давать оффер, но скорее всего это будет «прелюдией» к настоящему собеседованию. Но чем больше этапов собеседований, тем меньше шансов у кандидата дойти до финала (про это можно найти исследования в сети).
И пожалуйста – не надо давать опросные листы для использования людьми без опыта программирования. Это нормальный кандидат видит и смеется (глубоко внутри себя) над этим театром абсурда. Потом еще потребуется заставить своего программиста погадать на итогах этих опросных листов.
Тестовое задание
Про то, что больше не могу
// Кончится лето
Далее мне было предложено написать два небольших тестовых задания: sql запрос и сервис для скачивания данных из интернета. Запрос я написал быстро, а сервис стало лень писать хорошо. А плохо бы у меня не приняли, как я узнал потом. В тот момент у меня уже были параллельно идущие собеседования и готовые офферы на руках. Поэтому я отказался продолжать с ними разговор.
Данный формат собеседования идеален при большом потоке кандидатов и позволяет фильтровать «случайных» людей и ребят без мотивации. Компания практически ничего не тратит и может за счет кандидата проверить насколько он хорош. Я сам подобным пользовался, когда нанимал стажеров в своей компании в 2006–2008. Также я сам выполнял подобные тестовые задания если мне это было интересно.
Но у этого формата есть и большой минус – опытные кандидаты не любят тратить свое время без гарантии результата. Компания также не обязана давать кандидату детальный фидбек и есть очень много «вкусовщины» при ревью чужого кода. Есть риск ненароком обидеть «тонкую ранимую личность», и испортить свою репутацию на рынке труда. Поэтому нормальный фидбек по тестовому заданию — это миф и так не бывает.
Парное программирование
Мне кажется, нам по пути
// Два капитана
В 2013 я продолжил общение с компанией и меня «уговорили» прийти на собеседование в офис. Там мне позадавали для вежливости вопросы про технологии и язык программирования, посадили за ноутбук и дали задачу написать кэш для работы в многопоточной среде. Ноутбук был дрянной с отвратительной клавиатурой, но мне не разрешили писать на своем ноутбуке (был у меня с собой).
В процессе мы обсуждали как я буду решать задачу и какие сложности будут в предложенном решении. Использовать стандартную готовую библиотеку было нельзя. В конце мы вместе поревьювили код и поправили пару неясностей. Но был небольшой залет – в какой-то момент ребята свалили пообедать, оставив меня одного в переговорке дописывать тесты. Такое себе – я может тоже хотел есть?
Я считаю, что это один из лучших способов оценки экспертизы кандидата. Можно видеть, как он думает и как решает проблемы. По сути, компания проверяет насколько может работать с кандидатом, а кандидат проверяет адекватность собеседующих. Тут важно вежливо и корректно говорить о проблемах, уметь объяснять свою позицию и слушать. Далее я пытался улучшить этот подход, но сила оказалась в простоте.
В итоге я принял оффер и начались «мои десять лет». Но для этого пришлось пройти еще одно собеседование с руководителем разработки – «за жизнь». Еще до этого был «конфетно-букетный» этап на пару часов, когда мне продавали компанию и позицию. Итого я потратил почти 10 часов, не считая дороги на собеседования. Это были целиком мои инвестиции в смену работы. Но благодаря этому я нашел компанию близкую мне по культуре.
Чек-лист возведенный в абсолют
Вышиби двери плечом
// Мама, мы все тяжело больны
В 2014 я сам стал собеседовать, и мы в подразделении стали думать – как улучшить процесс. Все вышеперечисленное давало результат, но не хватало единообразия в заполнении итогов оценки кандидата. Каждый собеседующий заполнял фидбек как он это считал нужным, и нельзя было применять результаты собеседования в других командах – не хватало информации.
В итоге мы сделали убер опросник, вопросы были сгруппированы в темы. По каждому вопросу было написано, что мы ожидаем услышать – результат был «не бинарным», и на вопрос выделялось 2–3 минуты. По каждому вопросу можно было записать комментарий и развернуто написать ответ кандидата. Каждый собеседующий заполнял excel-таблицу, где было более сорока двух вопросов.
Выглядело это примерно так (в скобках примеры):
Тема вопроса (spring)
Вопрос кандидату (чем singleton отличается от prototype)
Дополнительное описание вопроса для собеседующего (ссылка на документацию)
Что должен ответить кандидат и как это влияет на оценку
Оценка по бальной шкале
Дополнительная информация об ответе кандидата
Результат представлял собой сырую информацию об опыте кандидата. Нанимающий менеджер мог принять решение построив модель кандидата у себя в голове. Мы дали возможность выбирать идеальных инженеров, подходящих к узлам нашего сборочного конвейера. Но проверялось совпадение по технологиям, а не культуре. Наш сборочный конвейер менялся и нам были нужны программисты, а не поломанные шестеренки.
Было очень скучно заполнять итоги собеседования, когда ты монотонно шел по чек-листу. Собеседующие срывались в обсуждение интересных им тем, а заставить их действовать по «инструкции» было невозможно. Мы пытались менять убер чек-листы, искали «волшебную пулю», но собеседующие это не «покупали».
Алгоритмы? Алгоритмы!
Всё повторяется по кругу
// Великий Индиктион
В 2014 пришел новый CTO и решил научить нас правильно программирование любить. По его инициативе в 2015 до нас докатились алгоритмические секции и стало неважно на каком языке кандидат пишет код. Мы стали просить людей писать алгоритмический код на бумажке или доске. А наш CTO «огнем и мечом» требовал от нас соблюдения формата. Он собрал группу людей, которые все контролировали и отчитывались ему о проблемах и результатах.
Было ожидание что кандидаты будут писать примерно такое:
// сгенерировано при помощи chatgpt
public static int median(int a, int b, int c) {
if ((a >= b && a <= c) || (a <= b && a >= c)) {
return a;
} else if ((b >= a && b <= c) || (b <= a && b >= c)) {
return b;
} else {
return c;
}
}Идея с алгоритмическими задачами меня увлекла, я не был «олимпиадником» в моем вузе. Я решал только учебные, а потом и промышленные задачи. По своей сути – «и то код, и то код», я прорешал наши задачи самостоятельно и стал их задавать на интервью. Но я так и не смог полностью отказаться от других способов оценки кандидата.
Мне хотелось работать с коллегами, которые пишут понятный код и с которыми можно эффективно взаимодействовать. По моему мнению программист это в первую очередь инженер, а не алгоритмист. Это было не соответствие видению компании, и я был вынужден измениться чтобы встроиться в новую создаваемую культуру.
В итоге мы перестали проверять навыки инженерии, и получили на входе поток программистов, которые не умели писать и поддерживать продакшен код. При этом было забавно наблюдать за программистами, которые выполняли devops задачи после того, как они проходили наши алгоритмические секции. В первое время эффективность и результат их работы были плачевными.
Спустя время культура компании изменилась, и мы сплотились вокруг идеи, что программист должен уметь в алгоритмы. Это очень сильно повлияло на внутренние процессы и дало очень сильный толчок к развитию. Акции компании росли, конкуренты оставались в «кильватере». Причин успеха было множество, но также этому поспособствовало устранение «бардака» в найме и фокус на «правильной» культуре.
Тестовые дни
У него пуля в пушке для твоей черепушки
// Татарин
В 2015 году я попал на собеседование в другую компанию, где все начиналось плохо – мне выдали опросник на 40 минут по технологиям и языку программирования. Потом меня посадили в кабинет с будущей командой и дали тестовую задачу никак не ограничив время на решение. Рядом со мной шел обычный рабочий процесс с обсуждением задач. Я «влюбился» в такой подход, но оффер не принял. Пацаны на нашей анонимной борде сказали – уходить надо на «икс два», а +35% это «ниочём». Меня удержали культурой и интересными задачами.
В 2017 году мой коллега ушел в отпуск на пару недель, и вышел в тестовом режиме на новую работу. Поработав две недели, он вернулся к нам назад. При этом он ничем не рисковал, и никто его за это не наказал. Он даже получил зарплату за две недели на новой работе. Его руководитель был в курсе этого и все было сделано с его согласия. Вот так безопасно удалось протестировать новое место работы.
Я считаю – это кандидату важно, где и как он будет работать. Компания всегда может его уволить или задвинуть поддерживать «чужое легаси», чтобы программист сам ушел. Но для программиста важно на что он тратит свою жизнь и какой опыт при этом получает. Опыт является часть оплаты труда, и при хорошей зарплате это служит отличным способом удержания людей. Поэтому программисту полезно инвестировать в тестовые дни, даже если за них не заплатят.
Особенно хорош подход инвестирования своего времени «за еду» для начинающих программистов. Так можно получить ценный опыт и найти хорошо оплачиваемую работу. Я несколько лет проработал в студенческой компании, а мои одногруппники работали официантами-продавцами и зарабатывали сильно больше меня. Но я никогда не гнался за деньгами, мне всегда был интересен опыт и возможности, которые я мог получить на новом месте работы. Сейчас я вижу, что это окупилось сполна.
Проектирование архитектуры
Но помни, наверх попадёт один
// Революция на вылет
Тем временем в компании зрело недовольство – кандидаты со знанием алгоритмов не умели в проектирование систем и не могли создавать поддерживаемые решения. Ходили идеи вернуть собеседования про технологии и языку программирования. Но было решено пойти другим путем – проведение архитектурных собеседований как дополнительный этап для опытных кандидатов.
Не все кандидаты были в восторге от этого. Ведь мы стали кроме нескольких алгоритмических секций проводить еще и архитектурную секцию. Многие не понимали – что это и зачем. И тут помогал опыт собеседования в FAANG, чтение книг про такой формат и просветительские статьи от компаний. Дополнительно это снизило шансы на найм из-за увеличения числа этапов на собеседовании.
Я любил на подобных архитектурных собеседованиях давать проектирование архитектуры знакомого мне сервиса и задавал что-то из этого списка:
Архитектура http сервера для обработки пользовательских запросов (jetty, tomcat).
Сервис по отправке данных о пробках с пользовательских устройств.
Скрапер (downloader) ссылок из интернета.
Все это прекрасно работало, но оказалось на рынке нет людей, которые могут пройти этот отбор. Почему-то многие программисты не интересуются как работают внутренности. Возможно, это уже не требуется в индустрии, но я всегда интересовался этим и вокруг меня были люди, с которыми можно было обсудить странность «коллапса волновой функции» (на обывательском уровне).
В итоге в компании решили, что алгоритмическая секция позволяет оценить уровень кандидата не выше среднего мидла. А для опытных ребят обязательно прохождение архитектуры. Это дало нам определенный буст, но мы отказались от большого куска рынка кандидатов. Людей не хватало и приходилось брать хотя бы мидлов, и доучивать их в процессе. Но зато прошедшие архитектуру были близки к нам по культуре и с ними было интересно работать.
Эксперименты с требованиями
Где давно потух огонь в асфальт закатанных надежд
// Готэм
Вскрылась еще одна проблема пока мы налаживали алгоритмические и архитектурные секции – не все кандидаты были мотивированы идти к нам на собеседования. Кого-то пугало большое число секций, кто-то думал о нашей неадекватности. Поэтому я стал проводить собеседования для продажи команды. Мы с кандидатом разговаривали «за жизнь», я рассказывал про наше направление и пытался оценить интерес.
Во второй части собеседования я рассказывал про процесс нашего собеседования и давал кандидату задачу чтобы оценить его готовность пройти наши секции. Мой опыт алгоритмических собеседований помогал мне в этом. Я за одну задачу мог сразу понять вероятность прохождения наших собеседований.
Но и этого мне показалось мало, и я стал проводить эксперименты с алгоритмическими задачами. Я взял задачу на написание функции – вычисляющей значение арифметического выражения из строки (калькулятор выражений), и изменил подход как эту задачу задают. Вначале я просил кандидата поддержать только сложение и вычитание для арифметических выражений. После решения кандидата я менял требования и смотрел как кандидат «выкручивается». При этом было видно, как принимаются компромиссные решения, особенно после очередного изменения требований.
Еще я пробовал давать сложную задачу полностью объясняя алгоритм и смотрел умеет ли кандидат программировать по ТЗ. Подобные задачи я давал только для людей, которые не могли придумать алгоритм. И только чтобы расстаться на хорошей ноте – они бы все равно не прошли дальнейшие алгоритмические секции. У меня было понимание, что уважительно отношение и открытость с объяснением ситуации поможет нам сохранить хорошие отношения с кандидатом и возможно приведет к нам других хороших ребят.
В итоге я понял – лучшее враг хорошему, и не надо улучшать парное программирование на собеседовании. Кандидат должен сам придумать и сам решить задачу. И даже на простой задаче можно получить сигнал о «хорошести» кандидата.
Лицо принимающее решение
Скажи сестре, что я болен душой
// Мама, я не могу больше пить
В 2023 году у нас внедрили новую спорную схему оценки кандидата. Все эти годы мы делали процесс найма и описывали кандидатов в стандартном формате. У нас работали алгоритмические и архитектурные секции. И внезапно сверху было принято решение о внедрении контроллеров найма.
Контроллер оценивал кандидата по всем его секциям и ставил ему безапелляционно оценку – нанимать и на какой уровень. Для компании было важно иметь везде одинаковые условия и человек не мог получить мидла в одном подразделении, а синьора в другом. Таких контроллеров иногда называют – bar raiser, и их задача блюсти планку найма по всей компании. Конкретно у нас этот человек даже не видел кандидата вживую, а работал с фидбеком других собеседующих.
Синьор разработчики и так «сбривались» на алгоритмах и архитектуре, а тут их внезапно перестали считать синьорами наши новые контроллеры найма. Я пытался изменить ситуацию и апеллировать к выводам контроллеров, и спустя время все получилось. Мне выдали возможность частично игнорировать выводы контроллеров найма при наличии «объяснительной записки».
Есть ли от подхода с «bar raiser» профит для компании? Думаю есть, и в очередной раз меняется культура внутри. Кризис роста невозможно преодолеть без потерь и изменений. Адаптация текущих сотрудников уже идет «полным ходом», и обратные связи создают баланс. Говорят даже начали вспоминать старые добрые способы оценки программиста на языковой секции и секции про технологии. Есть мнение что это повлияет на выводы людей оценивающих кандидатов.
Что дальше?
Наше дело — свинец!
// Стрелок
Не бывает правильных и неправильных способов оценки программиста. Собеседование — это поиск человека близкого вам по культуре. Процесс найма должен адаптироваться под команду. Всегда надо это держать в голове и тогда у вас будет комфортная рабочая среда для достижения результатов.
Я очень ценю десять лет работы-жизни в компании интересных людей. Я получил уникальный опыт, и не пришлось для этого соглашаться «работать за еду». В компании сложилась уникальная культура, и там работают очень крутые ребята. Как я уже писал ранее – эта культура не для всех, но мне «зашло».
Прямо сейчас я уже работаю в другой компании — меня купили новым опытом и возможностями. Я делаю платформу для Golang/Java/Kotlin разработчиков и параллельно выстраиваю процессы найма программистов. Также я строю культуру общения среди собеседующих и нанимающих менеджеров. Попробую про это рассказать в другой раз.
В конце напомню — это всё вымысел, и конечно же придумано в моей голове. Спасибо, что прочитали, и готов послушать обратную связь в удобном вам формате.
