Первая история: 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, но, может, зря мы так делаем?
