Пространство для современных эйчаров  
  right_in.png  right_face.png  right_twit.png  ВК  google_5941  

 

 

ИТ-рекрутинг: как отбирать резюме и проводить собеседования

« Назад

10.01.2014 00:09

joel_spolskyДжоель Спольски, инженер-программист и писатель, сооснователь Fog Creek Software: резюме и сопроводительное письмо – феноменально слабые способы презентации специалиста. Они могут дать рекрутерам только малейшие подсказки относительно того, насколько человек профессионален. Правда, иногда резюме довольно четко указывает на отрицательные моменты, что позволяет отсеивать заявителей еще на начальной стадии отбора.

Политика отбора резюме в компании Fog Creek Software состоит из трех частей:

  • Мы стараемся избирательно подходить к «рекламе» вакансии, чтобы не создавать лишний шум вокруг нее и ограничить поток резюме.
  • Мы, конечно, не нанимаем людей на основе резюме, мы только проводим с его помощью скрининг, за счет чего уменьшаем количество претендентов на собеседование.
  • Чтобы отобрать оставшиеся резюме и решить, кого стоит приглашать на интервью, мы используем объективную систему анализа и оценки. Это позволяет нам оставаться справедливыми и последовательными в деле подбора персонала.

Существует несколько объективных критериев, которыми мы пользуемся при отборе резюме.

Поэтому уже на само собеседование к нам попадают люди с самым высоким уровнем компетенций:  

Страстное увлечение. Мы ищем в резюме доказательства того, что соискатель является страстным поклонником всего относящегося к компьютерам и программированию. Классические доказательства:

  • Человек с раннего возраста возится с компьютерами и пытается заниматься программированием. Скорее всего, он проводил лето за разработкой сайтов для знакомых, а не подрабатывал в магазине одежды.
  • «Внеклассная» деятельность. Люди, увлеченные программированием, в свободное время часто работают над собственными проектами или принимают участие в проектах с открытым кодом.
  • Иногда некоторые языки программирования или технологии, указанные в резюме, свидетельствуют о том, что человек любит свое дело и все время стремится изучать что-то новое, улучшить свои навыки, отслеживая и пробуя новинки. Однако здесь нужно быть осторожными. Если в 1996 году упоминание Java в резюме было признаком страстного увлечения программированием, то уже сегодня не несет почти никакой особой информации.

Придирчивость. Мы обращаем внимание на сопроводительное письмо. Для нас оно служит доказательством того, что соискатель действительно хочет работать у нас. Нам не нужен стандартный текст, в котором только «я-я-я», мы хотим видеть в сопроводительном письме логические доводы относительно того, почему Fog Creek является для человека тем местом, где он хотел бы работать. Существует две причины, почему это действительно важно. Во-первых, это признак того, что кандидат не кидает пачками резюме на сотни вакансий одновременно. Тот факт, что он нашел время, чтобы узнать о Fog Creek и написать сопроводительное письмо именно для нас, означает, что он чувствуют уверенность в своих силах, поэтому обращается к немногим избранным работодателям, а не занимаются массовой рассылкой резюме.

Массовая рассылка резюме – один из симптомов отчаяния. Что еще более важно, сопроводительное письмо является признаком того, что, если мы сделаем кандидату предложение, то он, скорее всего, примет его. А это только лучше для нас. Если бы возникла такая ситуация, при которой я смог бы взять интервью только у шести человек, то я предпочел интервью с теми шестью соискателями, которые действительно хотят работать в Fog Creek, а не просто умными людьми, пробующимися на сотни других вакансий.

Грамотность. Решение проверять резюме на грамотность оказалось для нас трудным. Дело в том, что программирование – эта одна из тех областей, в которой иммигрант, не говорящий по-английски, все еще ​​может быть блестящим программистом. Тем не менее, опыт работы научил меня, что программисты, которые могут четко и грамотно выражать свои мысли, гораздо эффективнее.

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

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

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

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

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

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

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

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

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

Что делать, если в ваших руках оказались резюме слабых кандидатов?

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

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

Не ищите опыта работы с конкретными технологиями

Большинство программистов жалуются на самый главный, по их мнению, недостаток рекрутеров – почти болезненное увлечение ключевыми словами и терминами. Вся индустрия профессиональных «охотников за головами» и рекрутеров удивительным образом зациклена на простом алгоритме соответствия кандидата на должность, поэтому они ищут тех, кто имеет полный список «технических акронимов», необходимых работодателю. Это особенно бесит, когда ты понимаешь, что большинство из них понятия не имеют, что собой представляет любая из этих технологий. «О, у вас нет опыта работы с MSMQ? Пустяки, не берите в голову». Это ситуация аналогична той, когда агенты по недвижимости болтают о морозилке и печке. Но они, по крайней мере, знают, как выглядят эти предметы. Самый простой способ поймать рекрутера на некомпетентности, это когда он неизбежно настаивает на пятилетнем опыте работы с Ruby on Rails или отказывается рассматривать кандидатуру на вакансию с Windows API, когда у человека указывается в резюме Win32.

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

