Почему приглашая опытного разработчика вы должны себя вести не как покупатель, а как продавец?

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

Почему же на рынке сложилась такая ситуация? Почему кому-то привлечение опытных сотрудников дается легко, а у кого-то не получается вовсе? Ответ на эти вопросы можно уместить в одно предложение:

При найме senior-разработчика, не компания выбирает кандидата, а кандидат выбирает компанию.

Если говорить уж совсем просто, то приглашая опытного программиста вы не покупаете его, а продаете себя.

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

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

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

Большинство HR-менеджеров, с которыми мне доводилось общаться, со мной в этом соглашаются. Но проблема в том, что их слава в 80% случаев расходятся с делом. И проблема тут не в них, просто современная система рекрутинга устарела и не работает как нужно, причем для обеих сторон. Давайте убедимся в этом на отдельных примерах.

Плохое объявление о найме

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

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

К сожалению, как показывает практика, большинство вакансий просто ужасно составлены. Если вы откроете всеми известный ресурс для поиска работы и просмотрите вакансии по запросу senior-developer или senior-разработчик, то увидите, что в большинстве случаев вакансии составлены чуть ли не по одному шаблону.

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

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

Если рассматривать процесс найма сотрудника как покупку, то такой подход более чем логичен и оправдан. Вы объясняете, что вы хотите купить. Но если рассматривать процесс найма как продажу достоинств вашей компании, то это просто никуда не годиться. Это сродни тому, если бы резюме кандидата на 90% состояло из его требований.

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

Информацию о компании не найти

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

Какие то компании либо не знают, либо не понимают какую информацию нужно писать в таком разделе и пишут либо какую-то дичь, либо общие никому неинтересные слова. В разделе информации о компании вы должны предугадывать и отвечать на конкретные вопросы, которые могут возникнуть у кандидата на должность. Например:

  • Как выглядит офис компании?
  • На каком оборудовании нужно будет работать?
  • Сколько человек в компании?
  • Ходит ли команда вместе отдыхать или обедать?
  • Есть ли дресс-код?
  • Как отслеживается рабочее время?

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

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

Задайте себе вопрос, прошли бы вы это все или даже не стали бы начинать, и просто пошли бы в другой магазин? К сожалению в большинстве компаний процесс найма сотрудников построен именно таким образом и это подводит нас к следующему выводу.

Ваш процесс найма не вывозит

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

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

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

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

Какими должны быть задания для кандидатов

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

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

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

Адаптация и менеджмент

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

На этом этапе от вас что-то зависит уже в меньшей степени, но вы все равно должны показать кандидату все преимущества работы в вашей компании.

Поговорите с уже нанятыми сотрудниками, что они предпочитают. Работать дома или в офисе, как они проводят время с командой и т.д. Эти знания позволят вам легче встроить новичка в рабочую систему. Главное не забывайте, что в этом вопросе все субъективно.

Еще один важный момент. У вас есть выстроенная система работы и вы не должны менять и подстраивать ее под каждого кандидата. Вы не сможете удовлетворить все их пожелания и запросы и это нормально. Главное знайте о своих слабостях, не стесняйтесь признавать их и старайтесь перекрыть их другими плюсами.

Заключение

Если вы давно занимаетесь наймом персонала, при чем в любой области, то избавиться от мысли «продавец ⸺ это кандидат» будет не просто. Ведь смена ролей принесет много изменений в процесс найма, который вы оттачивали годами.

Но не стоит этого бояться. Просто смиритесь с ролью продавца и приступайте к работе. Главное ⸺ ставьте себя на место кандидата, у которого есть несколько предложений от разных компаний. Задайте себе вопрос «Почему он должен выбрать именно вас»? и от ответа выстраивайте свою работу.

Материалы о создании и развитии цифровых продуктов для предпринимателей, менеджеров и специалистов на канале Цифровая ферма единорогов

0
95 комментариев
Написать комментарий...
Александр Прилипко

Оценить навыки кандидата он сможет в небольшой дружеской беседе о последних проектах или технических интересах.

Вот проблема, шров сейчас

Ответить
Развернуть ветку
Victor Pomortseff

