Не думал что соберусь писать об этом статью и тем более на Хабр, но, как говорится, «с этим надо что-то делать». Наболело.
За 10 лет своей карьеры сначала Системным Администратором, потом Системным Инженером и DevOps-ом, успев побыть простым исполнителем, тех- и тим-лидом, я посетил и провел десятки собеседований в компаниях разного размера в разных странах, учувствовал в формировании требований при поиске сотрудников и… ребята, найм — это мрак.
Я думаю, что тот стиль и способ найма, который живет и процветает сейчас, вредит и сотрудникам, и компаниям.
Попробую объяснить почему.
Кого ищет работодатель?
Все зависит от того, в какой плоскости рассматривать этот вопрос.
С точки зрения бизнеса – работодатель ищет единицу, которая сможет выполнять требуемые функции при минимальных затратах.
На уровне руководителей департаментов, заместителей директоров и т.д. требования несколько меняются и детализируются – им нужен человек, зарплата которого укладывается в бюджет, которого можно найти на рынке имеющимися средствами и который будет выполнять задачи, которые ему поставит его руководитель в интересах бизнеса.
На этом уровне обычно определяются конкретные деньги, которые бизнес готов платить за выполнение работы и с этого уровня исходит распоряжение HRам по поиску сотрудника, который подходит под критерии, а потом те кандидаты, которые прошли первые фильтры, приходят на собеседование.
Вот об этом всём стоит поговорить.
Для того, чтобы запустить подбор персонала, нужно знать кого искать.
Для этого формируются требования к кандидатам, претендующим на вакансию.
В больших компаниях ради стандартизации есть еще список правил «как проводить собеседования» и даже внутренние тренинги с присвоением звания «лицензированный интервьюер».
И все это работает отвратительно.
В зависимости от структуры компании и компетенции руководителей список требований формируется в стилях от «нам нужен frontend-программист, требования обычные», до «нам нужен frontend-программист со знанием <список из 30 пунктов>, стажем работы не менее 23 месяцев и обязательным опытом в FMCG компаниях не менее 2 лет».
Иногда даже привлекаются технически компетентные сотрудники, которым дается задание «сформируйте полный список навыков и технологий, которые вы используете в письменном виде» и все это с некоторыми корректировками уезжает в вакансию в блок «требования».
В еще более редких случаях, поступает задание «сформируйте тест для проверки необходимых знаний», что порождает различные тестовые задания на Hackerrank, состоящие из задач, бесконечно далеких от рабочих.
Какой бы подход к формированию требований из этого диапазона не использовался – он плохо работает.
Почему это плохо работает?
Стек технологий в индустрии огромен.
Больше, чем можно представить или написать в требованиях (хотя бывают и трехстраничные листинги требований).
Более того – стек в компании тоже рано или поздно поменяется.
Поменяются руководители, изменится программная платформа, придет новый вендор с выгодным предложением.
А вот люди – останутся. Если не сбегут или не придется их уволить, потому что новые функции они выполнять не в состоянии.
Желание формализации понятно. Оно психологически безопасно и снимает нагрузку с головы.
Но это мешает найму и дальнейшей работе.
Специалисты по найму пропускают огромное количество талантливых людей просто потому, что не совпали ключевые слова.
Посмотрите на LinkedIn с его «у вас совпадает 27% навыков с этой вакансией». Или на первую страницу выдачи HH/Indeed/Glassdoor, на вакансии с портянками требований и знания технологий.
Следуя правилам, интервьюеры задают бредовые вопросы, понимая, что они не имеют никакого отношения к будущим задачам. Чаще всего – они и сами не знают никаких ответов кроме тех, что написаны в опроснике и не поймут правильный ответ, если он будет нестандартным.
Особенно, когда в компании много специалистов с различной специализацией, а правила и вопросы одни для всех.
Не следуя правилам, интервьюеры начинают опираться на свои, возможно очень специфичные знания и задают вопросы которые опять же, никак не помогают определить, как человек будет выполнять задачи, которые будут перед ним стоять.
Он может быть с другого проекта по разработке специфичной системы, может очень (не)любить ML, может (не)любить Go/Python/Perl/C#/C++/C/Java/Scala, презирать или обожать Puppet/Salt/CFEngint/Chef и т.д.
Просто потому, что он человек и у него не на что опереться, кроме как на собственный опыт и вкус.
Такие собеседования — стресс для всех причастных.
Большинству собеседующих все-таки неприятно писать отрицательные отзывы на кандидатов. Впечатление кандидатов после таких собеседований тоже далеки от позитивных. Руководители расстроены от того, что вакансия не закрыта, HRы вынуждены рассылать все больше и больше писем и сообщений, недоумевая, чем же не подошел предоставленный ими кандидат, ведь «под требования же отлично подходит».
Эти проблемы рождаются от того, что система поиска сотрудников сформирована для того, чтобы найти не хорошего работника с головой, а некую функцию, пытаясь через максимальное количество требований ее описать.
Списки, ключевые слова, теги, списки вопросов для собеседований в стиле «сколько аргументов принимает функция substring» — они все портят.
Подобная система отбора с одной стороны порождает профессиональных «проходителей собеседований», попадающих на позиции, которые объективно не тянут, с другой – мешают нормальным специалистам прийти работать в компанию и принести ей много пользы, потому что они использовали Puppet вместо Salt, писали на Python 2.7 вместо 3.5, использовали Symphony вместо Laravel, Docker, а не RKT, Docker Swarm, а не Kubernetes или etcd, а не Consul.
Все инструменты меняются и заменяются.
Через 1-2 года текущие знания об инструментах будут неактуальны, через 5 лет о большинстве никто не вспомнит. Все придется менять, функция работника тоже может изменится вместе с окружением и проектами.
В подавляющем большинстве компаний нет задач, где нужно знать 8 алгоритмов сортировки и помнить все функции Spring Boot Core или какие библиотеки npm он знает.
Нет никакой разницы, какую систему configuration management знает человек на старте или сколько аргументов к java он помнит.
Если человек знает, как выполнять определенную функцию в заданных рамках, то это совершенно не значит, что он хороший специалист.
Это значит только то, что он, по стечению обстоятельств, умеет выполнять определенную функцию здесь и сейчас.
На самом деле, исходя из моего опыта, для кандидата (и будущего успешного сотрудника) гораздо важнее другие критерии:
- Нужно быть адекватным, уметь рассуждать и учиться, уметь делать обоснованные предположения о том, что не знаешь.
- Нужно иметь базовые знания об операционных системах, сетях и актуальных технологиях.
- Нужно понимать, что лежит в основе инструментов, которые используются и почему эти инструменты они нужны (или не нужны).
- Нужно иметь убеждения о том, как нужно работать и силу им следовать.
- Короче – нужно уметь мыслить в широком смысле.
Посмотрите на крупные успешные компании, на их требования к кандидатам. Они минимально конкретизируют технологии, просто чтобы обозначить некую базу, на которую стоит опираться.
Вот, что пишет в своих вакансиях Яндекс в позиции Системного Администратора в требованиях:
- опыт администрирования Unix/Linux — более трех лет;
- опыт администрирования open source приложений (веб-серверы, базы данных, почтовые серверы и т.д.);
- знания сетевых технологий TCP/IP;
- опыт программирования на скриптовых языках (shell, python, perl);
- умение перенимать опыт коллег и делиться с ними собственным;
- последний год вы работали в аналогичной должности.
И вот, что в пожеланиях:
- опыт проектирования систем, работающих непрерывно и бесперебойно (24х7х365);
- аналитические навыки предотвращения и быстрого устранения неисправностей.
А вот требования к позиции SRE в Google:
- BS degree in Computer Science or related technical field involving coding (e.g., physics or mathematics), or equivalent practical experience.
- Experience with algorithms, data structures, complexity analysis and software design.
- Experience in one or more of the following: C, C++, Java, Python, Go, Perl or Ruby.
И вот пожелания:
- Interest in designing, analyzing and troubleshooting large-scale distributed systems.
- Systematic problem-solving approach, coupled with strong communication skills and a sense of ownership and drive.
- Ability to debug and optimize code and automate routine tasks.
Гораздо лучше уделить больше внимания в описании вакансии тому, чем занимается компания и чем придется заниматься кандидату, чем перечислять все 10 фреймворков, которые используются в ваших проектах.
Измените и подход к собеседованиям.
Спрашивайте на собеседованиях основы, просите рассуждать вслух, задавайте широкие вопросы (и будьте готовы услышать не единожды ответ, который для вас станет сюрпризом), стройте диалог, общайтесь, делитесь информацией. Ищите точки соприкосновения, пытайтесь понять как человек думает и почему он так думает.
Большинство людей, которым я задавал этот вопрос (а так же я сам), сходятся во мнении, что на самом деле 15-20 минут общения хватает, чтобы убедиться что человек подходит и определить его уровень и в пределах 10 минут нужно на то, чтобы понять, что человек не подходит совершенно.
При этом, тесты и глубокие технические опросы практически не влияют на результат.
Да, на это время придется напрячь и навыки общения тем, кто проводит собеседования.
Высший менеджмент должен научиться доверять тем, кто эти собеседования проводит и кому, в будущем, с нанятыми людьми работать.
Придется отказаться от тегов, безумной (и бездумной) фильтрации и излишней, но такой спокойной, стандартизации.
Придется нести расширенную ответственность за результат найма, т.к. «вот его результаты теста, он ответил на 98% вопросов, я не знаю, почему он завалил проект» больше не будут работать.
Увеличится входящий поток кандидатов, в том числе неподходящих.
Но, подумайте сами – это ведь окупится?
Автор: Anton Kostenko