В подборе персонала мы исходим из того, что нанимаем специалиста на длительный срок, и любая технология, с которой он по какой-то причине не знаком сейчас, вполне может устареть уже в следующем году. Кроме того, некоторым технологиям очень легко научиться. Если бы мне нужно было нанять кого-то на работу с языком Ruby, а у человека был бы опыт работы с Smalltalk и Python, и он никогда даже не слышал о существовании Ruby, то все равно у него было бы намного больше шансов по сравнению с тем, кто, допустим, читал книгу о Ruby. Для тех, кто является хорошим разработчиком ПО, изучение другого языка программирования – не такое уж и грандиозное событие.

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

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

Проведение собеседования с кандидатами   

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

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

Во время собеседований вы столкнетесь с тремя типами людей. Первый тип – это «массовые» кандидаты, не обладающие элементарными навыками. Их легко вычислить с помощью двух-трех вопросов. Второй тип – суперзвезды, а промежуточный вариант – большое количество возможных претендентов, так называемых maybes-кандидатов. Есть смысл объяснить различие между суперзвездами и maybes. Ведь вы не хотите брать на работу любого из категории maybes, а именно они, как правило, вам и нужны.  

По окончании собеседования вы должны быть готовы принять четкое решение относительно кандидата. И здесь возможны только два варианта – брать или не брать на работу. Никогда не говорите: «Вы хороший специалист, но не подходите для нашей команды». Это звучит грубо и, по сути, означает, что кандидат недостаточно умен, чтобы работать в вашей компании. Давайте однозначный ответ: «Мы не можем вас нанять». Никогда не говорите: «Может быть, но я сейчас не могу дать точный ответ». Если вы не можете дать ответ, это значит, что найм невозможен. Просто скажите – нет. И все встанет на свои места.

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

В принципе, все просто. Вы ищете людей, которые:

  • умны
  • добиваются своей цели

Вот и все. Это все, что вы ищете. Запомните это раз и навсегда.

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

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

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

Перед интервью я читаю резюме кандидата и записываю план собеседования в блокноте. Это просто список вопросов, которые я хочу задать человеку. Вот стандартный план интервью с программистом:

  1. Введение
  2. Вопрос о последних проектах кандидата, над которыми он работал
  3. Простой вопрос о программировании
  4. Вопрос об указателях / рекурсии
  5. Довольны ли вы?
  6. Есть ли у вас вопросы?

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

Собеседование – это весы. Если вы хотя бы немного знаете о кандидате заранее, то автоматически одна чаша весов будет перевешивать. И интервью окажется бесполезным. Однажды со мной произошел такой случай. Прямо перед самим собеседованием в мой кабинет зашел рекрутер и сказал: «Тебе обязательно понравится этот молодой человек. Он очень меня впечатлил». По-хорошему мне тогда следовало ответить: «Ну, если ты так уверен, что мне он понравится, то почему бы тебе просто не взять его на работу вместо того, чтобы тратить время на собеседование?». Но я был молодым и наивным, поэтому провел собеседование. Когда кандидат начал говорить глупости, я подумал: «Ну и дела, должно быть это то самое исключение, которое подтверждает правило». Я смотрел на все происходящее сквозь розовые очки. Я принял решение о найме, несмотря на то, что тот человек был откровенно слабым специалистом. И оказалось, что все остальные, кто общался с ним, сказали, что его не стоит брать на работу. Вывод таков: не ориентируйтесь на чужое мнение, не выведывайте о человеке информацию до интервью и никогда не говорите с другими интервьюерами о кандидате, пока вы по отдельности не приняли самостоятельные решения.

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

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

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

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

Большую часть времени во время собеседования необходимо посвятить написанию кода. То есть кандидат должен показать определенные способности. Вот два примера заданий:

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

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

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

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

Хотя сам по себе формат интервью поверхностный, моя основная цель – вести с кандидатом диалог в то время, когда он пишет код на доске. «Почему вы делаете это так?»; «Каковы характеристики производительности алгоритма?»; «Что вы забыли?»; «Где вы допустили ошибку?».

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

В конце собеседования спросите кандидата, есть ли у него какие-либо вопросы. Некоторые судят кандидата по тому, насколько «умные» вопросы он задает. Лично мне все равно, какие вопросы он задает, потому что к заключительному моменту я уже принимаю окончательное решение. Беда в том, что за день кандидату приходится встречаться с пятью-шестью людьми, блистать умными вопросами в таких условиях сложно, поэтому, если у него вообще не возникло вопросов, то это замечательно.

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

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

Автор: Джоель Спольски, инженер-программист и писатель, сооснователь Fog Creek Software

Перевод с английского: Инга Хамми

Копирование и любая переработка материалов с сайта neohr.ru запрещены



Комментарии


Комментариев пока нет

Добавить комментарий *Имя:


E-mail:


*Комментарий: