Зарплата по результатам собеседования — лучший способ сократить отклики на вакансию, а тестовые задания — избыточны

Какой 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-подразделений, а особенно - специалистов, работающих в сфере компенсаций и бенефитов. На вебинаре вы узнаете о том, каковы типичные ошибки анализа компенсационной информации внутри компании и где взять информацию о зарплатах за её пределами. Результатом урока будет обзор особенностей анализа рынка труда, который поможет избежать наиболее грубых ошибок при сопоставлении компенсационной политики компании с внешним рынком. Регистрация на вебинар [[доступна по ссылке]].