Егор Павловец методом проб и ошибок разработал алгоритм, который позволяет ему проводить собеседования с QA-инженерами, укладываясь в 35 (максимум — в 45) минут.

Читать далее…

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

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

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

Проблема N1: затяжные собеседования с 80% «сильных теоретиков»    

Обычно, когда открывается позиция джуниор-тестировщика, от желающих отбоя нет. На интервью сразу заметно, что 80% соискателей реально сильно подготовились по теории. На любой стандартный вопрос у «сильного теоретика» всегда готов ответ. И выходит, что из 10 человек — 8 показывают примерно одинаковый уровень.

На первых порах это обстоятельство было нашим главным тормозом. Да, когда начинаешь копать, сразу выявляются белые пятна. Но такие «раскопки», когда их приходится проводить в 80% случаев, отнимают существенно больше времени и надолго отрывают от горячей технической задачи по текущему проекту.

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

Проблема N2: тестовое задание с недельной отсрочкой

После некоторого анализа мы приняли первую попытку улучшить процесс. Да — добавили тестовое задание для junior-тестировщиков.

Тестовое задание заключалось в необходимости протестировать видоизменённое приложение из примеров приложений Android SDK, в которое мы умышленно вносили дефекты. Соискатель должен был написать отчёт по дефектам в течение недели.

В результате из 8 специалистов, хорошо освоивших теорию, отсеялось около 6. Выбор из оставшихся двух уже обосновывался косвенными показателями (креативность подхода к выполнению тестового задания, оформление отчёта, скорость выполнения задания).

Одна девочка вообще буквально за выходные выполнила тестовое задание, обставив около десятка конкурентов-парней по скорости и качеству выполнения. Женя, привет!  

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

KPI: отсеивание «болтунов» с запросом на зарплату в $2000

Стало очевидно, что необходимо тестовое задание включать прямо в процесс собеседования. Ведь всё равно у нас уже есть на руках приложение, в котором заведомо известны все дефекты.

Вопросы по теории тоже были тщательно переработаны. Мы выбрали 15 блиц-вопросов на 15 минут, на сколько из них соискатель отвечает — столько баллов и идёт в зачёт. Известных дефектов было всего около 10. Итого максимум 25 баллов.

Получилась своеобразная KPI (Key Performance Indicators, ключевые показатели эффективности) таблица соискателей — по теории и по практике.

Забавно, но никто ни разу не смог набрать максимум, хотя были люди, которые находили такие дефекты, о которых даже мы не знали!

По результатам нескольких десятков собеседований сразу стало очевидно, что некоторые соискатели — откровенные болтуны, которые при всём великолепном знании теории не смогли найти даже одного-единственного дефекта в приложении из двух экранов. И при этом с запросом на зарплату в 2000$!

Ребят с первых трёх позиций на вершине списка мы и наняли к себе в команду. В процессе работы они действительно проявили свой багхантерский талант. Каждый руководитель ведёт метрики эффективности, так вот эти ребята находили от 80 до 120 дефектов в месяц в таком приложении, как Prestigio eReader.

Сюрпризы 35-минутного собеседования

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

Например, во время быстрого опроса по теории около десятка человек просто сказали: я ничего не знаю; теорию не буду отвечать — ни на один вопрос.

После просьбы протестировать приложение заметки (2 экрана и меню, из серии примеров в Android SDK) некоторые из кандидатов предположили, что мы хотим воспользоваться их трудом в течении этих 15 минут, чтобы самим баги не искать. От такой дичи в ступор впали уже мы с эйчаром.

Табу на «мы вам перезвоним»  

Каждому человеку, который по своим KPI нам точно не подходил, мы не говорили печально известную фразу «мы вам перезвоним». А сразу указывали на слабые стороны, которые нужно подкачать, чтобы профессионально подрасти.

Расставались почти друзьями, поскольку давали реально нужную для соискателя обратную связь.

Резюме: отличные результаты на всех уровнях — от джуниора до сеньора

Конечно, невозможно вложиться в жёсткое ограничение 35 минут. Но ни одно наше собеседование не длилось дольше 45 минут.

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

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

Кстати, данный KPI подход отлично показал себя на всех уровнях соискателей на QA позицию — от джуниора до сеньора. Мы даже вопросы не меняли.

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

Бонус: список вопросов позапрошлогоднего интервью

1. Что делает QA команда?
2. Что делает QC команда?
3. В чём разница между QC и QA?
4. Какие вам известны техники тестирования «чёрным ящиком», которые также используются для дизайна тест-кейсов?
5. Вы использовали на практике тестирование методом «белого ящика»?
6. Расскажите поподробней, какие техники используются в методе тестирования «белого ящика»?
7. Назовите обязательные критерии тестового плана?
8. Как определить, что тестирование релиз-кандидата завершено?
9. Напишите команду установки Android-приложения на смартфон с помощью командной строки.
10. Напишите команду удаления Android-приложения с помощью командной строки.
11. Вы получили новое Android-устройство, сделали первый его запуск, прошли мастер настройки, но не можете подключить устройство к компьютеру. Что не так и как это исправить?
12. Чем вы пользуетесь из инструментов Android-разработчика (из SDK и в настройках самого телефона — для разработчиков)?
13. Как вы фильтруете вывод логкэта, чтобы получать только нужную информацию?
14. Что, на ваш взгляд, нужно обязательно проверять в каждом Android-приложении, если отсутствуют спецификации, требования и т. д.?
15. Какая разница между терминами Monkey testing и Ad hoc testing?

Колонка подготовлена при участии Натальи Провалинской

Место солидарности беларусского ИТ-комьюнити

Далучайся!