- PVSM.RU - https://www.pvsm.ru -
На протяжении последних нескольких лет я управляю разработкой и мне регулярно приходится набирать новых сотрудников.
И хотя у меня нет профессионального образования в области управления персоналом, я, тем не менее, осмелюсь дать достаточно негативную оценку текущему состоянию дел в этом вопросе в IT-отрасли: на мой взгляд, собеседования полны субъективности и случайности, а среднее качество отбора получается весьма посредственным — работодатели жалуются на неадекватность [1] запросов кандидатов, вакансии могут оставаться незакрытыми месяцами, а принятые в штат сотрудники часто не оправдывают ожиданий.
Предположу, что причиной является тот факт, что мало кто из технарей, проводящих собеседования, имеет образование в сфере управления персоналом (естественно), либо хотя бы что-то читали об этом. А рекрутеры, в свою очередь, слабо смыслят в анализе данных. В итоге, пара этих компетенций редко соединяется в одном человеке и нанимающие просто повторяют внешние признаки [2] понравившихся им самим собеседований, не понимая, какой цели они служили исходно и какую информацию были задуманы извлечь. В итоге, с каждой такой копипастой, качество принятия решений падает.
Учитывая мою техническую специализацию, я попытался повысить качество отбора и попутно снизить затраты времени, требуемые для этого, разработав процесс, опирающийся на объективные данные, и внедрив его для найма разработчиков в свой отдел. В итоге, процесс продемонстрировал эффективность, широко распространился по компаниям, в которых я работал, и применяется сейчас для найма специалистов самого разного профиля.
Пару лет назад я уже рассказывал о нëм на HR Unconference [3]. Но записи выступления нет, а знакомые, которые не могут найти себе людей в отдел, всë чаще интересуются деталями, так что я решил, наконец, подробно всë расписать, а заодно и опубликовать свой первый пост на Хабре, поделившись своими наработками с широким кругом читателей.
Вот ключевые свойства данного процесса:
Итак, начнëм с типичного процесса и будем его улучшать. Обычно дело обстоит так:
Иногда используются и совсем экстравагантные приëмы, такие как длительный разговор на свободную тему, применение интуиции в попытках разглядеть скрытые таланты и даже анализ плейлиста вконтакте (всë это — реальные случаи).
Сперва приступим к улучшению текста вакансии.
В описании вакансии присутствует с десяток «обязательных требований», при этом в итоге нанимается кандидат, удовлетворяющий только половине из них. Знакомая ситуация? Можно ли в этом случае считать, что требования действительно были настолько обязательными?
По моему опыту, чаще всего это происходит из-за завышенных ожиданий нанимающего (что, кстати, приводит ещë и к тому, что не удаëтся никого отобрать за несколько месяцев собеседований), а также из-за того, что в «обязательные требования» попадают его личные хотелки («я не смогу работать с человеком, который не знаком с bash, даже если это тестировщик»; «если разработчик не сталкивался с git, значит он никогда серьëзно не работал и я не буду его рассматривать»; ...). Отчасти такие требования возникают из-за того, что личное собеседование занимает много времени и отнимает много сил, поэтому приходится искать какие-то эвристики, чтобы отсеять побольше сомнительных кандидатов на этапе просмотра резюме.
Итак, что требуется для улучшения процесса.
На данном шаге отделите действительно обязательное от желательного. Подумайте, а готовы ли вы в крайнем случае взять человека, который не будет уметь вот этого и этого из вашего списка обязательных требований? Если да, то перенесите такие требования в желательные. Не бойтесь, что на личное собеседование попадëт слишком много недостойных кандидатов — от этого мы защитимся на следующем шаге. Сейчас важно понимать, что обязательно, а что — нет. Лучше бойтесь того, что из-за небольших несоответствий будут отсеяны действительно достойные соискатели.
Приведëнный ниже простой чеклист поможет вам отделить обязательное от желательного:
Вообще, следует обратить внимание на следующую мысль: любому айтишнику в любом случае придëтся чему-то учиться. Даже если вы волшебным образом найдëте человека, профиль которого на 100% соответствует текущим требованиям, через пару месяцев ситуация изменится и наверняка появится новое требование, которому уже не все будут соответствовать. В проекте могут появиться новые библиотеки, которые потребуется изучить; вы внедрите новые технологии, методологии и во всëм этом сотрудникам придëтся разбираться. Поэтому значительно важнее, чтобы человек показывал хорошую кривую обучения, нежели имел высокое значение обученности на данный момент.
Итак, после описанных манипуляций, в списке обязательных требований должно остаться не более 3-5 пунктов. Это те навыки, которыми обязаны обладать все сотрудники и которые при этом невозможно приобрести относительно быстро. Вот пример того, что могло бы получиться для вакансии разработчика:
Теперь ваша задача — это проверить.
Человек не может быть объективным и непредвзятым в вопросе оценки кандидатов, так как подвержен множеству когнитивных искажений [5].
Список можно продолжать и дальше…
В связи с этим, я стараюсь исключить человеческий фактор и объективизировать процесс отбора настолько, насколько это возможно. Дополнительным положительным эффектом является то, что процесс становится воспроизводимым любым человеком и фактор личности собеседующего перестаëт оказывать влияние на результат кандидата.
Компания TripleByte [13], специализирующаяся на отборе кандидатов, вывела 10 тезисов о том, как должна производиться работа с кандидатами и назвала их собственным манифестом [14]. Мой опыт подтверждает их тезисы на 100%.
Я выявил несколько способов оценки кандидатов, дающих возможность объективно их сравнивать по формальным критериям и так, чтобы результаты этого сравнения высоко коррелировали с реальным уровнем кандидата.
Составить хороший тест с вариантами ответа непросто. Чтобы не позволить читерам получить наивысшие оценки, тест должен удовлетворять следующим критериям:
1 / количество_вариантов
, то мы отсеим неудачников, а не тех, кто хуже знает тему);
Со временем у меня выработались несколько техник, которые помогают написать хорошие вопросы:
PluralSight [16] (бывший Smarterer) предлагает адаптивные тесты с вариантами ответа по множеству тематик — каждый следующий вопрос подбирается по сложности с учëтом предыдущих ответов. В конце концов, можно прорешать несколько раз тесты на интересующую вас тематику и вдохновиться понравившимися вопросами на создание собственных похожих.
Хорошие примеры вопросов также можно встретить на TripleByte [17], причëм тексты вопросов содержат примеры кода на совершенно различных языках программирования, однако ответить на все вопросы можно и без знания этих языков. Таким образом, они проверяют не только сообразительность, но и мотивацию кандидата — часть людей сдаëтся, увидев название незнакомого им языка, даже не попытавшись прочитать код. По моему опыту, люди отвечают либо на 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;
}
Ответить на данный вопрос несложно даже не зная языка JavaScript. Данный вопрос хорош ещë тем, что набрать и запустить этот код недостаточно для того, чтобы узнать ответ — требуется ещë подставить входные данные, которые позволят однозначно классифицировать результат, а также перебрать каждый из вариантов ответа. Едва ли это проще, чем подумать головой и логически додуматься до правильного ответа.
Блоки кода я, конечно, даю скриншотами, чтобы затруднить их запуск.
Для проведения тестирования, я использую платформу TypeForm [18]. Помимо прочего, платформа умеет подсчитывать общее время, затраченное на тест, что является немаловажным фактором. Форму можно брендировать в ваши корпоративные цвета. Также мне нравится платформа SurveyGizmo [19], раньше я использовал еë.
Следует иметь в виду, что основная задача данного этапа — отсеять существенную часть недостойных кандидатов (и тем самым охватить больше входящих лидов), по возможности оставив всех достойных. То есть, не так страшны false positives, как false negatives. Поэтому требования к прохождению теста я стараюсь держать немного заниженными (выявляем достоинства, а не недостатки).
Исключите скрининг по резюме и направляйте на тест всех! Это не требует никаких усилий от компании, а кандидату хороший тест также доставляет удовольствие. Я часто встречал хороших кандидатов с плохим резюме и наоборот, и убедился в том, что умение красиво описывать свой опыт — это отдельный навык, который обычно слабо коррелирует с рабочими качествами кандидата, поэтому не стоит попадаться на крючок и делать какие-то выводы по резюме.
Многие компании предлагают на собеседованиях задачки типа «сколько люков в нашем городе» или «как определить фальшивую монету за N взвешиваний», а потом удивляются, что кандидаты, отлично ответившие на эти вопросы (то есть, очевидно, много в своей жизни ходившие по собеседованиям и знающие такие задачки наизусть) потом работают плохо. Google, который долгое время славился использованием подобных задач на своих собеседованиях, в конечном счëте признал [20], что они не работают.
Я придерживаюсь следующей позиции: чтобы понять, насколько человек будет хорошо работать, надо на собеседовании… заставить его поработать!
Для этого отлично подходит тестовое задание, максимально имитирующее обычную рабочую деятельность. Я разрабатываю такие задания для каждой позиции. Ниже приведëн пример для позиции разработчика.
На следующем собеседовании (длительностью 1.5 часа) вы должны будете решать несложные задачи. Задачи связаны в единую канву — при решении каждой следующей задачи, будет удобно отталкиваться от кода, написанного при решении предыдущих.
К моменту начала этого этапа, я прошу вас подготовить на своëм компьютере окружение, в котором вам будет удобно писать код и запускать его.
Сегодняшнее собеседование продлится не более чем полтора часа, в течение которых вы будете решать задачи, одну за одной.
Перед началом вам необходимо убедиться, что на компьютере установлено и удобно настроено ваше любимое средство разработки (IDE), есть возможность писать и запускать код на языке программирования <...>.
Оцениваться будет:
1. Количество задач, которые вы успеете решить за отведëнное время.
2. Количество попыток, которое вам потребуется для решения каждой из задач.Данный этап собеседования построен так, чтобы максимально имитировать обычный рабочий процесс. Этому способствуют следующие его особенности:
1. Качество кода оцениваться не будет, однако каждая следующая задача является некоторым развитием либо усложнением предыдущей. Таким образом, код выгодно писать так, чтобы вам удалось его переиспользовать. Как и в обычном рабочем процессе, вы не знаете заранее, какие участки кода придëтся развивать в будущем.
2. Как и на работе, можно без ограничения пользоваться любой информацией из интернета.
3. Перед «релизом» (то есть перед тем, как сгенерировать ответ по каждой из задач), вам необходимо самостоятельно убедиться, что ваш код работает, потому что в реальной работе никто не обнаружит ошибку за вас.
4. Пишите сконцентрировано, но без спешки. По опыту, излишняя спешка по сравнению с вашим обычном рабочим темпом вам скорее помешает, чем поможет.
Желаю удачи!
Разработчикам далее выдаëтся последовательность заданий. Это не олимпиадные задачи, хоть и внешне всë похоже! Это задачи, в наилучшей степени отражающие то, что придëтся делать кандидату на рабочем месте. Например, для кандидатов на должность, которая предполагала подключение на потоке различных рекламных сетей по API, мы выбрали API [21], с которым точно никто не работал (чтобы уравнять исходные позиции кандидатов) и наделали заданий, связанных с этим API, которые проверяют:
В общем, всë то, с чем реально придëтся столкнуться при работе с различными API. Всë это нам удалось найти в приведëнном API.
Неплохой отправной точкой для тех, у кого пока нет идей, может стать сайт CryproPals.com [22], где собраны несложные задачи на тему криптографии, решение которых не требует никаких базовых знаний, в том числе и по криптографии.
Для админов мы готовили виртуалку, на которой требуется разобраться в проблемах и исправить конфигурацию, чтобы достичь целевых показателей по нагрузке. Залогом успеха для кандидата в этом случае является сочетание базового знания основных технологий, умения находить информацию в интернете, анализировать логи и эффективно использовать bash. Похожие задачи предлагает Яндекс в рамках олимпиад Яндекс.Root [23].
Тестировщикам давали страничку и просили найти как можно больше проблем. При этом, проблемы могут быть самого разного плана: и баги при вводе пограничных значений, и уязвимости, и ухудшение отзывчивости при заполнении системы большим количеством данных, и ошибки в js-консоли, и проблемы с юзабилити. Всë зависит лишь от того, какие компетенции мы ищем в кандидате.
С аккаунт-менеджерами было немного сложнее, но нашли способ сформировать практическое задание и для них: мы давали синтетические кейсы возражений клиентов и просили менеджера написать ответы, а затем отмечали по пунктам, какие из важных установок были применены при ответах (например, если в вопросе отмечалось, что общение происходит со старым клиентом, генерирующим компании существенную часть оборота, было важно, чтобы менеджер пытался найти win-win решение даже несмотря на то, что клиент настаивает на варианте, невыгодном для себя, но выгодном для компании в краткосрочной перспективе).
Важным положительным свойством такого задания является то, что кандидата не требуется контролировать, ведь для решения задачи ему разрешено использовать любые доступные ему средства, равно как и в обычном рабочем процессе.
Личное собеседование является наиболее затратным по времени и самым субъективным, поэтому на нëм я стараюсь проверять только то, что невозможно проверить на более ранних этапах. Обычно, дело остаëтся за малым:
Последнее проверяется дополнительные вопросами по пройденным тестам: почему вы ответили именно так; а как изменится ответ, если поменяется вот эта вводная; почему в практическом задании вы реализовали такую-то вещь именно таким образом.
Конечно, такие истории случаются не часто (вроде бы, мне такие случаи так ни разу и не попадались), да и в любом случае всë быстро станет очевидно на испытательном сроке, но зачем до этого доводить. В конце концов, иногда и рекрутерам за взятых кандидатов надо платить, так что лучше по возможности выявить читеров сразу.
Кстати, именно в начале личного собеседования я, к удивлению кандидатов, впервые открываю их резюме.
Вы можете пробовать и иные варианты объективного тестирования качеств кандидата, описанными выше способами мир не ограничен. Я какое-то время использовал тестовое задание, однако затем решил, что этот этап является избыточным и отказался от него. Помните, что главная мысль заключается не в том, что вот есть тест и есть практическое задание — используйте их. А в том, что вам следует на первом шаге понять, что же вам действительно требуется от кандидата, а затем найти самый простой объективный способ это проверить.
Не следует принимать на веру, что данный механизм сразу заработает. Так и не будет. Я использую методику «постепенного ввода» этого процесса.
На первом этапе я прошу пройти тест людей, уровень которых я хорошо знаю и результат которых я могу предсказать. Обычно это действующие и бывшие коллеги и друзья, уровень профессионализма которых мне отлично понятен. Я даю им протестировать каждый этап и смотрю, насколько предсказуемым оказался для меня их результат. Можно также попробовать дать, например, админское задание разработчикам и убедиться, что их результат будет ниже проходного, в то время как профессиональные админы получают проходной результат. В идеале, мы должны сделать отборочные этапы такими, чтобы достаточно сильные люди проходили их почти в 100% случаев, а слабые не проходили как можно чаще.
Если удаëтся добиться устойчивой корреляции, я перехожу ко второму этапу — боевой проверке. Первые 5-10 кандидатов довожу до личного собеседования независимо от их результатов на отборочных этапах, а на личном собеседовании прошу каждого присутствующего независимо от других дать свою оценку кандидату по каждому из проверенных тестами критериев. При этом присутствующие коллеги не знают результата кандидата, а также оценок друг друга (чтобы минимизировать влияние группового
Если же корреляция низкая, то попытайтесь локализовать проблемы и исправить их.
В тесте с вариантами ответа следует сделать следующее:
В практическом задании постарайтесь устранить случайные факторы. Например, бывают такие сложности, столкновение с которыми не говорит о кандидате ничего плохого, но оказывает сильное отрицательное влияние на результат. Например, в задании с API таким фактором стало то, что авторы API предлагали библиотеку для работы с ним, которая на деле не работала. Те, кто пытались ей воспользоваться, теряли много времени и в итоге заканчивали с плохим результатом. Мы сделали в задании подсказку, что не нужно использовать эту библиотеку, потому что попытка ей воспользоваться априори не является неправильным действием, а значит не должна мешать результату.
Не всегда тесты оказываются хорошими с первого раза, но почти всегда одной итерации улучшений хватает, чтобы тест и практическое задание начали работать идеально.
Когда система налажена, всë взаимодействие на этапе теста с вариантами ответа можно делегировать абсолютно любому сотруднику организации — например, менеджеру по персоналу или офис-менеджеру. Второй этап также может проводить любой человек, однако на практике проводит человек в той же должности, на которую ищется новый сотрудник, чтобы ответить на вопросы кандидата о компании и таким образом немного замотивировать его на прохождение второго этапа. Общение с кандидатом отнимает на данном этапе 5-10 минут времени.
Делегируя, следите за тем, чтобы объективность отбора не снизилась — заставляйте в обязательном порядке фиксировать формальные результаты по каждому взятому в работу кандидату.
Когда система налажена, мне удаëтся по итогам личного собеседования брать более половины попавших на него людей. Все набранные таким образом кандидаты прошли испытательный срок и я могу назвать их прекрасными, эффективными сотрудниками.
Как только появляется потребность расширить штат, эффективный поиск очередного нового сотрудника при уже готовой вышеописанной системе становится очень простым и быстрым: главное это организовать входящий поток кандидатов, а выбрать из этого потока наилучший вариант становится очень простой задачей, которая решается в кратчайшие сроки и без мук выбора.
Итак, повторю основные шаги:
Автор: batony4
Источник [25]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/266994
Ссылки в тексте:
[1] неадекватность: https://habrahabr.ru/company/regionsoft/blog/339284/
[2] внешние признаки: https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%80%D0%B3%D0%BE-%D0%BA%D1%83%D0%BB%D1%8C%D1%82
[3] HR Unconference: http://www.globalhru.com/
[4] поговаривают: https://softwareengineering.stackexchange.com/questions/179616/a-good-programmer-can-be-as-10x-times-more-productive-than-a-mediocre-one
[5] когнитивных искажений: https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B3%D0%BD%D0%B8%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D1%85_%D0%B8%D1%81%D0%BA%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9
[6] иррациональное усиление: https://en.wikipedia.org/wiki/Escalation_of_commitment
[7] эффект первого впечатления: https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%BF%D0%B5%D1%80%D0%B2%D0%BE%D0%B3%D0%BE_%D0%B2%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F
[8] групповое мышление: http://www.psychologos.ru/articles/view/ogrupplenie-myshleniya
[9] эффект сверхуверенности: https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D1%81%D0%B2%D0%B5%D1%80%D1%85%D1%83%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8
[10] склонность к подтверждению своей точки зрения: https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BB%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8E_%D1%81%D0%B2%D0%BE%D0%B5%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8_%D0%B7%D1%80%D0%B5%D0%BD%D0%B8%D1%8F
[11] эффект знакомства с объектом: https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%B7%D0%BD%D0%B0%D0%BA%D0%BE%D0%BC%D1%81%D1%82%D0%B2%D0%B0_%D1%81_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BE%D0%BC
[12] гало-эффект: https://ru.wikipedia.org/wiki/%D0%93%D0%B0%D0%BB%D0%BE-%D1%8D%D1%84%D1%84%D0%B5%D0%BA%D1%82
[13] TripleByte: https://triplebyte.com/
[14] собственным манифестом: https://triplebyte.com/manifesto
[15] не удержать: https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%82%D0%BA%D0%BE%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C
[16] PluralSight: https://www.pluralsight.com/
[17] TripleByte: https://triplebyte.com/users/start
[18] TypeForm: https://www.typeform.com/
[19] SurveyGizmo: https://www.surveygizmo.com/
[20] признал: https://habrahabr.ru/post/184008/
[21] выбрали API: http://swapi.co/
[22] CryproPals.com: http://cryptopals.com/
[23] Яндекс.Root: https://academy.yandex.ru/events/system_administration/root-2015/
[24] мышления: http://www.braintools.ru
[25] Источник: https://habrahabr.ru/post/341220/
Нажмите здесь для печати.