Не надо требовать определенного технологического опыта от Senior+ разработчиков

Разговор, который я (слишком) много раз вел в нашей отрасли:

Вы: Я ищу senior инженера. Знаешь кого-нибудь хорошего?
Я: Отлично, я знаю хороших людей! Как насчет $A?
Вы: Не пойдет. Нам нужен кто-то, имеющий как минимум $X лет в $ТЕХНОЛОГИИ
Я: Почему?
Вы: Нужно быстро набрать скорость»
Я: ☹️

Здесь делается много предположений, из которых исходит или не исходит ваша организация:

• Знание $ТЕХНОЛОГИИ в течение $X лет, означает, что новые сотрудники смогут быстро освоить вашу кодовую базу на $ТЕХНОЛОГИИ, потому что им не нужно будет изучать ее в рабочее время.
• Все ваше существующее использование $ТЕХНОЛОГИИ настолько совершенно идиоматично, что любому, кто имеет $X-летний опыт работы в $ТЕХНОЛОГИИ будет просто понять код.
• Основным препятствием на пути к быстрому росту будет изучение $ТЕХНОЛОГИИ, а не изучение вашей системы контроля версий, системы развертывания, инженерной культуры компании и т.д.
• Имеется достаточное количество инженеров, обладающих как минимум $X лет в $ТЕХНОЛОГИИ, которые захотят работать в вашей организации за вознаграждение, которое вы готовы платить, и ослабление этих ограничений не приведет к лучшему найму.
• Такая краткосрочная оптимизация для новых сотрудников, будет хорошим решением в среднесрочной/долгосрочной перспективе

Вы также думали или не думали о следующем:

• Большая часть работы senior+ инженера включает в себя задачи, не связанные с написанием на $ТЕХНОЛОГИИ, например базы данных, развертывание, менторинг, устранение проблем, code review, сотрудничество с руководством/продуктом/дизайном/продажами и т.д.
• Инженеры, которые уже имеют опыт в более чем одной $ТЕХНОЛОГИИ, часто могут очень быстро изучать новые.
• Опыт работы с более чем одной $ТЕХНОЛОГИЕЙ и различными парадигмами $ТЕХНОЛОГИЙ часто могут помочь инженеру лучше писать на всех языках.
• Ваш выбор $ТЕХНОЛОГИИ может быть не лучшим решением проблемы, и инженер с опытом работы на других языках может помочь вам рассмотреть будущие альтернативы.
• Вы не можете использовать $ТЕХНОЛОГИЮ в среднесрочной/долгосрочной перспективе.
• $ТЕХНОЛОГИЯ может быть не тем, в чем многие люди имеют $X лет опыта (но хотят учиться).

По моему опыту, сочетание этих предположений и отсутствие размышлений обо всем вышеперечисленном (и многом другом!) означает то, что я считаю антипаттерном. Не надо требовать от инженеров опыта работы с конкретной технологией! Вы можете просто учитывать это при принятии решения о приеме на работу — рассматривая двух идентичных кандидатов, тот, у кого больше опыта в этом языке, может быть более желательным.

Если вы перефразируете свои объявления о вакансиях, чтобы убрать эту $ТЕХНОЛОГИЮ как «требование» и заменить ее на «желательную» (или просто упомите, что вы ее используете), вы обнаружите, что сможете привлечь больше, лучших кандидатов в своем канале приема на работу (особенно из-за большой группы разработчиков, которые часто не удосуживаются подавать заявки, если они не соответствуют «требованиям»).

Это может потребовать изменения процесса собеседования. Если большая часть вашего процесса предполагает рабочее знакомство с данным языком, и вы ожидаете, что кандидат сможет писать на этом языке без какой-либо помощи, то в новых условиях кандидат и интервьюер будут иметь ужасный опыт. В идеале ваш процесс должен позволить кандидату использовать язык, который ему удобен и/или представлять собой процесс сопряжения «открытой книги» технологий, которые вы используете внутри компании, с опытом кандидата. Кроме того, чем более опытный кандидат или более высокая позиция, тем больше процесс собеседования должен быть посвящен коммуникациям, передовым инженерным методам, архитектуре и т.д., а не только программированию.

Это может быть непросто изменить, но это один лучших подходов к интервьюированию разработчиков.

Источник