О найме. Взгляд оттуда

Небольшое предисловие

Написать эту статью меня сподвигло мое недавнее общение с HR российских компаний. И мое немалое удивление насколько бедным, неорганизованным и кустарным оно выглядит по сравнению с их коллегами на другой стороне глобуса. Это выглядит очень удивительно, учитывая что многие, если не большинство, российских софтверных компаний ориентируются на западные практики. Но этот «взгляд» почему‑то никак не трансформируется в заимствование и адаптацию практик найма людей, а ведь любую компанию формируют люди. Найм людей это первое с чем сталкиваются все основатели: кого взять с собой? Кто может сделать то или это? Где найти таких людей с нужной мотивацией? И деньги тут не всегда помогут. Перефразируя Макиавелли — правильные люди принесут вам много денег, однако я сомневаюсь что большое количество денег привлечет нужных вам людей. Поэтому поиск, оценка и найм нужных людей это очень важная часть фундамента компании и он не может быть плохим. На плохом фундаменте не построишь хороший дом. Моя цель в статье не просто критиковать российские компании, а попытаться указать на явные проблемы и, может быть, подсказать возможные решения. Если российские компании собираются становиться большими и международными, а я надеюсь что они собираются, то надо работать над проблемами.

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

О найме в США (FAANG)

Следует немного рассказать о том как происходит найм в Бигтехе в США и как устроен сам процесс найма.

Начнем немного издалека, а именно с вопроса чем же, собственно, занимается HR? Какую роль он играет в организации? В чем состоит его стратегия? Говоря абстрактно, стратегический HR помогает так организовать жизнь в организации, чтоб это наиболее четко соответствовало бизнес-целям организации. И чем больше организация, тем более формальным и более детальным становится HR планирование. HR (стратегический) это не только найм но и в целом жизнь работника в организации, а именно:

• Планирование будущей рабочей силы (нужно ли нам нанять или уволить? в каком количестве? кого? сколько это будет стоить?)

• Тренинг и компетенции (кого учить? чему учить? как?)

• Перфоманс (хорошо или плохо работает персонал и почему?)

• Оценка состояния (кто у нас есть и чем они заняты?)

• Мотивация (насколько работники мотивированы, сколько хотят уйти и что с этим делать? кого продвинуть по службе и т. п.)

• Конкуренция за рабочую силу (Чем мы привлекаем людей? Как сделать чтоб привлечь больше и т. п.)

Это основные вопросы, которыми занимается HR на уровне организации.

Об имитации

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

О корпоративной культуре и психологическом интервью

Бигтех это огромные компании. Самая большая это Амазон — 1.5 миллиона работников, cамая маленькая — Мета с 65 тыс. работников. При таких цифрах управление такой компанией это как управление небольшим городом со своей культурой, со своей демографией, кланами и со своими проблемами. В таких компаниях уследить за каждым невозможно физически. Невозможно прочитать все отчеты всех менеджеров и решить кому и на что выделить деньги, а кого уволить. Поэтому тут большую роль играет «культура компании», которую насаждает HR. Это и 14 принципов Амазон, и Googleyness в Гугл, и Meta's «Be Bold. Make impact. Live in the Future» и так далее. Каждая компания, с какого‑то размера, начинает вырабатывать и насаждать свою культуру, которая подчинена бизнес‑целям (да, тут всегда и все про деньги) и решает одновременно как вопросы управления, так и вопросы привлечения людей. Компании занимаются этим не потому что это «модные практики» и все так делают, они может и рады бы не заниматься всей этой «фигней», но по‑другому просто невозможно. (Еще раз про копирование — не нужно это копировать слепо. Это американские компании, действующие в американских условиях, которые очень специфичны, с людьми из чрезвычайно разных обществ, что тоже очень специфично. Это все нужно осмыслить и выработать свой собственный подход.) Поскольку культура очень важна для компании, какой бы ерундой это не казалось, почти все Бигтех включают раунд, который называется психологическое интервью (behaviour interview). Амазон пошел даже дальше, каждый раунд интервью содержит один или два вопроса на тему 14 принципов. Невозможно пройти все технические раунды, но завалить поведенческое интервью и быть нанятым. Немного деталей о подобном интервью от интервьюера Меты*

