Как я проводил собеседование на тестировщика

Раньше никогда не думал, что окажусь «по ту сторону баррикад». Я всегда именно проходил собеседование, а не проводил его сам. Тогда в моей компании не было более опытного сотрудника, который мог бы провести собеседование на тестировщика, поэтому выбора у меня не было. Изначально я был слегка озадачен этой перспективой, немного сомневался в своей компетенции, но потом осознал что это отличная возможность получить полезный опыт.

Подготовка к собеседованию

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

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

Чтобы систематизировать собеседование, мы создали шаблон с вопросами в Confluence. Сделали разделы по требованиям и наполнили каждый из них подходящими вопросами. Каждый раздел оценивается по 5-бальной шкале и может иметь комментарии. В комментарии я записываю подробности, или оставляю заметки.  В шаблоне также можно сохранить все записи для архива.

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

Тестовое задание для тестировщика

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

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

С какими проблемами столкнулся

Есть 2 проблемы с вопросами, которые я сейчас явно вижу.

Иногда я ловлю себя на ощущении, что мои вопросы на собеседовании тестировщика слишком сложны или наоборот слишком легкие. Стоит ли усложнить вопросы и ужесточить отбор, либо наоборот ослабить хватку. По моим приблизительным предположениям отсекается примерно 70% дошедших до меня кандидатов. Пока не знаю как оценивать этот показатель. Все прошедшие собеседование сотрудники показали себя достойно.

Еще по прежнему не уверен в том, стоит ли спрашивать теорию и основы тестирования. Обычно кандидаты проходящие через «HR фильтр» обладают опытом более 2х лет. И я сильно сомневаюсь в том, что в течении своей работы тестировщиком им не доводилось открыть википедию или хорошую книгу по тестированию, чтобы знать теорию.

Буду рад прочитать ваши комментарии.  Стоит ли задавать вопросы по теории тестирования? Как вы составляете свои вопросы? На что обращаете особенное внимание?

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

  1. Записывать беседу — отличная идея, спасибо.

    Необходимо, четко определиться с требованиями к новому сотруднику сотруднику.
    Потом по каждому требованию задавать вопросы, знает ли он что-то или нет.
    Я просто проставлял циферки от 1 до 4, где 1 — он ничего не знает, а 4 знает в совершенстве.
    Опять же, многие вещи новый сотрудник может и не знать, но ему не составит труда их выучить.
    Пример: брали автоматизатора в соседний проект, используем фрейворк Selenide — сотрудник про него ничего не слышал, но если он имеет опыт работы с Selenium, то разобраться с Selenide не будет никаких проблем.

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

    Сразу же после собеседования, необходимо написать письмо менеджеру:
    «Собеседование Иванов И.И.»
    Отметить там + и — сотруднка, общее впечатление и т.п. Также Ваше мнение, необходимо ли брать его на работу.

    • «Также обязательно задавать вопросы по резюме, даже если какие-то вещи вы и не используете в проекте.»

      А вы можете пояснить зачем (обязательно) спрашивать про то, что на вашем проекте не используется? Вы же не проводите собеседование кандидата на соответствие его резюме.

  2. Andrey Kim

    04.04.2016 в 09:20

    Спасибо за ответ. Учитывая ваш пример с Selenide. Мне кажется что хороший инженер, даже если и не знает технологию, вполне способен ее освоить за несколько дней. И вот в этом месте, мы порой с коллегами расходимся. Например кто-то считает что знание SQL можно нагуглить и подтянуть, а кто-то считает что нужно им владеть изначально.

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