Неожиданно жаркая дискуссия разгорелась вокруг статьи “А судьи кто?“, которую написал Алексей Булат на тему собеседований QA специалистов. Я решил достать из черновиков свои мысли на тему подбора людей и рассказать о своем подходе к собеседованиям. Подобрать хорошего сотрудника – это проблема, а найти хорошего члена Скрам команды – это еще большая проблема 😉

Сразу оговорюсь, я не буду рассказывать, где и как найти кандидата – об этом лучше расскажут опытные рекрутеры. Я рассказываю только о том, что должны  делать менеджеры проектов (командные лидеры и прочие), кто пришел на “техническое собеседование” кандидата.Свои первые собеседования я начал году в 2000-м. Почти сразу стало ясно, что даже если человек вас впечатлил знаниями во время беседы, то не факт, что он окажется хорошим членом команды и не уйдет через 3-6 месяцев. Со временем, у меня выработался подход, который я теперь всегда применяю, и который зарекомендовал себя с лучшей стороны.

Отвечая на возможные вопросы – да, я искал книги и статьи на эту тему, и, к сожалению, многое из того, что я нашел, было написано людьми далекими от рекрутинга в целом и собеседований технических специалистов в частности 🙁 Единственная толковая статья, которая мне попалась – это была статья Джоэля Спольски The Guerilla Guide to Interview, которая существует уже в третьей (!) редакции. Поэтому дальше я буду цитировать его по мере своего рассказа, даже если я не на 100% с ним согласен 😉

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

You’re looking for people who are

1. Smart, and
2. Get things done.

That’s it. That’s all you’re looking for.

Мы ищем человека “толкового и умеющего доводить дело до конца“. По большому счету за 30 (ну 60 максимум) минут можно выяснить не так уж много. И многие “человеческие” качества вы узнаете потом. Сейчас вам главное быстро определить подходит вам кандидат или нет. Причем очень важно, чтобы он(она) одновременно обладал обоими качествами.

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

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

1. Итак, надеюсь, вы заучили мантру и встречаете кандидата. Прежде чем переходить к делу, потратьте одну-две минуты, чтобы немного “расслабить” человека. Спросите, как он добрался, легко ли вас нашел. Предложите чай. Для любого кандидата собеседование – это стресс, и потратив эти две минуты, вы  сможете получить больше информации и лучше провести интервью. Не забудьте представиться, назвать свою роль, и рассказать о цели собеседования: о позиции, на которую мы собеседуемся и о том, как пройдет интервью (т.е. структуру, которую я и описываю).
2. Дальше идет очередь рассказа о прошлых проектах. Даже если вы читали резюме, то все равно попросите кандидата рассказать о его прошлых проектах. Если человек “застрял”, то просто читая в CV название или описание прошлого проекта, вы можете сказать “расскажите, пожалуйста, об этом чуть подробнее”. Слушая этот рассказ, вы должны обратить для себя внимание сразу на несколько моментов:
   • Понятность изложения. Даже если человек рассказывает о сложном научном проекте или бизнес области, мало известной лично вам, то он может делать это понятным языком или наоборот, используя кучу сленговых выражений (тем самым показывая свой снобизм, свое превосходство). Если кандидат может объясняться доступным языком, то это означает, что он способен объяснить сложные вещи, адаптируясь к уровню собеседника. Например, он сможет простыми словами объяснить заказчику выгоды от использования новых библиотек, изменений в старом коде, автоматизации тестирования (нужное подчеркнуть) и т.п. Также с другими членами команды, он наверняка быстро найдет общий язык.
     Однажды мне рассказали о достаточно сложном проекте для медицины так, что я до сих пор считаю, что я запросто мог бы его использовать 😉
   • Также в рассказе должна присутствовать страсть. Как говорить Джоэль: неважно, позитивная или негативная (как, например, рассказ о недальновидном или просто глупом начальнике), важно чтобы она была. Даже если вы не видите “огонька” в рассказе о прошлом месте работы, то можно спросить о самом лучшем и самом плохом проекте, где он работал. Важно помнить, что если человека ничего не интересует, то вы никак не сможете “мотивировать” такого человека. Он будет просто “отсиживать” свои часы и делать не больше среднего работника. С командной работой тоже могут в будущем возникнуть нюансы.
   • Ну и слушая рассказ о прошлой работе, обращайте внимание на примеры коллективной работы, а особенно на те случаи, когда кандидат проявлял инициативу (или даже лидерские качества). Важно, что если даже в проекте были проблемы, а кандидат выступил с предложением или просто собрал команду, чтобы вместе придумать решение – это хорошие проявления лидерства (пусть даже вы собеседуете рядового разработчика). Я могу, конечно, сослаться на концепцию “проактивности”  у Стивена Кови или других авторов, хотя объяснение может быть и проще. Любой пример того, что человек добился чего-то, преодолевая препятствия – уже хороший знак того, что он умеет доводить дело до конца.