Вопросы для каждого этапа интервью подбираются очень тщательно. Случайных вопросов тут нет и каждый вопрос, вплоть до формулировки, подобран так чтобы получить тот или иной «сигнал» от кандидата. Практически не бывает такого что интервьюер сидит и, разглядывая потолок, думает «о чем бы еще спросить?». За все компании сложно сказать, но у Гугл и Мета есть свои пулы вопросов, которые могут быть использованы на интервью. Разумеется, они постоянно обновляются и дополняются — какие‑то вопросы убирают, какие‑то добавляют. По всем вопросам ведется статистика и заметки.

Как итог, кандидат оценивается как с технической так и с психологической/культурной стороны и для инженеров структура интервью выглядит примерно так: два или три раунда на кодинг/алгоритмы, один или два раунда дизайна и раунд психологического интервью. Вопросы стараются подбирать таким образом чтобы выяснить определенный навык, опыт или поведение. Компания хочет знать кто вы и на что вы способны и немного о вашей подготовке. Само по себе знание не играет роли, если из него не делаются какие‑то выводы. Для большой компании, странно нанимать человека, который знает несколько языков программирования, но не способен освоить еще один. А с другой стороны, если человек способен освоить любой язык программирования, то странно требовать знания какого-то конкретного.

О задаче на кодинг

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

Часть кодинга, наверное, наиболее формализованная. Дали задачу - выдал решение. Код нужно будет написать на доске, иногда в IDE - везде по-разному. Цель этого или этих раундов понять может ли кандидат писать код, знает ли он наиболее популярные алгоритмы и может ли он их применять. В особо сложном случае, но тут я не очень уверен, проверяется интуиция и креативность применительно к алгоритмам и кодингу.

Что оценивается при решении задачи? Задачу, конечно, нужно решить, это основное, но есть некоторые оговорки. Если кандидат, получив задание, сразу же приступает к решению — это плохой знак. На решение задачи дается около 45 минут и в это время входит несколько этапов — постановка задачи, прояснение требований, объяснение алгоритма, собственно код, обсуждение решения и тестирование. Перескакивание сразу к решению может снизить оценку вплоть до негативной с формулировкой «Задача знакома кандидату. Мало сигналов для оценки». Опционально, если есть время, то можно дать еще одну задачу и это будет плюсом. Однако, если решения для обеих задач будут записаны в полной тишине, то это большой минус. Коммуникация важна. Рассуждения важны.

О задаче на дизайн

С дизайном чуть сложнее, но именно тут оценивается опыт и есть где развернутся и кандидату и интервьюеру. Условно говоря, цель этого раунда оценить умение кандидата подходить к большим и сложным проблемам, умение разбивать их на части и, в итоге, собирать решение из этих частей. Не требуется детально и глубоко знать какие‑то конкретные технологии, хотя это будет плюсом. Если есть опыт и знаешь — отлично, но если чего‑то не хватает, то это не страшно. Суть немного в другом. Смысл в том, чтобы оценить способен ли кандидат видеть проблемы, понимать их глубину и находить или синтезировать какие‑то решение, уметь оценить плюсы и минусы этого решения и тп. Дизайн и архитектура это всегда различные компромиссы и приоритезация различных свойств получаемой системы. Тут нет однозначно правильных или однозначно не правильных ответов, нет догматизма. От кандидата не требуется знать SOLID или Clean Code, как «Отче Наш», но если такая тема всплывает, но он должен объяснить почему были выбраны эти подходы, какие у них плюсы, какие минусы и как они могли бы быть смягчены и тп.

