Первая история: Jaskell
Мне рассказывали когда-то о компании, которая писала бекенд на Java и хотела нанимать талантливых разработчиков. Чтобы привлечь их, эта компания размещала вакансии на Haskell, и потом уговаривала этих кандидатов все-таки писать на Java. По-моему, это не очень красиво (вешать ложное объявление — нехорошо), но нас сегодня интересует сама идея, лежащая в основе этой тактики: толковый разработчик важнее, чем стек, которым он пользовался в последнее время.
Вот небольшое видео, иллюстрирующее эту идею:
Вторая история: Kotlin
Когда мы нанимали разработчиков в проект Kotlin, мы не могли ограничиться только теми, кто уже разбирался в разработке компиляторов. На рынке было просто слишком мало таких людей, а наш проект еще не имел мировой известности. Тогда я и начал учиться распознавать на собеседованиях тех, кто сможет разобраться на месте и будет двигать проект вперед, хотя раньше работал в другой сфере.
Это оказалось не так-то сложно: все-таки любой программист пользуется каким-то языком программирования каждый день, и на собеседовании можно поговорить про то, как все это работает внутри. Любознательные инженеры знают, как устроены их любимые игрушки, так что с темами для разговора проблем не было.
По сути, мы брали в Kotlin тех, кто хорошо понимал не как работает компилятор, а что такое виртуальная машина, как устроены блокировки потоков в ОС, как устроены структуры данных, которые любой из нас использует каждый день и т.д.
Со временем Kotlin стал известным и успешным, и нам стало проще нанимать людей с профильным опытом. Они принесли в команду очень ценные знания, и мы все вместе сделали крутой востребованный продукт. Но по сей день, насколько я знаю, опыт именно в компиляторах не является обязательным условием для найма в Kotlin.
Из этой истории у меня два вывода:
Бывают условия, при которых выгоднее брать просто толковых разработчиков, а не специалистов в узкой области.
Специалисты в узкой области дают большой буст, и их обязательно надо тоже нанимать.
Третья история: Alter
Сейчас мы нанимаем разработчиков в Alter. Тут мы не компиляторы пишем, а платформу для психотерапии. Ничего особо экзотического: Python, Django, MySQL, вот это все. Каждый день помогаем сотням людей.
А принципы найма остались те же: мы упоминаем стек в описании вакансий только в разделе "Будет плюсом, но необязательно" потому, что кандидатам хочется знать, на чем написан проект. Не было ни одного кандидата, которого мы не стали бы рассматривать из-за стека.
Но почему-то мы время от времени слышим от знакомых и знакомых знакомых: "а вот я хотел(а) к вам в команду, но я на Java пишу, а у вас Python". Так я и решил написать этот пост.
Важные оговорки:
Мы нанимаем опытных разработчиков (Senior и Middle), учить с нуля нам не выгодно. Когда берем Middle, следим, чтобы был потенциал роста до квалификации Senior. Если кандидат застрянет на уровне Middle навсегда, в небольшой команде такой разработчик не очень нужен.
На собеседовании мы обсуждаем вопросы, общие для всех бекендовых стеков: как работает HTTP, что делать, чтобы сервис держал нагрузку, как проектировать схемы БД, как искать и устранять ошибки и т.д.
А зачем вообще так делать? Вам что, питонистов не хватает?
Если вам хватает, мы за вас рады :)
Делать так стоит, только если затраты на поиск разработчиков на нужном стеке превышают затраты по онбордингу в этот стек. Ясное дело, если у вас очередь отличных специалистов, которые вдоль и поперек знают какую-нибудь Django (или на чем там у вас бек), то вы не будете смотреть кандидатов с опытом на FastAPI, PHP, Java и т.д. А если вы из десяти кандидатов скрепя сердце готовы взять одного, а он вам говорит, что неделю подумает, потому что у него тут еще три оффера намечается, то, наверное, вам имеет смысл подумать, как расширить воронку.
И, судя по общению с коллегами из других компаний, ситуация большинства работодателей в последнее время больше похожа на второй вариант.
То есть фундаментальная идея проста: человек, хорошо освоивший один инструмент, быстро переучится на другой, достаточно похожий. Если опытному человеку сложно освоить новый стек, то он, вероятно, достиг своего потолка, а это не очень хороший знак. Это дает нам возможность нанимать толковых программистов со всего рынка, а не только с некоторой его части.
Еще один момент, хоть и не такой важный: если кандидат выбирает компанию, а не стек, можно предположить, что он будет больше мотивирован в этой компании и оставаться, а не перейдет через полгода в другое место. Мелочь, а приятно.
Это как у Джоэла: Smart and gets things done?
Еще в 2006 года Joel Spolsky писал в своем The Guerrilla Guide to Interviewing (version 3.0), что достаточно знать о кандидате две вещи: толковый и доводит дело до конца (smart and gets things done). Зачем же тогда этот пост?
Во-первых, многие, и особенно кандидаты, до сих пор верят, что стек — это первый фильтр, по которому отсеиваются вакансии и резюме. Мне бы хотелось, чтобы больше людей понимало, что это далеко не всегда так.
Во-вторых, если ограничиться "smart and gets things done", онбординг может оказаться существенно дороже, чем если брать человека, который решал похожие задачи, просто другими инструментами. Так что мы для себя считаем, что бекендер-джавист превращается в бекендера-питониста как на том видео выше, а вот что там насчет других специализаций — это уже сложный вопрос, который в каждом конкретном случае надо решать индивидуально. Массовому читателю я готов рекомендовать только быстрый онбординг в другой стек, не в другую специализацию.
А всегда ли это так хорошо работает?
Как уже было сказано выше, главное, о чем нужно подумать: окупятся ли затраты на онбординг. При этом надо учитывать несколько существенных моментов.
Не любой разработчик захочет поменять стек
Кто-то привязан душой к своему любимому фреймворку и ни за что не "предаст" его. Ну, это не наш клиент, что делать.
Кто-то боится, что не справится быстро освоить новый стек. Даже если вокруг будут отзывчивые коллеги, готовые подсказать. Ну, имеет право, тоже не наш клиент.
Некоторые стеки отличаются сильнее, и между ними переход значительно тяжелее
Как правило, это связано с тем, что и задачи надо другие решать: если вчера писал обычный бек на PHP, а завтра надо делать highload на Java, онбордиться будет сложновато.
Некоторые платформы/проекты до сих пор используют более низкоуровневые абстракции. PHP, Node.js и Python более-менее избавляют от необходимости думать о тредах, а в Java при желании можно этого счастья хлебнуть ого-го сколько. Это зависит от того, как написан ваш Java-проект. Не надо ожидать, что онбординг питониста в мультитрединг будет таким же легким, как онбординг джависта в Django.
Чтобы быстро поменять стек, надо хорошо понимать основы
Если кандидат не очень уверенно пользуется своим основным языком программирования, то и новый ему осваивать будет не просто
Если HTTP-заголовки или SQL для кандидата — темный лес, тут не до смены стека
Если кандидат совсем не понимает, что его любимый фреймворк делает под капотом, ему будет сложно освоить новый фреймворк, который делает под капотом что-то другое
Команда должна помогать осваивать новый стек. Одно дело учиться самому, другое — когда вокруг сидят люди, которые знают новый стек вдоль и поперек. Только нужно, чтобы знания передавались, а для этого важно:
Поощрять вопросы и запросы на ревью
Быстро отвечать на вопросы, чтобы разблокировать товарища (если вопросы выглядят моментально гуглящимися, дружелюбно спросить в личке, в чем дело)
Вежливо и аргументированно подсказывать идиомы и разные фишечки на code review
Не ругать стек, с которого человек пришел, за недостаточно православное мировоззрение
Получается, для джунов этот подход не работает?
Тут как посмотреть. С одной стороны, для быстрого освоения нового стека надо хорошо знать старый, а Junior еще не успел в нем толком разобраться. С другой стороны, если ты и старый стек не очень знал, много ли ты потерял, пересев на новый?
На самом деле с Junior разработчиками вопрос вообще лежит в другой плоскости. Далеко не всем командам в принципе имеет смысл брать неопытных людей. То есть, если честно, скорее всего на предложение "нам трудно искать синьоров, давайте наберем джунов и доучим на месте", ответ: "отличная идея, но нам это не выгодно".
Не буду тут углубляться в анализ, но в целом понятно, что за обучение джунов вы платите не только их зарплатой, но и большим количеством внимания, которое их обучению уделяют более опытные разработчики. А они в это время могли бы двигать проект вперед. Ясно дело, что бывают очень бодрые джуны, которые учатся супер-супер быстро, и тогда их учить мега-выгодно, но если вы уже умеете нанимать таких джунов, то вы, наверное, или в хорошем ВУЗе преподаете для души, или у вас такие бюджеты на хайринг, что вам этот пост не очень интересен.
А разве смена стека — это не шаг назад в карьере?
Рекрутеры, а иногда и кандидаты, говорят: если я перейду на новый язык/стек, я в нем не буду таким профи, как в своем привычном языке/стеке — это ведь я стану менее ценным специалистом!
Честно говоря, мне немного грустно от такого подхода к жизни, но я стараюсь отнестись с пониманием и ласково объяснить, что
синтаксис языка выучить — это только в первый раз сложно, а третий-пятый язык уже учится гораздо легче,
твоя ценность как специалиста состоит не в том, что ты знаешь синтаксис языка и название стандартных функций фреймворка, а в том, что ты понимаешь, как система должна работать и в деталях, и в целом,
изучение нового иногда дает свежий взгляд на знакомые вещи, а это приносит многим людям удовольствие.
Вопрос в зал
А вот как вы думаете: для фронтэндеров это тоже работает? Мы пока пишем в своих вакансиях, что нужен опыт на React.js, но, может, зря мы так делаем?
