Повышение качества отбора персонала на основе данных30.10.2017 13:48

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

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

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

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

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

Вот ключевые свойства данного процесса:

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

Итак, начнëм с типичного процесса и будем его улучшать. Обычно дело обстоит так:

• вакансия, перегруженная «обязательными требованиями»;
  
• первый этап — скрининг по резюме;
  
• затем, возможно, беседа с «эйчаром» для первичного отсева;
  
• после чего, длительное техническое интервью без чëткого плана с обсуждением опыта работы, углублением в произвольные детали и «задачками на сообразительность», по итогам которого принимается окончательное решение.
  

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

Шаг 1. Просейте вакансию
Сперва приступим к улучшению текста вакансии.

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

По моему опыту, чаще всего это происходит из-за завышенных ожиданий нанимающего (что, кстати, приводит ещë и к тому, что не удаëтся никого отобрать за несколько месяцев собеседований), а также из-за того, что в «обязательные требования» попадают его личные хотелки («я не смогу работать с человеком, который не знаком с bash, даже если это тестировщик»; «если разработчик не сталкивался с git, значит он никогда серьëзно не работал и я не буду его рассматривать»; …). Отчасти такие требования возникают из-за того, что личное собеседование занимает много времени и отнимает много сил, поэтому приходится искать какие-то эвристики, чтобы отсеять побольше сомнительных кандидатов на этапе просмотра резюме.

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

Приведëнный ниже простой чеклист поможет вам отделить обязательное от желательного:

1. Есть ли необходимость в том, чтобы все сотрудники обладали данным навыком? Например, часть задач по системе связаны с доработкой внутренней админки, которая использует Vue.js. Если только половина сотрудников отдела разработки будет знать Vue.js, достаточно ли будет их ресурсов, чтобы решать все задачи такого плана?
   
2. Может ли человек быстро обучиться этому навыку? К примеру, если работа в вашем отделе построена по git flow, совершенно не обязательно требовать этого навыка от кандидатов — любой человек легко разберëтся в git flow за пару первых рабочих дней, даже если никогда раньше не работал с git.
   

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

Итак, после описанных манипуляций, в списке обязательных требований должно остаться не более 3–5 пунктов. Это те навыки, которыми обязаны обладать все сотрудники и которые при этом невозможно приобрести относительно быстро. Вот пример того, что могло бы получиться для вакансии разработчика:

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

Теперь ваша задача — это проверить.

Шаг 2. Разработайте объективный механизм проверки обязательных требований
Человек не может быть объективным и непредвзятым в вопросе оценки кандидатов, так как подвержен множеству когнитивных искажений.

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

Компания TripleByte, специализирующаяся на отборе кандидатов, вывела 10 тезисов о том, как должна производиться работа с кандидатами и назвала их собственным манифестом. Мой опыт подтверждает их тезисы на 100%.

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

1. Тест с вариантами ответа

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

• ответы должно быть нельзя нагуглить (по крайней мере, за отведëнное время) — для этого хороший вопрос должен требовать не фактическое знание, а некоторую манипуляцию в голове, чтобы дойти до правильного ответа;
  
• если вопрос содержит блок кода, его должно быть невозможно запустить, чтобы узнать правильный ответ;
  
• вопрос не должен быть слишком простым (в этом случае ответ на него не даст никакой информации);
  
• вопрос не должен быть слишком сложным (если процент правильных ответов близок к 1 / количество_вариантов, то мы отсеим неудачников, а не тех, кто хуже знает тему);
  
• не должно проверяться знание наизусть того, что можно легко нагуглить во время работы — наличие этих знаний в голове ничего не показывает;
  
• не должно проверяться то, что не будет использоваться кандидатом в работе у нас («общая эрудиция», навороченные структуры данных и алгоритмы, умение моделировать физические процессы, …) — вопросы должны составляться только по обязательным требованиям;
  
• хорошим количеством вариантов ответа будет от 4 до 7 — при 3 и меньше вариантах ответа слишком велика вероятность угадать, в то время как при более чем 7 вариантах ответа велика вероятность не удержать все варианты в голове и запутаться.
  

Со временем у меня выработались несколько техник, которые помогают написать хорошие вопросы:

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

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

Хорошие примеры вопросов также можно встретить на TripleByte, причëм тексты вопросов содержат примеры кода на совершенно различных языках программирования, однако ответить на все вопросы можно и без знания этих языков. Таким образом, они проверяют не только сообразительность, но и мотивацию кандидата — часть людей сдаëтся, увидев название незнакомого им языка, даже не попытавшись прочитать код. По моему опыту, люди отвечают либо на 90 и более процентов таких вопросов, либо на 50 и менее — промежуточных результатов практически не встречается.

// возвращает индекс наименьшего элемента в массиве
function minIndex(array) {
    minIndex = -1;
    minValue = 0;
    for (i = 0; i < array.length; ++i) {
        if (array[i] < minValue || minIndex == -1) {
            minIndex = i;
            // ПРОПУЩЕННАЯ СТРОКА
        }
    }
    return minIndex;
}

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

Для проведения тестирования, я использую платформу TypeForm. Помимо прочего, платформа умеет подсчитывать общее время, затраченное на тест, что является немаловажным фактором. Форму можно брендировать в ваши корпоративные цвета. Также мне нравится платформа SurveyGizmo, раньше я использовал еë.

