Первая история: Джаскелл Однажды мне рассказали о компании, которая написала бэкенд на Java и хотела нанять талантливых разработчиков.
Чтобы их привлечь, эта компания разместила вакансии на Haskell, а затем убедила этих кандидатов все-таки писать на Java. На мой взгляд, это не очень приятно (развешивать ложную рекламу нехорошо), но сегодня нас интересует сама идея этой тактики: умный разработчик важнее того стека, который он использовал недавно.
Вот короткое видео, иллюстрирующее эту идею:
Вторая история: Котлин
Когда мы нанимали разработчиков для проекта Kotlin, мы не могли ограничиться только теми, кто уже разбирался в разработке компиляторов.Таких людей на рынке было просто слишком мало, а наш проект еще не был всемирно известен.
Именно тогда я начал учиться узнавать на собеседованиях тех, кто мог разобраться на месте и продвинуть проект вперед, хотя раньше я работал в другой сфере.
Это оказалось не так уж и сложно: ведь любой программист каждый день использует какой-то язык программирования, и на собеседовании можно рассказать о том, как все это работает внутри.
Любознательные инженеры знают, как устроены их любимые игрушки, поэтому проблем с темами для разговора не возникло.
По сути, мы набирали в Kotlin тех, кто хорошо понимал не то, как работает компилятор, а что такое виртуальная машина, как работают блокировки потоков в ОС, как работают структуры данных, которыми любой из нас пользуется каждый день и т. д. Со временем Kotlin стал известным и успешным, и нам стало проще нанимать людей с профильным опытом.
Они принесли в команду очень ценные знания, и вместе мы сделали крутой, востребованный продукт. Но по сей день, насколько мне известно, опыт работы с компиляторами не является обязательным условием при приеме на работу в Котлине.
Из этой истории у меня два вывода:
- Есть условия, при которых выгоднее нанимать умных разработчиков, а не специалистов в узкой области.
- Специалисты в узкой области дают большой импульс, и вам обязательно стоит нанять их.
История третья: Альтер
В настоящее время мы набираем разработчиков в Изменить .Здесь мы пишем не компиляторы, а платформу для психотерапии.
Ничего особенно экзотичного: Python, Django, MySQL и всё.
Мы помогаем сотням людей каждый день.
Но принципы найма остаются прежними: стек мы упоминаем в описании вакансии только в разделе «Было бы плюсом, но не обязательно», потому что кандидаты хотят знать, на чем написан проект. Не было ни одного кандидата, которого бы мы не рассмотрели из-за стека.
Но по какой-то причине Время от времени мы слышим от друзей и знакомых: «а я хотел присоединиться к вашей команде, но я пишу на Java, а вы используете Python».
Поэтому я решил написать этот пост. Важные заявления об отказе от ответственности:
- Мы нанимаем опытных разработчиков (Senior и Middle), обучать с нуля нам невыгодно.
Когда мы берем Middle, мы убеждаемся, что есть потенциал роста до Senior квалификации.
Если кандидат навсегда застрянет на уровне Middle, в маленькой команде такой разработчик не особо нужен.
- В ходе интервью мы обсуждаем общие для всех бэкенд-стеков вопросы: как работает HTTP, что сделать, чтобы сервис поддерживал нагрузку, как проектировать схемы баз данных, как находить и исправлять ошибки и т.д.
Зачем это вообще делать? Вам не хватает питонистов?
Если у вас достаточно, мы рады за вас :) Делать это стоит только в том случае, если затраты на поиск разработчиков нужного стека превышают затраты на онбординг в этот стек.Понятно, что если у вас есть очередь отличных специалистов, знающих немного Django от и до (или какой у вас бэкграунд), то вы не будете смотреть на кандидатов с опытом работы в FastAPI, PHP, Java и т.д. А если вы неохотно готовы взять одного кандидата из десяти, и он вам скажет, что подумает неделю, потому что у него запланировано еще три предложения, тогда вам, наверное, имеет смысл подумать, как расширить воронку.
И, судя по общению с коллегами из других компаний, ситуация большинства работодателей в последнее время больше похожа на второй вариант. То есть основная идея проста: человек, хорошо освоивший один инструмент, быстро переучит другой, весьма похожий .
Если у опытного человека возникли проблемы с освоением нового стека, то, вероятно, он достиг своего потолка, что не является хорошим знаком.
Это дает нам возможность нанимать умных программистов.
со всего рынка , и не только из какой-то его части.
Еще один момент, хотя и не столь важный: если кандидат выберет компанию, а не стек, можно предположить, что у него будет больше мотивации остаться в этой компании, а не переехать в другое место через полгода.
Это мелочь, но приятно.
Это как Джоэл: Умный и добивается цели?
Еще в 2006 году Джоэл Спольски написал в своей книге Партизанское руководство по проведению собеседований (версия 3.0) , что достаточно знать о кандидате две вещи: умный и добивающийся цели.Зачем тогда этот пост? Во-первых, многие, а особенно кандидаты, до сих пор считают, что стек — это первый фильтр, отсеивающий вакансии и резюме.
Я бы хотел, чтобы больше людей поняли, что это не всегда так.
Во-вторых, если вы ограничитесь «умным и доводящим дело до конца», онбординг может оказаться существенно дороже, чем если бы вы наняли человека, который решал аналогичные задачи, просто используя другие инструменты.
Итак, для себя мы считаем, что бэкендер-джавист превращается в бэкендер-питониста, как на видео выше, а что насчет других специализаций — это сложный вопрос, который нужно решать индивидуально в каждом конкретном случае.
Обычному читателю я готов порекомендовать только быстрый переход в другой стек, а не в другую специализацию.
Всегда ли это работает так хорошо?
Как уже говорилось выше, главное, о чем стоит задуматься, окупятся ли затраты на онбординг.При этом необходимо учитывать несколько существенных моментов.
Не каждый разработчик хочет менять стек
- Кто-то привязан душой к любимому фреймворку и никогда его не «предаст».
Ну это не наш клиент, что нам делать?
- Некоторые люди боятся, что не смогут быстро освоить новый стек.
Даже если рядом есть отзывчивые коллеги, готовые дать совет. Что ж, он имеет право, он тоже не наш клиент.
- Как правило, это связано с тем, что нужно решить другие проблемы: если вчера я написал обычный бекенд на PHP, а завтра нужно сделать хайлоад на Java, то онбординг будет достаточно сложным.
- Некоторые платформы/проекты по-прежнему используют абстракции более низкого уровня.
PHP, Node.js и Python более-менее избавляют от необходимости думать о потоках, а в Java при желании можно отведать немало этого счастья.
Это зависит от того, как написан ваш Java-проект. Не следует ожидать, что внедрение питониста в многопоточность будет таким же простым, как внедрение Javaиста в Django.
- Если кандидат не очень уверенно владеет своим основным языком программирования, то освоить новый ему будет непросто.
- Если HTTP-заголовки или SQL для кандидата — темный лес, времени менять стек нет.
- Если кандидат вообще не понимает, что «под капотом» делает его любимый фреймворк, ему будет сложно изучить новый фреймворк, который «под капотом» делает что-то другое.
Одно дело — учиться самостоятельно, другое — когда вокруг сидят люди, которые знают новый стек вдоль и поперёк.
Необходимо только передавать знания, а для этого важно:
- Поощряйте вопросы и запросы на рассмотрение
- Быстро отвечайте на вопросы, чтобы разблокировать друга (если вопросы сразу кажутся непонятными, дружелюбно спросите, что не так)
- Вежливо и разумно предлагать идиомы и различные приемы при проверке кода.
- Не ругайте стопку, из которой вышел человек, за недостаточно православное мировоззрение.
Получается, что для юниоров такой подход не работает?
Вот как посмотреть.С одной стороны, чтобы быстро освоить новый стек, нужно хорошо знать старый, а Джуниор еще не успел его толком понять.
С другой стороны, если вы толком не знали старый стек, сколько вы потеряли, перейдя на новый? На самом деле с джуниорскими разработчиками вопрос лежит вообще в другой плоскости.
В принципе, не всем командам имеет смысл нанимать неопытных людей.
То есть, если честно, скорее всего на предложение «нам сложно искать сеньоров, давайте наберем юниоров и доучим обучение на месте», ответ будет: «отличная идея, но нам это невыгодно».
Не буду здесь вдаваться в глубокий анализ, но в целом понятно, что за обучение юниоров вы платите не только их зарплатой, но и большим количеством внимания, которое более опытные разработчики уделяют их обучению.
И в это время они могли бы продвинуть проект вперед. Понятно, что есть очень энергичные юниоры, которые супер-супер быстро учатся, и тогда учить их мегаприбыльно, но если вы уже знаете, как нанимать таких юниоров, то вы, вероятно, либо преподаете для хобби в хорошем университете, либо вы у вас такие бюджеты на найм, что этот пост вам не очень интересен.
Не является ли смена стека шагом назад в вашей карьере?
Рекрутеры, а иногда и кандидаты, говорят: если я перейду на новый язык/стек, я не буду владеть им так же хорошо, как на привычном языке/стеке — я стану менее ценным специалистом! Честно говоря, мне немного грустно от такого подхода к жизни, но я стараюсь отнестись с пониманием и любезно это объяснить.
- выучить синтаксис языка сложно только с первого раза, а вот выучить третий или пятый язык гораздо проще,
- ваша ценность как специалиста заключается не в том, что вы знаете синтаксис языка и название стандартных функций фреймворка, а в том, что вы понимаете, как должна работать система как в деталях, так и в целом,
- Изучение нового иногда дает свежий взгляд на знакомые вещи, и это приносит удовольствие многим людям.
Вопрос к зрителям
Как вы думаете: это работает и для фронтенд-разработчиков? В настоящее время мы пишем их вакансии что нам нужен опыт работы с React.js, но может быть, мы зря это делаем? В опросе могут участвовать только зарегистрированные пользователи.Войти , Пожалуйста.
А как насчет фронтендеров? 74,38% Фронтендерам перейти на новый фреймворк не сложнее, чем бэкендерам на новый стек (даже язык менять не нужно!) 119 8,75% Фронтендерам труднее перейти на новый фреймворк, чем для бэкендеров на новый стек 14 16,88% Вы не понимаете, это другое! Проголосовали 27 160 пользователей.
60 пользователей воздержались.
Теги: #Разработка сайтов #Управление персоналом #frontend #backend #найм разработчиков
-
Миллион Книг И Как Их Не Читать
19 Oct, 24 -
Без Тз: Почему Клиент Этого Не Хочет
19 Oct, 24 -
Магазин Приложений В Реальной Жизни
19 Oct, 24
