Собеседование с обеих сторон. Личный опыт работы с вакансиями Middle QA

8 ноября
Дмитрий Волошин, QA Engineer
Собеседование с обеих сторон. Личный опыт работы с вакансиями Middle QA
Я долго проводил интервью и определял методику подбора новых кандидатов в свою команду. На некоторое время делал перерыв в карьере, и чтобы вернуться, пришлось посмотреть на процесс с другой стороны.

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

Немного истории

За первые шесть лет работы в менеджменте отдел из двух человек, который я возглавил, удалось расширить до 34-х. Это коррелировало с ростом компании от 60 до около 300 сотрудников. Компания занималась аутсорсинговой разработкой и была ориентирована на рынок мобильных приложений. Основной поток клиентов приходил с разных фриланс-площадок, а QA набирали преимущественно уровней Junior и Middle.

Для полноты картины уточню, как я понимаю профессиональные грейды:

  1.  Junior — сотрудник, требующий надзор ментора. Возможно, с минимальным опытом работы или вовсе без него. Уточню, что интернов в моей прежней компании в штат не зачисляли.
  2.  Middle способен справиться с тестированием проектов самостоятельно. Он, однако, не всегда предлагает оптимальные решения, потому периодически требует консультации и ревью.
  3. Senior может принимать проектные решения, анализировать риски и выносить их на обсуждение. Его теоретические знания подкреплены опытом реальных проектов.

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

Поскольку я уже несколько лет занимался организационными вопросами и координацией ресурсов, начал рассматривать инженерные вакансии уровня Middle. Я понимал, что мог отстать и мои технические знания в чем-то просели. К тому же, у меня не было опыта ведения масштабных проектов — максимальное количество QA в одном проекте в компании, из которой я уходил, не превышало четырех. 

Так я после перерыва попал на собеседование в качестве кандидата. И это, оказалось весьма интересным опытом.

Структура собеседований

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

На первом этапе рекрутер запрашивал у QA-менеджера  профиль вакансии с описанием, кто именно и с каким знаниями нужен.

Потом общался с кандидатами, проверяя:

  • соответствие опыта составленному профилю;
  • совместимость soft skills с культурой компании;
  • знание английского.

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

  1. В первой он просил кандидата описать прежний опыт, задавая уточняющие вопросы.
  2. Вторая часть включала проведение опроса из трех блоков:
    a) Базовая теория тестирования.
    До десяти вопросов по теории (почему она важна, думаю, объяснять не обязательно). Для уровня Middle необходимо задавать и базовые вопросы — практика показала, что кандидаты часто забывают или просто не знают базовых вещей.
    б) Технические вопросы.
    Мы подбирали до 20 вопросов по тем технологиям, с которыми предстоит работать в конкретном проекте. Этот блок был самым важным для проверки, насколько релевантен опыт кандидата.
    c) Знание профильной области.
    Разработка мобильных приложений интересна тем, что каждый месяц здесь появляется что-то новое, к чему приходится адаптироваться по ходу проекта. Критически важным для проекта может оказаться, знает ли QA, когда именно выйдет новая версия iOS или какие браузеры есть на смартфонах определенного производителя. Мы задавали примерно пять вопросов. Правильный ответ на них становился большим преимуществом для кандидата, хотя блок никогда не считался решающим.
  3. Третья часть интервью состояла из двух задач:
    а) Задача, связанная с техниками тестирования.
    Важно было понять, применяет ли кандидат знание этих техник при поиске решения.
    б) Задача «как бы вы протестировали популярный продукт».
    Учитывалось, какие вопросы человек задает, прежде чем приступить к решению. Понимает ли соискатель, что к тестированию нужно подходить комплексно, что, к примеру, мобильное приложение Booking.com это не только фронтенд, но и серверная часть. Учитывает ли он  разные виды тестирования.
  4. Собеседование заканчивалось тестовым заданием на 15 минут. Иногда оказывалось, что соискатель, владеющий теорией, на практике ее не применяет и пропускает явные баги.

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

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

В целом, техническая часть собеседования занимала около часа.

Альтернативные структуры

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

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

Отличия от моего опросника — по каждому отмеченному пункту заготовлено 5–10 вопросов, и структура соблюдается вне зависимости от опыта кандидата. Собеседования такого формата занимает более двух часов, они требуют проработанной карты уровней знаний сотрудников внутри компании. Результат — довольно точная оценка уровня кандидата, но процесс напоминает допрос и рискует показаться ему крайне неприятным.

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

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

Кандидаты воспринимают этот подход положительно только при правильной организации процесса.

Ошибки при поиске соискателей, на которые я обратил внимание

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

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

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

  • Поверхностная проверка английского. Практика показала  что, рекрутеры спрашивают одно и то же: «Опишите ваш рабочий день», «Опишите ваше хобби» «Опишите ваш последний проект». Все эти темы после четвертого собеседования кандидаты знают наизусть. Такое собеседование мало сообщит о том, как потенциальный сотрудник сможет обсуждать технические темы или общаться с клиентом. Лично я старался проверять письменный английский.
  • Затягивание с ответами вакансий. «Подождите несколько дней, мы пригласим вас на второй этап собеседование с менеджером/клиентом». В итоге ждать реакции приходится неделю, а за это время у активного соискателя уже появляется несколько предложений. Понятно, что иногда это делается сознательно — компании хотят приглашать тех, кто действительно мотивирован работать именно с ними. Но в итоге на основании внутренних отзывов проектных команд отбор проходят спорные кандидаты из сформировавшегося пула. Даже в условиях самой жесткой бюрократии нужно искать лазейки для сокращения сроков принятия решений.

Заключение

Выбор подхода к собеседованию зависит от уровня компании, специфики проектов и требований бизнеса. Готовой формулы — «бери и используй» — здесь не будет.

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

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

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