Следует иметь в виду, что основная задача данного этапа — отсеять существенную часть недостойных кандидатов (и тем самым охватить больше входящих лидов), по возможности оставив всех достойных. То есть, не так страшны false positives, как false negatives. Поэтому требования к прохождению теста я стараюсь держать немного заниженными (выявляем достоинства, а не недостатки).

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

2. Практическое задание

Многие компании предлагают на собеседованиях задачки типа «сколько люков в нашем городе» или «как определить фальшивую монету за N взвешиваний», а потом удивляются, что кандидаты, отлично ответившие на эти вопросы (то есть, очевидно, много в своей жизни ходившие по собеседованиям и знающие такие задачки наизусть) потом работают плохо. Google, который долгое время славился использованием подобных задач на своих собеседованиях, в конечном счëте признал, что они не работают.

Я придерживаюсь следующей позиции: чтобы понять, насколько человек будет хорошо работать, надо на собеседовании…  заставить его поработать!

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

Разработчикам далее выдаëтся последовательность заданий. Это не олимпиадные задачи, хоть и внешне всë похоже! Это задачи, в наилучшей степени отражающие то, что придëтся делать кандидату на рабочем месте. Например, для кандидатов на должность, которая предполагала подключение на потоке различных рекламных сетей по API, мы выбрали API, с которым точно никто не работал (чтобы уравнять исходные позиции кандидатов) и наделали заданий, связанных с этим API, которые проверяют:

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

В общем, всë то, с чем реально придëтся столкнуться при работе с различными API. Всë это нам удалось найти в приведëнном API.

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

Для админов мы готовили виртуалку, на которой требуется разобраться в проблемах и исправить конфигурацию, чтобы достичь целевых показателей по нагрузке. Залогом успеха для кандидата в этом случае является сочетание базового знания основных технологий, умения находить информацию в интернете, анализировать логи и эффективно использовать bash. Похожие задачи предлагает Яндекс в рамках олимпиад Яндекс.Root.

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

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

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

3. Личное собеседование

Личное собеседование является наиболее затратным по времени и самым субъективным, поэтому на нëм я стараюсь проверять только то, что невозможно проверить на более ранних этапах. Обычно, дело остаëтся за малым:

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

Последнее проверяется дополнительные вопросами по пройденным тестам: почему вы ответили именно так;, а как изменится ответ, если поменяется вот эта вводная; почему в практическом задании вы реализовали такую-то вещь именно таким образом.

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

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

4. Другие варианты

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

Шаг 3. Тюнингуйте
Не следует принимать на веру, что данный механизм сразу заработает. Так и не будет. Я использую методику «постепенного ввода» этого процесса.

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

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

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

В тесте с вариантами ответа следует сделать следующее:

• найдите вопросы, на которые отвечают все. Исключите их или сделайте сложнее, иначе они не будут нести никакой информации;
  
• найдите вопросы, на которые отвечают примерно на уровне случайного попадания в вариант ответа. Исключите их или упростите. Вопрос даëт больше всего информации, если на него отвечает примерно 50–60% кандидатов;
  
• посмотрите, не палятся ли правильные ответы по какому-то простому критерию. Например, сколько баллов получит в вашем тесте человек, если всегда будет выбирать самые длинные ответы? Скорее всего, если вы об этом раньше не задумывались, то большинство правильных ответов у вас окажутся самыми длинными;
  
• посчитайте корреляцию каждого отдельно взятого вопроса с итоговым впечатлением от кандидата и с результатом прохождения им других этапов (функция подсчëта корреляции доступна из коробки в любых электронных таблицах). Вопросы, имеющие близкую к нулю или отрицательную корреляцию следует удалить или улучшить — скорее всего, в них есть какая-то проблема и они проверяют не то, что нужно;
  
• если сильный человек неправильно ответил на вопрос — уточните на личном собеседовании, почему он выбрал именно этот вариант. Может быть, вы чего-то не учли, вопрос составлен с ошибкой, содержит двусмысленность или просто ничего не проверяет;
  
• вместо всех удалëнных вопросов придумайте новые, чтобы примерно сохранить их количество.
  

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

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

Шаг 4. Делегируйте
Когда система налажена, всë взаимодействие на этапе теста с вариантами ответа можно делегировать абсолютно любому сотруднику организации — например, менеджеру по персоналу или офис-менеджеру. Второй этап также может проводить любой человек, однако на практике проводит человек в той же должности, на которую ищется новый сотрудник, чтобы ответить на вопросы кандидата о компании и таким образом немного замотивировать его на прохождение второго этапа. Общение с кандидатом отнимает на данном этапе 5–10 минут времени.

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

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

Итак, повторю основные шаги:

1. критически посмотрите на список обязательных требований и постарайтесь оставить лишь несколько главных;
   
2. продумайте, каким образом можно объективно проверить соответствие кандидатов этим требованиям — хорошо работают тесты с вариантами ответа и практическое задание, максимально приближенное к реальной работе; на личном же собеседовании лучше проверять только то, что не получается проверить на других этапах;
   
3. убедитесь, что построенная система работает как надо и действительно позволяет отделить хороших кандидатов от плохих;
   
4. смело делегируйте отборочные этапы коллегам, чтобы высвободить себе время на более стратегические дела.
   

© Habrahabr.ru