Пару слов о том о чем НЕ спрашивают.

• Не спрашивают о глубоком знании конкретной технологии. Есть, конечно, исключения, но в целом нет. Не важно знаете ли вы о деталях работу сборщика мусора или сколькими способами можно создать объекты в java. Никто не просит знать на изусть api стандартных библиотек. Нет вопросов вроде «что выведет этот код» и т. п.

• Обычно, не требуется знание какого-то конкретного языка. Может, как исключение, C++ только. Достаточно знать и уметь пользоваться хоть каким-то языком: Go, Java, Kotlin, Python, C и тд. Считается, как само собой разумеющееся, мочь освоить любой язык месяца за три-четыре.

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

Про интервьюеров и решение найма

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

Этикет

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

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

О найме в России

Как обстоят дела с наймом в России? Если коротко, то "так себе".

Отсутствие стратегического HR

Среди всех компаний, с которыми я беседовал, ни одна не проявила признаков стратегического планирования. Чаще всего найм свален на менеджера проекта (или отдела), который и определяет (если определяет) структуру собеседований и типы вопросов. Компании не планируют потребность в персонале и не имеют планов по развитию навыков уже имеющегося персонала. Чаще всего это просто профанация в виде закупки курсов, которые обучают навыкам, не находящим применения в компаниях. Вся стратегия по привлечению кандидатов сводится к вопросу о верхней и нижней планке зарплаты. Это, безусловно, важный параметр, но далеко не единственный. Вопросы удержания сотрудников, почему‑то, отданы непосредственным руководителям, при отсутствии общей стратегии и системы мотиваций на уровне организации. Позиционирование компаний (HR‑brand) на рынке труда очень слабое — все сводится к «мы платим больше» или «у нас печеньки и пинг‑понг». Медианный возраст разработчика 39 лет, о каком «пинг‑понге» вы пытаетесь рассказать человеку с ипотекой и семьей?

Отсутствие структуры процесса интервью

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

Про интервьюеров

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

Следующий «грех» наших интервьюеров, который встречается нередко и у их коллег на западе, это отсутствие понимания ЧТО они ищут в кандидате и, как следвтие, не понимают КАК это искать. Как говорится, если мусор на входе — мусор на выходе. Тут, вероятно, довольно ярко проявляется ограниченность трансферности знаний и навыков. Разработчики, хорошо понимающие тестирование программ, не могут транслировать подобные же приемы на тестирование людей даже в базовый принципах вроде, «что мы тестируем», «какими методами», не говоря уже о более продвинутых техниках по оценки результативности тестирования. Проще говоря, умение тестировать программы и программные системы, не транслируется в умение тестировать (проверять навыки и знания) людей, несмотря на всю схожесть процесса. Отсюда нет понимания ни цели задаваемых вопросов, ни ответов, полученных на них.

Что мы ищем

Вследствие искажений, описанных выше, и отсутствия системы, вопросы, которые задаются на интервью в лучшем случае проверяют знает ли кандидат какое‑либо специфический API или синтаксис языка и почти никак не проверяют его навыки и способности решать задачи, возникающие в реальной работе. Разумеется, знание тонкостей синтаксиса языка или каких‑либо особенностей используемого API является плюсом и как‑то помогают в работе, но тут есть одна проблема. Языки развиваются, а инструменты и их API меняется. Хуже того, данные знанию даже не являются базисом для новых. Я тут немного уточню свою мысль. Да, знакомство с одним языком программирования, помогает изучить другой, опыт использования одного API, помогает в освоении другого. Однако, это горизонтальный перенос, а не вертикальный. Один язык не всегда является расширением другого, а новый API чаще всего вообще использует новые идиомы. В этом случае, нанимая на основе столь волатильных знаний компания рискует получить не релевантного работника уже через год. Конечно, если компания нанимает на срочный проект, то такой подход вполне валиден, но чаще найм идет на неопределенное время. Если знания специфики быстро устаревают и не отвечают потребностям компании, то что же тогда спрашивать на интервью и как оценивать ответы? В деталях на этот вопрос, каждая компания должна сама найти ответ, но в общем можно подумать и найти некоторые рекомендации основываясь на опыте западный коллег (конечно, адаптированном).

