Главная » Хабрахабр » Человек-функция или перестаньте нанимать технологии

Человек-функция или перестаньте нанимать технологии

Не думал что соберусь писать об этом статью и тем более на Хабр, но, как говорится, «с этим надо что-то делать». Наболело.

За 10 лет своей карьеры сначала Системным Администратором, потом Системным Инженером и DevOps-ом, успев побыть простым исполнителем, тех- и тим-лидом, я посетил и провел десятки собеседований в компаниях разного размера в разных странах, учувствовал в формировании требований при поиске сотрудников и… ребята, найм — это мрак.

Я думаю, что тот стиль и способ найма, который живет и процветает сейчас, вредит и сотрудникам, и компаниям.

Попробую объяснить почему.

Кого ищет работодатель?

Все зависит от того, в какой плоскости рассматривать этот вопрос.
С точки зрения бизнеса – работодатель ищет единицу, которая сможет выполнять требуемые функции при минимальных затратах.

требования несколько меняются и детализируются – им нужен человек, зарплата которого укладывается в бюджет, которого можно найти на рынке имеющимися средствами и который будет выполнять задачи, которые ему поставит его руководитель в интересах бизнеса. На уровне руководителей департаментов, заместителей директоров и т.д.

На этом уровне обычно определяются конкретные деньги, которые бизнес готов платить за выполнение работы и с этого уровня исходит распоряжение HRам по поиску сотрудника, который подходит под критерии, а потом те кандидаты, которые прошли первые фильтры, приходят на собеседование.

Вот об этом всём стоит поговорить.

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

И все это работает отвратительно.

В зависимости от структуры компании и компетенции руководителей список требований формируется в стилях от «нам нужен frontend-программист, требования обычные», до «нам нужен frontend-программист со знанием <список из 30 пунктов>, стажем работы не менее 23 месяцев и обязательным опытом в FMCG компаниях не менее 2 лет».

Иногда даже привлекаются технически компетентные сотрудники, которым дается задание «сформируйте полный список навыков и технологий, которые вы используете в письменном виде» и все это с некоторыми корректировками уезжает в вакансию в блок «требования».
В еще более редких случаях, поступает задание «сформируйте тест для проверки необходимых знаний», что порождает различные тестовые задания на Hackerrank, состоящие из задач, бесконечно далеких от рабочих.

Какой бы подход к формированию требований из этого диапазона не использовался – он плохо работает.

Почему это плохо работает?

Стек технологий в индустрии огромен.
Больше, чем можно представить или написать в требованиях (хотя бывают и трехстраничные листинги требований).
Более того – стек в компании тоже рано или поздно поменяется.
Поменяются руководители, изменится программная платформа, придет новый вендор с выгодным предложением.
А вот люди – останутся. Если не сбегут или не придется их уволить, потому что новые функции они выполнять не в состоянии.

Оно психологически безопасно и снимает нагрузку с головы. Желание формализации понятно.

Но это мешает найму и дальнейшей работе.

Или на первую страницу выдачи HH/Indeed/Glassdoor, на вакансии с портянками требований и знания технологий. Специалисты по найму пропускают огромное количество талантливых людей просто потому, что не совпали ключевые слова.
Посмотрите на LinkedIn с его «у вас совпадает 27% навыков с этой вакансией».

Чаще всего – они и сами не знают никаких ответов кроме тех, что написаны в опроснике и не поймут правильный ответ, если он будет нестандартным.
Особенно, когда в компании много специалистов с различной специализацией, а правила и вопросы одни для всех. Следуя правилам, интервьюеры задают бредовые вопросы, понимая, что они не имеют никакого отношения к будущим задачам.

Не следуя правилам, интервьюеры начинают опираться на свои, возможно очень специфичные знания и задают вопросы которые опять же, никак не помогают определить, как человек будет выполнять задачи, которые будут перед ним стоять.
Он может быть с другого проекта по разработке специфичной системы, может очень (не)любить ML, может (не)любить Go/Python/Perl/C#/C++/C/Java/Scala, презирать или обожать Puppet/Salt/CFEngint/Chef и т.д.
Просто потому, что он человек и у него не на что опереться, кроме как на собственный опыт и вкус.

Такие собеседования — стресс для всех причастных.

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

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

Списки, ключевые слова, теги, списки вопросов для собеседований в стиле «сколько аргументов принимает функция substring» — они все портят.

7 вместо 3. Подобная система отбора с одной стороны порождает профессиональных «проходителей собеседований», попадающих на позиции, которые объективно не тянут, с другой – мешают нормальным специалистам прийти работать в компанию и принести ей много пользы, потому что они использовали Puppet вместо Salt, писали на Python 2. 5, использовали Symphony вместо Laravel, Docker, а не RKT, Docker Swarm, а не Kubernetes или etcd, а не Consul.

Все придется менять, функция работника тоже может изменится вместе с окружением и проектами.
В подавляющем большинстве компаний нет задач, где нужно знать 8 алгоритмов сортировки и помнить все функции Spring Boot Core или какие библиотеки npm он знает.
Нет никакой разницы, какую систему configuration management знает человек на старте или сколько аргументов к java он помнит.
Если человек знает, как выполнять определенную функцию в заданных рамках, то это совершенно не значит, что он хороший специалист.
Это значит только то, что он, по стечению обстоятельств, умеет выполнять определенную функцию здесь и сейчас.

На самом деле, исходя из моего опыта, для кандидата (и будущего успешного сотрудника) гораздо важнее другие критерии: Все инструменты меняются и заменяются.
Через 1-2 года текущие знания об инструментах будут неактуальны, через 5 лет о большинстве никто не вспомнит.

  • Нужно быть адекватным, уметь рассуждать и учиться, уметь делать обоснованные предположения о том, что не знаешь.
  • Нужно иметь базовые знания об операционных системах, сетях и актуальных технологиях.
  • Нужно понимать, что лежит в основе инструментов, которые используются и почему эти инструменты они нужны (или не нужны).
  • Нужно иметь убеждения о том, как нужно работать и силу им следовать.
  • Короче – нужно уметь мыслить в широком смысле.

Посмотрите на крупные успешные компании, на их требования к кандидатам. Они минимально конкретизируют технологии, просто чтобы обозначить некую базу, на которую стоит опираться.

Вот, что пишет в своих вакансиях Яндекс в позиции Системного Администратора в требованиях:

  • опыт администрирования 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% вопросов, я не знаю, почему он завалил проект» больше не будут работать. Придется нести расширенную ответственность за результат найма, т.к.

Увеличится входящий поток кандидатов, в том числе неподходящих.

Но, подумайте сами – это ведь окупится?


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Как распознавание лиц помогает находить тестовые телефоны

Привет, хабровчане! В EastBanc Technologies ведётся большое количество проектов, связанных с мобильной разработкой. В связи с чем необходим целый зоопарк устройств для тестирования на всех этапах. И, что характерно, каждый отдельный девайс постоянно оказывается нужен самым разным людям, а найти ...

Security Week 39: на смерть Google+

На прошлой неделе Google объявил (новость) о закрытии социальной сети Google+, но сделано это было достаточно необычно. Компания Google вообще не стесняется закрывать проекты, которые по разным причинам не взлетели. Многие до сих пор не могут простить компании отказа от ...