2019-01-17
Как кандидат на интервью код в продакшн выкатывал.
Я в первых выпусках несколько раз рассказывал про асимметричность процесса найма.
С кандидата обычно спрашивают так, что с него семь потов сойдёт. И про любимые пет-проджекты расскажи, и про будущее на ближайшие пять лет, и про образование и опыт, и про тонкие детали работы технологии. Ну и про алгоритмы, конечно.
Что же про себя рассказывает компания?
Печеньки, молодой дружный коллектив, дух стартапа, белая зарплата
Конечно, ты всегда должен задавать правильные вопросы во время интервью. Про такие вопросы я напишу отдельный пост. Но как бы ты не спрашивал, если у тебя нет инсайдера в виде знакомого, то первый рабочий день будет полон сюрпризов.
Знакомая ситуация, да?
Как тебе врут
Больше всего меня расстраивают компании, которые врут про стостояние процессов и технологий.
Знакомая, собеседуясь в 2017 году слушала рассказы о том, что они вот-вот переедут с SVN на GIT. Да, в две тысячи, сука, семнадцатом году. Впрочем, в остальном компания её устроила, и она приняла оффер. На дворе 2019 год, как ты думаешь, кто до сих пор хранит код в свн?
Да я и сам видел как истории типа “мы активно мигрируем на микросервисную архитектуру” в реальности оказывались одним дохлым сервисом по рассылке email-ов, который даже в докер засунули.
Да, формально это не ложь, но по-факту от тебя многое скрывают. И про старый код, и про безумные процессы.
Что мы делали
На одной из прошлых работ я был серьёзно вовлечен в процесс найма. У нас был один этап, которым, пожалуй, можно гордиться.
После более-менее стандартных этапов — скрининг резюме, скайп, тестовое задание, мы привозили кандидата к нам в офис. Оплачивали ему билеты на самолёт, визу и снимали гостиницу в центре города, рядом с офисом.
Формально, этот этап был частью отбора. Мы всё ещё задавали вопросы и пытались понять подходит ли нам этот человек, но, конечно, на онсайте уже принятно предварительное решение. И, если кандидат не совершал каких-то глупостей, то он получал оффер.
Настоящей же целью было проверить так называемый team fit, очень субъективно определить нравится ли он нам, как человек, хотим ли мы с ним работать. Второй стороной медали было желание показать компанию и команду с выгодной стороны. Показать, как и чем мы живём, какие мы, как работаем.
Обычно всё начиналось с экскурсии по офису и рассказу об отделах и нашем бизнесе. Потом были разговоры с HR и тимлидом. За час до обеда кандидата выдавали мне. Я отводил его к своему рабочему месту, вытягивал из джиры специально подготовленный таск и предлагал кандидату его закрыть.
Задача, была относительно синтетическая. Что-то из серии “добавить ещё одно поле в JSON ответ, предварительно достав его из таблички в базе”. Иногда чуть проще, иногда чуть сложнее. Такая задача была подробно расписана, пожалуй, подробнее, чем была бы описана настоящая задача.
В то время, мы практиковали парное программирование, и я рассказывал кандидату, что вот так мы работаем. Брал код из репозитория, попутно объясняя, как устроено хранение кода и где и как мы держим модули и сервисы.
Далее, я создавал новый бранч, рассказав о бранч-модели, используемой в компании. Открывал проект и объяснял его структуру. После передавал управление кандидату. В данном случае было честное парное программирование: я отвечал на любые вопросы, мог советовать. Кандидат мог предлагать любые изменения и конечно же, можно было пользоваться гуглом. Более того, я не стеснялся гуглить сам, если забывал какие-то мелочи.
Сама задача была минут на пять-десять. Незнакомый с кодом кандидат мог тратить сколько угодно времени. Ни каких целей или оценок не ставилось.
Если кандадат успевал, то мы вносили все необходимые правки в код, создавали пулл-реквест, который максимально быстро проходил ревью и получал фидбэк. Ревьюер, конечно же, был заранее ознакомлен с задачей и ему не требовалось дополнительное время для понимания контекста.
После успешного мерджа, код раскатывался по окружениям и прогонялись авто-тесты. И, если оставалось время, по отмашке QA кандидату предоставляли почетное право запустить деплой на продакшн.
После, мы всей командой отправлялись на обед в ресторан и отпускали кандидата погулять и посмотреть город. Благо, в Европейской столице всегда найдётся на что поглядеть и чем себя занять.
Зачем всё это?
В первую очередь, мы хотели показать полный и максимально реалистичный путь от задачи в баг-трэкере до продакшна. Нам казалось честным рассказывать о всех процессах. Мы не скрывали потенциальные проблемы в коде и инфраструктуре. Честно говорили и об устаревших фреймворках и о странностях. Но и показывали себя, как слаженную и крепкую команду.
Это был своеобразный тест-драйв рабочего места. Да, поездка вокруг торгового центра не сравнима с многочасовым стоянием в пробках, но в любом случае это лучше, чем покупать машину по рекламному ролику в интернете.
По отзывам кандидатов (как тех, кто принимал оффер, так и тех, кто отказывался) такой подход им нравился.
Важным и приятным бонусом является фидбек, высказаный кандидатом. Это возможность свежим взгядом оценить сложность процессов внутри команды. Так часто бывает, что ты привыкаешь к каким-то шагам, и даже забываешь зачем они нужны. А тут тебя спросят “ой а почему так?”, и ты поймёшь, что не знаешь ответа. Это полезно.
Но это всё долго и дорого
Увы, но это и правда, очень затратный процесс. А зачастую, что-то подобное делать не возможно из-за юридических вопросов и NDA. Наверное, дешевой альтернативой будет корпоративный инженерный блог.
Кстати, на сколько я знаю, эта практика в той компании уже закончилась. И хайринг превратился в более-менее стандартный и безликий процесс. Очень жаль.
Выводы
У нас был кандидат, который в целом нам понравился, но он решил, что не хочет работать в нашем формате. Не помню, уж что ему не понравилось, кажется парное программирование. Я считаю, что это хороший показатель успеха. Мы заранее получили отказ, сэкономив немало денег на релокейт того программиста из Берлина. Такой кандидат ушёл бы из компании достаточно быстро.
Мне кажется такое открытое и человеческое отношение — хорошее дело. Конечно, для внедрения таких практик нужно иметь сильного и авторитетного сотрудника, готового взять на себя ответственность за это мероприятие. Нужны люди, готовые вести этот час. Хотя, мне кажется, это легче, чем засыпать кандидата вопросами на классическом интервью.
Как вам такой вариант? Хотели бы, чтобы это стало стандартной практикой?