Проблема HR'ов в том, что они лезут не в свое дело - пытаются сами оценить технический уровень кандидата, имея очень отдаленное представление о том, что это вообще такое - разработка.
Особенно, когда речь идет о высоких позициях, где задачи будут не рутинно-тривиальные и надо знать больше чем пару-тройку инструментов.
Нашли кандидата по формальным признакам? Молодцы. Дальше отдайте его "технарям", пусть они сами оценят.

Ответить
Развернуть ветку
Иванов Иван

Можно подумать, что среди технарей меньше мудаков.
Бывают даже такие моральные уроды в начальниках отделов, которые специально годами "никого не могут найти", люди в отделе тонут в работе, а все это ради экономии по зарплате, какой-то процент которой потом капает ему в карман.

Ответить
Развернуть ветку
Victor Pomortseff

Их везде хватает. Но HR по определению не может адекватно оценить уровень кандидата. Тем более, кандидата высокого уровня (где требуется понимание некоторых фундаментальных сущностей)

Ответить
Развернуть ветку
Иванов Иван

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

Ответить
Развернуть ветку
Victor Pomortseff

Какой тест?
Если я разговариваю с кандидатом даже на уровень middle+, я не буду давать ему олимпиадных заданий. Просто спрошу - "Вот есть такая задача, как предполагаешь ее решать? Какие грабли там потенциально заложены? Как их обходить?" без кода, просто общий подход. И не факт что кандидат не предложит свой подход к решению, отличающийся от моего. Мы прикинем плюсы и минусы моего и его решений.
Мне важен человек думающий и понимающий что он делает, а не просто тупой сборщик типовых решений из готовых компонентов.

Ответить
Развернуть ветку
Иванов Иван
Просто спрошу - "Вот есть такая задача, как предполагаешь ее решать?

Моя практика собеседований с "технарями" говорит об обратном.

Ответить
Развернуть ветку
Victor Pomortseff

Я работаю в немодной области. Где очень много "нетипичных" решений, где практически нет модных фреймворков, но при этом во главу угла ставиться высокая эффективность, надежность и сопровождаемость.
Тут даже подход к достаточно типовой (для нас) задаче - распараллеливание обработки большого объема данных - можно обсудить с разных сторон и сделать выводы о качестве кандидата

Ответить
Развернуть ветку
Иванов Иван

То есть лучше даже не приходить, если нет докторской степени по философии распараллеливания данных?

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

Ответить
Развернуть ветку
Victor Pomortseff

Нам не нужны клерки. И грузить будем ровно тем, с чем придется работать.
Естественно, не будет вопросов "чем отличается *usrq от *dtaq на IBM i" - это слишком специфический вопрос, такие вещи уже потом, по ходу действия человек осваивает. Но если человек понимает где могут быть заложены грабли и как правильно распределить нагрузку master-workers при построении batch машины - это ему однозначный плюс.

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

Ответить
Развернуть ветку
Иванов Иван
Нам не нужны клерки

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

И грузить будем ровно тем, с чем придется работать.

Моя практика собеседований с "технарями" говорит об обратном.

Ответить
Развернуть ветку
Victor Pomortseff

В какой области разработки? Под какие платформы?

Я не говорю что круче. Просто специфика. Разработка на уровне ядра банковской системы на платформе IBM i (AS/400).
Основные требования - надежность, эффективность, сопровождаемость.
Наша разработка относится к mission-critical части.

Ответить
Развернуть ветку
Иванов Иван

Мне вообще похрен, чем вы занимаетесь, своего геморроя хватает. Я говорю о том, что кругом сплошные понты, искатели великих специалистов и уникальные разработки. А на деле? На деле, я сейчас 20минут трахался с телефоном, чтобы зайти в госуслуги, оказалось, что это кривое угребище не умеет сменить пароль (который хрен поймешь зачем понадобилось менять). Удалось только с компа. И такое ИТ сейчас везде...

Ответить
Развернуть ветку
Victor Pomortseff

Никаких понтов. Просто специфика. И жесткие нормативы не недоступность систем банка от регулятора. За нарушение штрафы со многоми нулями.
Любой крд сначала ревью, потом компонентный тест, бизнес тест, нагрузочный тест, интеграционный тес и только пом на прод. Если ни у кого не возникло вопросов.
Поэтому и выбираем людей, которые способны самостоятельно думать. И писать максимально эффективный код сразу. Которым не надо тыкать - вот тут у тебя два цикла, а можно все в одном сделать.

