
Какой HR (или рекрутер) не сталкивался с этой проблемой? Думаю, что все. Сколько копий сломано на эту тему? — Сейчас мы сломаем еще одно!
Предполагаю, что сейчас все кадровики начнут кидать в меня тапками. Но умные и опытные вполне себе поймут, что мои тезисы защищают не только интересы разработчиков, но и интересы службы персонала. И вот почему.
Начну с начала. Представьте себе, что вы — достаточно опытный разработчик, и вам платят примерно рублей так 800 в час (или больше, или меньше — не существенно, потому что все нижесказанное абсолютно верно для любого уровня зарплаты и для специалиста любого уровня подготовки, кроме junior, к ним действительно нужен особый подход). И вот к вам приходит письмо от рекрутера с красиво описанной вакансией и без указания грейда зарплаты. Вы заинтересовались проектами и пишете в ответку, что хотели бы узнать вилку зарплаты. «На том конце провода» специалист пишет вам красивые слова о том, что «зарплата по результатам собеседования», «нужно еще убедиться в уровне вашей квалификации и оценить его, без чего мы не можем сделать предложение», и так далее, и тому подобное. Вы думаете, большинство разработчиков продолжит общаться и проходить цепочку интервью? Ну джуны, которым очень нужна работа, безусловно, продолжат. И несомненно, что именно на них такой подход и был рассчитан изначально. Но потом этот подход как-то перекочевал на вакансии, где перечень компетенций совсем уже не джуновский. Почему так произошло — трудно сказать, но скорее всего, какой-нибудь маститый западный HR, никогда сам не занимавшийся программированием, написал книжку под впечатлением красивой сказочки об «эффективных менеджерах», книжка пошла в народ и наделала бед, как в свое время наделали бед в России книги Карнеги (надо сказать, весьма вздорные). Так вот, уважаемые рекрутеры — уважающий себя специалист уровня middle или, тем более, senior, 90 % вероятности, если и продолжит общение с вами, то будет делать это крайне неохотно и, скорее всего, откажется проходить процесс оценки его квалификации. Вы еще не поняли почему?
-
Во-первых, ему не интересно отвечать на «олимпиадные» вопросы и заниматься live-кодингом задачек на сообразительность, так как большинство таких проверок предназначены именно для отсеивания слабых джунов. Не интересно и даже отчасти унизительно нормальному сложившемуся уже специалисту заниматься такой ерундой. Некоторые рекрутеры работают «на слабо» и подкидывают кандидату какую-нибудь сентенцию вроде «ну это же вопросы/задачки для джунов, уж тем более вы на них легко ответите, ну давайте, попробуем». Да пробовали уже — стопитсот раз. А еще хорошие специалисты прекрасно знают, что человеческая память не безгранична, и из нее вылетает все, даже элементарные вещи. Вот вы помните подробности проекта, который делали неделю или год назад? Я не помню вообще. Но если открою старый код проекта, то легко и за короткое время восстановлю в памяти, что же там было. Почему? Потому что мозг уже натренирован решать продуктовые проблемы, и работает он в динамике в контексте задачи. А вот ответы на какие-то отдельные вопросы по списку аннотаций, какие бывают в Java или в Spring легко забыть, прежде всего для тех моментов, которыми на практике приходится пользоваться ну очень нечасто. И специалист прекрасно знает об этой ловушке сознания и не хочет позориться и мямлить, отвечая на вопросы по забытой теме. Тем более, что ему некогда заранее «готовиться к собеседованию» — скорее всего, он уже работает и занят на работе много часов в день, просто хочет сменить ее по какой-то разумной причине. И рекрутер прекрасно понимает, что чем больше таких вопросов на интервью удастся задать, тем легче будет психологически надавить на кандидата и добиться понижения грейда зарплаты в оффере (если он последует). Хорошему специалисту абсолютно все равно в течение рабочего процесса в продуктиве, что он что-то забыл напрочь — он просто провалится в документацию, все вспомнит и решит поставленную задачу. Потому что у него огромный опыт решения задач, он знает как их решать и не боится этого. А еще он уважает себя, дураки в ИТ не идут как правило, и он прекрасно видит такие уловки рекрутера, ему становится неприятно и он может запросто прервать общение с вами.
-
Во-вторых, давайте вспомним о финансовой стороне дела. Нет нет, я имею ввиду не зарплату (пока что). Давайте посчитаем затраты кандидата на проведение интервью. В среднем в серьезной фирме бывает около 3 этапов примерно по 2 часа. Это уже 6 часов х 800 рублей = 4800 рублей. А если потребуется выполнить тестовое задание часов этак на 10 объемом, то это еще 8000 рублей. После этого вдруг выясняется, что вы предлагаете уровень зарплаты, не отвечающий не только рынку, но и значительно ниже, чем тот, который интервьюируемый соискатель уже давно имеет на текущем месте работы. Итого, вы наказали этого соискателя на 12 800 его собственных кровных рублей, не говоря уже о потерянном времени. А ведь время для него (как и для любого человека вообще, в том числе для вас) — это самый ценный ресурс. В результате он бесплатно просадил 16 часов жизни, не заработав 12800 рублей и не получив желаемого оффера. Такой результат соискатель оценит как крайнюю форму не уважения к себе со стороны рекрутера и/или со стороны нанимающей фирмы.
А вы вообще представляете себе, что происходит с хорошим middle разработчиком, когда он открывает доступ к своему резюме? С ним происходит следующее — за неделю ему могут накидать от нескольких до нескольких десятков приглашений. Мой личный рекорд был 30 штук. И по каждому из них рекрутеры требовали (извините, «настоятельно просили») пройти хотя бы первый этап «еще вчера». А если вы соглашались и проходили первый этап — беседу с самим рекрутером, то приглашение на второй этап предлагалось провести через день-другой. От тридцати рекрутеров сразу! А как же текущая работа, ведь ее же тоже бросать нельзя! А как же еда, сон, отдых и нервное здоровье?! А когда резюме открывает senior, ему приходится еще тяжелее!
А теперь «бинго»! Вы забыли посчитать вашу потерянную зарплату и ваше потерянное время, уважаемый рекрутер! Это вы можете проделать сами. С учетом того, что единый подход к найму используется, вероятно, для всех кандидатов, умножьте это число на число претендентов, которых вы оцениваете. Допустим вы проинтервьюировали 4 соискателей в день, пусть мы будем считать, что вы также неплохо зарабатываете, не меньше 500 рублей в час в пересчете за месяц — вы потеряли за день 2000 рублей. Кроме того, с вашей подачи на втором этапе интервью из этих 4 человек, один или даже два senior разработчика на этапе технического интервью потеряли 800 рублей х 4 = 3200 рублей каждый из них. В месяце 22 рабочих дня — хотите продолжить умножение сами? Это все ваши прямые финансовые потери и потери вашей фирмы-работодателя, если такая политика продолжается постоянно и если вы предлагаете зарплату хотя бы немного ниже рынка. Вот теперь вы поняли к чему приводит не указание грейдов зарплаты к вакансии и бесплодное, глупое и непрофессиональное упорствование в этом тяжелом заблуждении, совершенно напрасно почерпнуто из глупых западных книжонок. А ведь и кандидат и еще больше — вы сами, могли бы сэкономить напрасно потраченное время и деньги, если бы сразу удалось отсеять тех кандидатов, которых ни в коем случае не устроят предлагаемые вами условия. Вы бы просто не тратили на них время и работали с теми, кто согласен на нужный грейд. Или, если таковых не оказалось, вы бы уже на раннем этапе поиска обнаружили несоответствие вашего предложения уровня зарплаты рынку, и исправили бы ситуацию.
Давайте зададим себе второй вопрос — а зачем нанимающей фирме тестовое задание? Абсолютно ложный ответ — проверить возможности кандидата. Ответ неправильный, потому что у нанимающей фирмы уже есть как минимум два источника, чтобы посмотреть на реальные рабочие навыки кандидата. Первый — это ссылки на github, gitlab и другие аналогичные сервисы, в которых есть профиль кандидата и образцы кода из выполненных проектов, а иногда и сами проекты целиком. При этом очевидно, что если фирма начинает говорить кандидату что-то вроде «ну мы же не можем гарантировать, что вы не накидали туда чужих проектов, а сами так не умеете», то это уже показатель токсичности рабочей атмосферы в вашей фирме и стоящий здравомыслящий кандидат уже трижды задумается — а стоит ли вообще к вам подаваться? Второй источник — это собственно код вашего кандидата, написанный им в боевой обстановке в течение испытательного срока. Да-да, вы забыли, что есть еще и испытательный срок, который иногда может достигать трех месяцев и вы можете вообще его оформить как временный срочный контракт, чтобы меньше было юридических проблем при расставании с не прошедшим отбор кандидатом. И за это время кандидат покажет себя намного глубже и в отношении хард скиллов и в софтскиллах, чем на одном тестовом задании. Испытательный срок в гораздо лучшем виде дублирует и заменяет ваше тестовое задание. А вот когда есть и то, и другое — кандидат уже задумывается о том, стоит ли овчинка выделки, чтобы проходить через все эти препоны и рогатки, когда вокруг так много намного более адекватных работодателей. Уважающий себя соискатель непременно задаст вам такие вопросы: «Оплачивается ли тестовое задание? Давайте подпишем разовый контракт на тестовое задание? Если тестовое задание будет признано успешно выполненным, то последует ли за ним офер сразу в штат без испытательного срока? А зачем вам испытательный срок, если вы уже оценили мои возможности в тестовом задании? А давайте без тестового задания, но заключим разовый договор на весь испытательный срок и, если я его успешно пройду, то потом сразу примем меня в штат на полную ставку?»
Вас смущают эти вопросы, они кажутся вам жесткими и преждевременными? А вы вспомните, что у кандидата тоже есть свои интересы, и переговорный процесс при приеме на работу — обоюдосторонний, то есть не только вы оцениваете кандидата, но и кандидат оценивает работодателя. Ах, вы не привыкли к такой постановке задачи? Ну добро пожаловать в реальную жизнь и в мир победившего капитализма! Тогда у вас практически нет шансов собрать достойную высококвалифицированную команду и наладить потом с ней полноценную не токсичную и эффективную работу. В лучшем случае вы наберете такими методами много джунов, которые легко поддаются на провокации рекрутеров, красивые слова о «горящих глазах», «креативности» и «энтузиазме». А два, три и четыре джуна не смогут сделать одну работу мидла или сеньора, тут дело не в объеме, а в качестве и глубине понимания стеков разработки. Горящие глаза, креативность и энтузиазм прилагаются бонусами сами собой — зайдите в кабинет к сложившейся команде разработчиков в процессе работы, вы поймете, что это все у них и так есть. Но только за хорошую зарплату — за горящие глаза в магазине нам давно уже ничего не выдают, выдают за деньги, причем с каждым днем денег нужно все больше, с учетом реальной инфляции в стране и в мире.
Если вежливое, логичное и обоснованное описание проблемы оказалось для вас недостаточным, могу еще привести аргумент психологического характера, выраженный простонародным языком. Вы и ваша фирма — «темнилы»! А «темнил» нигде не любят. Если ваш собеседник «темнит» — значит, он что-то скрывает, и хочет вас «нагреть». Подсознательно это также очень работает и автоматически настораживает соискателя и представляет вашу фирму, как кандидата в работодатели с крайне токсичной рабочей обстановкой. Джуны на это еще покупаются, а вот хорошие специалисты — уже кожей чувствуют подвох, они таких фирм и таких рекрутеров уже навидались за свою карьеру ого-го-го сколько! Ну, вот теперь все, уфф… Кидайте тапки.
Кстати, у моих друзей из OTUS скоро пройдет бесплатный вебинар для начинающих аналитиков, руководителей HR-подразделений, а особенно — специалистов, работающих в сфере компенсаций и бенефитов. На вебинаре вы узнаете о том, каковы типичные ошибки анализа компенсационной информации внутри компании и где взять информацию о зарплатах за её пределами. Результатом урока будет обзор особенностей анализа рынка труда, который поможет избежать наиболее грубых ошибок при сопоставлении компенсационной политики компании с внешним рынком. Регистрация на вебинар доступна по ссылке.
ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/711904/
Добавить комментарий