Образ кандидата

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

• Некоторые базовые знания и умения. (Большую часть этих знаний и умений получают в профильных вузах. Доверять им или нет — дело личное. Можно проводить только sanity check.) В эти знания и умения обычно входят базовые алгоритмы и структуры данных, знание хотя бы одного языка программирования и некий общий кругозор.

• Умение анализировать проблему, т. е. разбить еще на части, определить свойства этих частей и синтезировать решение

• Умение донести свою мысль

• Быть командным игроком (обычно это просто не конфликтовать, быть открытым к критике и не доставлять проблем в целом)

• Понимать цели компании или хотя бы проекта

• Некоторые дополнительные требования в зависимости от позиции и характера работы, которые каждая компания должна определить сама.

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

Задача на кодинг

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

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

Вообще, не обязательно задавать задачки в стиле leetcode. Можно придумать и другой формат, если он позволяет оценить требуемые навыки кандидата. Надо только точно отличать оценку навыка от оценки справочных знаний. Например: написать обход дерева с подсчетом чего‑то в каждой вершине — навык, а реализовать сортировку пузырьком или еще хуже, спросить устройство строк в Java — справочник. Спрашивать справочные знания, а также реализацию популярного алгоритма, смысла большого не имеет. Они не дают сигнал на навык применения алгоритма и мало что могут сказать об умении конструировать решение. А именно это важнее всего.

Мой топ бесполезных вопросов, которые задают на интервью:

1. Расскажите как работает GC в Java.

2. Назовите классы из java.util.concurrent или еще какого то пакета или библиотеки

3. Как работает Hashmap?

4. Как устроено Red‑Black Tree?

5. Сколько памяти занимает объект?

6. Напишите синглтон. (и далее со всеми вопросами вплоть до thread‑safe singlton)

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

Задача на дизайн и архитектуру

Тут, как говорят многие, нет правильных или не правильных ответов. Вообще, задача должна быть такой чтоб ее невозможно было полностью охватить в течении часового интервью. Как в ширь так и в глубь. Задача специально задается максимально пространно и в обязанности кандидата входит раскрыть ее как можно шире и как можно глубже. Тут нужно четко объяснить что вы хотите от кандидата, и мягко направлять его в нужном направлении если он вдруг «улетает в стратосферу». Цель — понять как кандидат справляется со сложными и непонятными проблемами и насколько у него обширный опыт в интересующей компанию области. 90% времени на данном раунде должен говорить кандидат, а интервьюер больше выступает как справочник и иногда задает вопросы. Как уже было сказано раньше главное тут умение анализировать проблему и синтезировать решение. Разумеется в рамках профессиональной доменной области кандидата. Наверное, не стоит задавать вопрос на дизайн мобильного приложения бакэнд‑разработчику. Суть не в том чтобы получить «правильный» ответ или ответ, похожий на где‑либо реализованную систему — все же это интервью, а не дизайн системы — суть в том, чтобы узнать определенные способности и опыт человека.

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

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

Чем грешат наши интервьюеры тут? Первое же — карго культ интервью. По форме похоже, но по сути совсем другое. Вероятно, наши интервьюеры считают что тут есть правильный ответ и пытаются оценить насколько кандидат приблизился к «идеалу». Второе — догматизм подходов, что очень странно для меня — SOLID, DRY, KISS, MVC, MVI, Clean Architecture, GRASP, SQL vs NoSQL vs NewSQL, легион их. Не об этом это интервью. Третье — излишняя придирчивость к деталям, не являющимся ключевыми в данной задаче. Например что лучше, бросить Еxception или вернуть код ошибки и далее полчаса обсуждений этого случая.

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