Ответить
Развернуть ветку
Иванов Иван
и только пом на прод

Обычно же так нигде не делают и только в вашем говнобанке все иначе...

выбираем людей, которые способны самостоятельно думать. И писать максимально эффективный код

Только дай технарям нанимать технарей и они этот процесс превратят в экзекуцию. Все такие умники, что просто капец...

Ответить
Развернуть ветку
Victor Pomortseff
Обычно же так нигде не делают и только в вашем говнобанке все иначе...

Может оттуда и проблемы? Херак-херак и в продакшн. А потом начинается

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

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

Только дай технарям нанимать технарей и они этот процесс превратят в экзекуцию

Никакой экзекуции. Поговорили на равных и приняли решение.

Экзекуция это когда сначала HR задает по бумажке тупые вопросы и сравнивает ответы с бумажкой (тут наиболее продвинутые писали что у них аж программа специальная есть с вопросами и вариантами ответов для тестирования).
А потом еще "техническое собеседование". Там тоже не сильно умный начинает олимпиадные вопросы задавать. Вот накойхер (фамилие такое) это надо?
Ну возьмут такого и что? Результат его деятельности Вы сами озвучили выше.

Ответить
Развернуть ветку
Иванов Иван
Наш подход хотя бы гарантирует что новый модуль на 100% соответствует требованиям

Видимо кое-кто не догоняет, что сейчас везде сидят точно такие же, мнящие себя уникальными, на 100% соответствующими и самыми лучшими на рынке. Отсюда и разговор в таком тоне. Но как показывает практика, даже в очень именитых ИТ-продуктах, творится такой бардак, что волосы дыбом. И какой бы спец к ним не пришел, они всегда себя ставят так, будто он должен у них поучиться.

Поговорили на равных и приняли решение

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

Ответить
Развернуть ветку
Victor Pomortseff

Бардак творится там, где его могут себе позволить.
Кто там что заметил я не знаю. Да и не интересно.
Мнить о себе можно что угодно, но есть конкретные показатели того, чего ты стоишь на самом деле.

Ответить
Развернуть ветку
Иванов Иван
Бардак творится там, где его могут себе позволить

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

Ответить
Развернуть ветку
Victor Pomortseff

Так на то и тестирование чтобы баги выявлять. Если вы не выявили их на тесте - получите бардак на бою. Потому у нас и тесты чуть сложнее чем "не упало сразу - внедряемся".

Да, "дефекты боя" бывают. Но не сказать чтобы очень часто. Чтобы что-то валилось в дампы - это вообще исключительная ситуация. 99% дефектов по логике - какой-то исключительный кейс, который не прогнали через тесты вызывает не тот результат, который ожидался. Такие дефекты дорабатываются быстро. А в целом большая часть софта работает годами без проблем.

Все это в нашей ситуации выявляется быстро - есть сопровждение, дежурная смена, которая постоянно мониторит работоспособность всего.

Ответить
Развернуть ветку
Иванов Иван

Вы считаете себя самым умным в ИТ? Или думаете, что в других компаниях забыли нанять тестеров?

Ответить
Развернуть ветку
Victor Pomortseff

Я не считаю себя самым умным.

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

Ну или сравните цену ошибки - дизлайки от юзеров для какого-нибудь мобильного приложения против $500k/час простоя у банка.

И цель - или скорее выскочить на рынок с пусть и сырым пока продуктом против стабильности работы. Да, у нас тестирование снижает показатель T2M. Но это цена устойчивости системы целиком. Тут альтернатива "или быстро или чтобы рукава одинаковые" (с)

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

Если платеж вдруг не проходит потому что при контроле платежей неправильно отработала процедура поиска совпадений (а она достаточно нетривиальна, поверьте) получателя со списками росфина - это повод для вынесения на комиссию по инцидентам. И поиска - кто аналитик, кто разработчик, кто от бизнеса принимал...

Ответить
Развернуть ветку
Иванов Иван
Я не считаю себя самым умным

А я вижу, что считаете.

Ответить
Развернуть ветку
92 комментария
Раскрывать всегда