3. После того, как вы достаточно узнали об опыте кандидата, наступает очередь простых технических вопросов. Обычно я прошу написать какую-то простую функцию, на языке, основном для этой вакансии. Что-то типа “массив целых чисел заполнить случайным образом и выкинуть от туда все двойки”. Это должно быть что-то достаточно простое и не требующее знания сложных алгоритмов. Да,  компилятора нет под рукой, не страшно, мы не будем обращать внимание на мелкие ошибки 😉  Суть этого шага – узнать умеет ли кандидат писать код, и важно как быстро он справится с таким простым заданием. Кому-то нужно сначала набросать пример кода, а кто-то сразу начнет рассказывать, как он видит решение и записывать код по ходу рассказа. Как видите, вопрос был достаточно размытый и по ходу того, как человек крутит его в голове, у него должны появиться разумные и иногда очень интересные уточняющие вопросы (типа какой длины массив и т.п.) – все это признаки хорошего специалиста. Плохой специалист может надолго уйти в себя и в лучшем случае признаться, что не понял, а в худшем вообще ничего внятного не написать.
   Однажды, у меня был кандидат, который долго рассказывал о прелестях объектно-ориентированного проектирования с помощью приложения Rational Rose, а на мой вопрос “в каком IDE вы работаете” посмотрел на меня удивленно и выдал: “я же говорю – мы все делаем в “Розе”.
   Если вы собеседуете не разработчика, а скажем тестера (или  QA специалиста), то можно, например, попросить придумать возможные тесты для формы создания записи о сотруднике, где есть 4-5 полей разного типа. Так или иначе, вы можете выделить простые технические вопросы, для своей области.
4. К  сложным техническим вопросам можно переходить, когда кандидат успешно справился с простым заданием. Тут уже вам решать насколько глубоко прощупывать его знания. Если рекрутеры давали какой-то технический тест, то можно использовать его как “повод для разговора” и попросить рассказать о тех вопросах, где он допустил ошибку. Главное не задавать “энциклопедических” вопросов, которые требуют наличия справочника под рукой или наличия практического опыта.
5. После того, как “отстрелялись” с сугубо технической частью, нужно потратить еще немного времени и узнать побольше о кандидате вне его профессиональной деятельности. Я много работаю с иностранными заказчиками, поэтому эта часть носит характер «About myself» кандидата и заодно проверяется уровень английского у кандидата. Кроме базовых вопросов о семье и хобби, остальные предлагаю придумать вам самим и рассказать  мне и читателям. Джоэль Спольски много пишет о “политкорректных” вопросах, хотя для нас это не так актуально 😉
6. Ну и предпоследний, немаловажный, этап – это презентация самого проекта, которую проводите вы сами. Даже если кандидат вам не понравился в самом начале, вы можете пропустить сложные вопросы, но оставьте эту часть. У кандидата есть друзья и коллеги, поэтому если вы интересно расскажете о проекте, возможно, кто-то другой захочет к вам прийти. А уж если кандидат вам подходит, и самому понравился, то во многом от вашего красочного рассказа зависит, будет ли он у вас работать.
7. Обязательно, в конце оставьте время и место для ответов на вопросы кандидата. Как бы хорошо рекрутеры не рассказывали про компанию в целом, все равно останутся вопросы. Потрудитесь на них всесторонне ответить или хотя бы сообщить, что вы не можете этого сделать и посоветовать, у кого можно получить эту информацию.

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

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