По окончании интервью должны быть понятны ответы на вопросы вроде:

Кандидат может кодировать? Кандидат понимает задачу? (бывает что не понимают, но уже пишут решение). Кандидат озвучил алгоритм решения? Хорошо ли он понимает алгоритмическую сложность? Рассматривал ли/предложил ли альтернативные варианты? Слушает ли подсказки интервьюера и как реагирует на них? И тому подобные вопросы. Просто решение задачи никому не интересно.

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

Поведенческое интервью

Поведенческое интервью для российского ИТ, наверное будет наиболее уникальным и не похожим на аналогичное интервью в западных компаниях. Если в западных компания ценится самостоятельность и открытость, а также соблюдением правил, то в России могут цениться исполнительность, послушание и следование традициям. В США люди предпочитают быть вежливым и опасаются оскорбить человека правдой, в России же предпочитают правду вежливости. В США развита культура общения намеками и полунамеками, в России же предпочитают прямоту. В России жизнь и работа переплетаются очень тесно, в США же есть четкая граница между этими областями. Вобщем, много культурных различий что должно, конечно учитываться. В остальном же все зависит от компании, от стиля ее руководства и от ее внутренней культуры (или отсутствия таковой). В любом случае, мне кажется наиболее важным на этом интервью будет возможность получить ответы следующие вопросы:

• Каковы цели у человека в общем?

• Интересно ли ему ИТ в целом?

• Интересна ли ему компания и продукт (или проект)?

• Как он взаимодействует с людьми?

• На сколько он, скажем, конфликтен?

Это не обязательный список — каждая компания определяет его по‑своему. Мне кажется, что ответы на эти вопросы позволят составить определенное мнение о человеке. Будет ли он конфликтным или наоборот — станет душой компании? Нравится ли ему то чем он занимается и у него есть профессиональная гордость, которая не позволяет ему сделать работу плохо или он просто работает за деньги (что тоже вполне подходит для некоторого типа проектов)? Он пришел в компанию потому что «ваш продукт полный шлак и я хочу его починить» или он пришел потому что «ваш продукт очень крутой и я хочу примазаться»? В общем и целом — будет ли такой человек приносит больше положительного или больше отрицательного в компанию? Привести какие‑то конкретные примеры тут сложно, все очень сильно зависит от самой компании.

Решение и оценка

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

Один из самых простых, но не без издержек, способов это консенсус — все интервьюеры должны дать положительный или, хотя бы не отрицательный ответ. Либо 2 из трех. Либо 3 из 5, и тп.

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

Для больших компаний с массовым набором можно установить некоторую планку. Допустим, нанимать верхние 80%. Например, каждое интервью оцениваем от 1 до 5, а проходной балл 12 или выше (верхние 80%). Кандидат за кодинг получил 3, за архитектуру 5 и за поведение 4. 3+4+5 = 12, что является проходным. Конечно, для большей точности можно ввести больше параметров и баллов за каждый раунд.

После найма

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

Итого. Стратегический HR, исходя из целей компании, среди прочего, разрабатывает структуру найма и мотивации сотрудников. В зависимости от принятой стратегии разрабатывается система анализа эффективности этих действий. Для программистов/разработчиков определяется набор необходимых компетенций. Далее определяются конкретные этапы собеседования и ожидаемые результаты этих собеседования. Цель — как можно больше собрать информации о кандидате и выяснить на каком уровне он обладает необходимыми навыками для выполнения своих рабочих обязанностей. В зависимости от набора навыков подбирается соответствующий стиль и вопросы для каждого раунда. По результатам собеседований, в зависимости от планов компании и стратегии найма, принимается решение о найме. Весь процесс время от времени анализируется и оптимизируется.

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

^{* Meta, Facebook - запрещённые в РФ организации}