По роду деятельности приходится часто заниматься подбором персонала. Время от времени мы ищем новых сотрудников в свою компанию, а иногда помогаем клиентам отбирать лучших кандидатов на их вакантные позиции. За последние 15 лет довелось собеседовать совершенно различных специалистов: ИТ-директоров, руководителей среднего звена, технических специалистов, консультантов, менеджеров ИТ-процессов, тренеров, бизнес-аналитиков, программистов, всевозможных администраторов, главных по QA и даже, страшно сказать, методологов, скрам-мастеров и эджайл-коучей.
В условиях катастрофического дефицита времени собеседования необходимо делать как можно более сжатыми. При этом за сильно ограниченное время требуется понять: стоит ли с кандидатом разговаривать дальше? Недавно поймал себя на мысли, что так или иначе использую для решения этой задачи простые маркеры.
Например, разработчика ПО можно спросить, знает ли он кто такой Мартин Фаулер? Если ответ отрицательный, то с очень большой вероятностью перед вами кодер, не задумывающийся о том, что работа может быть организована по-разному, а супергениально написанная процедура не всегда несёт ценность заказчику. И лишь слышавший слово “рефакторинг“, но не понимающий что это, как и зачем.
Хороший вопрос для бизнес-аналитика – уточнить, чем отличается функциональная архитектура от системной. Засекаем время, через пять минут либо радость, либо грусть.
В беседе с архитектором поинтересуйтесь, что он думает о книге “Building Evolutionary Architectures“, и вы поймёте из какого времени кандидат – до миллениума, либо из современных.
Любого кандидата на работу в продуктовую команду (не важно: на роль аналитика, разработчика, тестировщика, администратора…) можно попросить объяснить как построить конвейер развёртывания. Не по верхам, не концептуально, а на деле – когда что происходит и зачем. И при чём здесь разработка в одной общей ветке кода.
Лучший вопрос для того самого эджайл-коуча – попросить его объяснить разницу между Agile Coach и Scrum Master. Буквально через три с половиной минуты можно понять есть ли смысл тратить время дальше.
Классический тест для кандидата на любую позицию, связанную с управлением качеством, прост. Даёте утверждение: “Тестирование – худший способ обеспечения качества”, и просите либо опровергнуть, либо объяснить. Справляются немногие. Тех, которые справляются, можно дополнительно попросить пояснить, почему количество найденных дефектов не может быть метрикой для этапа тестирования в жизненном цикле разработки ПО.
Вообще, тест на метрики является почти универсальным и срезает наибольшее число кандидатов. Нужно лишь поинтересоваться за что человек отвечал на прошлой работе и попросить привести примеры KPI, характеризующих достижения или неудачи.
Таким образом, получается, что для большинства современных позиций в ИТ можно подобрать сравнительно простые и короткие тесты на профессиональную пригодность. Что меня пугает больше всего, так это не вопрос поиска и отбора кандидатов, нет. Меня пугает, что те же самые короткие тесты, вполне возможно, уже имеющиеся и работающие сотрудники не пройдут. Что же с этим делать? У всех ведь нынче цифровая трансформация, а знания очень, очень быстро устаревают. На кого же опираться?
Очень интересно.
Олег, а как мог бы тестовый вопрос для специалиста поддержки и эксплуатации?
Вопрос не праздный. В настоящее время мы даем кандидату в службу поддержки даем тесты и вопросы, ориентированные скорее на разработчиков, так уж исторически сложилось. Хотелось бы уйти от этой практики и оптимизировать процесс.
Спасибо.