Короткие тесты на профессиональную пригодность

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

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

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

Хороший вопрос для бизнес-аналитика — уточнить, чем отличается функциональная архитектура от системной. Засекаем время, через пять минут либо радость, либо грусть.

В беседе с архитектором поинтересуйтесь, что он думает о книге «Building Evolutionary Architectures», и вы поймёте из какого времени кандидат — до миллениума, либо из современных.

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

Лучший вопрос для того самого эджайл-коуча — попросить его объяснить разницу между Agile Coach и Scrum Master. Буквально через три с половиной минуты можно понять есть ли смысл тратить время дальше.

Классический тест для кандидата на любую позицию, связанную с управлением качеством, прост. Даёте утверждение: «Тестирование — худший способ обеспечения качества», и просите либо опровергнуть, либо объяснить. Справляются немногие. Тех, которые справляются, можно дополнительно попросить пояснить, почему количество найденных дефектов не может быть метрикой для этапа тестирования в жизненном цикле разработки ПО.

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

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

 

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Новая полезная деловая игра
 

DevOps: погружение

Короткий, но ёмкий семинар для ваших сотрудников о самой сути
 

DevOps: резюме для руководства

Семинар на два часа для высших руководителей бизнеса
 

Комментарии и мнения

  1. Юлия

    Очень интересно.

    Олег, а как мог бы тестовый вопрос для специалиста поддержки и эксплуатации?

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

    Спасибо.

    1. Олег Скрынник Автор

      Юлия, с ходу могу предложить два варианта.

      В своё время, пусть и очень давно, использовал для проверки инженеров поддержки простой тест аббревиатур. Кандидат должен был на бумажке расшифровать TCP/IP, DNS, DHCP, HTTPS, MS SQL, и даже IDDQD. Это позволяло фильтровать неучей очень даже бодро.

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

      1. Юлия

        Спасибо, Олег.

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

    2. Владимир Невский

      Для спец. Службы поддержки, важны не столько знания и исполнительность, сколько умение общаться и принимать решения. Поэтому, кандидату даёте вводную: ПО, которое не поддерживается тех.подержкой и официально не разрешено к применению (например, Фотошоп); обращается пользователь, который просит помочь с программной; Ваши действия? Адекватный кандидат говорит: типа, помогать не буду, т.к. запрещено к использованию. Вы даёте новую вводную, типа, пользователь — секретарь Главного, готовит материалы к важной презентации, если не поможете — организация понесет убытки. Ваши действия? Адекватный ответ — нужно узнать у Руководителя, как быть. Новая вводная — руководитель вне досягаемости, связаться не можете; нужно срочно — Ваши действия? И тут важна реакция кандидата и каждое сказанное им слово. ИМХО, идеальный кандидат должен сказать, что обязательно поможет пользователю, но при этом соблюдет рамки правил (закона). Как именно, он сделает последнее — будет говорить о его опыте, умении общаться с людьми и самостоятельно принимать решения.

      2
      2

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20