Как кандидат на интервью код в продакшн выкатывал.

Я в первых выпусках несколько раз рассказывал про асимметричность процесса найма.

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

Что же про себя рассказывает компания?

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

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

Знакомая ситуация, да?

Как тебе врут

Больше всего меня расстраивают компании, которые врут про стостояние процессов и технологий.

Знакомая, собеседуясь в 2017 году слушала рассказы о том, что они вот-вот переедут с SVN на GIT. Да, в две тысячи, сука, семнадцатом году. Впрочем, в остальном компания её устроила, и она приняла оффер. На дворе 2019 год, как ты думаешь, кто до сих пор хранит код в свн?

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

Да, формально это не ложь, но по-факту от тебя многое скрывают. И про старый код, и про безумные процессы.

Что мы делали

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

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

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

Настоящей же целью было проверить так называемый team fit, очень субъективно определить нравится ли он нам, как человек, хотим ли мы с ним работать. Второй стороной медали было желание показать компанию и команду с выгодной стороны. Показать, как и чем мы живём, какие мы, как работаем.

Обычно всё начиналось с экскурсии по офису и рассказу об отделах и нашем бизнесе. Потом были разговоры с HR и тимлидом. За час до обеда кандидата выдавали мне. Я отводил его к своему рабочему месту, вытягивал из джиры специально подготовленный таск и предлагал кандидату его закрыть.

Задача, была относительно синтетическая. Что-то из серии "добавить ещё одно поле в JSON ответ, предварительно достав его из таблички в базе". Иногда чуть проще, иногда чуть сложнее. Такая задача была подробно расписана, пожалуй, подробнее, чем была бы описана настоящая задача.

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

Далее, я создавал новый бранч, рассказав о бранч-модели, используемой в компании. Открывал проект и объяснял его структуру. После передавал управление кандидату. В данном случае было честное парное программирование: я отвечал на любые вопросы, мог советовать. Кандидат мог предлагать любые изменения и конечно же, можно было пользоваться гуглом. Более того, я не стеснялся гуглить сам, если забывал какие-то мелочи.

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

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

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

После, мы всей командой отправлялись на обед в ресторан и отпускали кандидата погулять и посмотреть город. Благо, в Европейской столице всегда найдётся на что поглядеть и чем себя занять.

Зачем всё это?

В первую очередь, мы хотели показать полный и максимально реалистичный путь от задачи в баг-трэкере до продакшна. Нам казалось честным рассказывать о всех процессах. Мы не скрывали потенциальные проблемы в коде и инфраструктуре. Честно говорили и об устаревших фреймворках и о странностях. Но и показывали себя, как слаженную и крепкую команду.

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

По отзывам кандидатов (как тех, кто принимал оффер, так и тех, кто отказывался) такой подход им нравился.

Важным и приятным бонусом является фидбек, высказаный кандидатом. Это возможность свежим взгядом оценить сложность процессов внутри команды. Так часто бывает, что ты привыкаешь к каким-то шагам, и даже забываешь зачем они нужны. А тут тебя спросят "ой а почему так?", и ты поймёшь, что не знаешь ответа. Это полезно.

Но это всё долго и дорого

Увы, но это и правда, очень затратный процесс. А зачастую, что-то подобное делать не возможно из-за юридических вопросов и NDA. Наверное, дешевой альтернативой будет корпоративный инженерный блог.

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

Выводы

У нас был кандидат, который в целом нам понравился, но он решил, что не хочет работать в нашем формате. Не помню, уж что ему не понравилось, кажется парное программирование. Я считаю, что это хороший показатель успеха. Мы заранее получили отказ, сэкономив немало денег на релокейт того программиста из Берлина. Такой кандидат ушёл бы из компании достаточно быстро.

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

А ты что думаешь? Видел подобное хоть раз? Может у тебя в компании есть такой этап?

Эти и другие вопросы обсуждаем в канале https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Подписывайтесь и рассказывайте друзьям.

МS.