Привет! Я Алексей, старший тестировщик в департаменте разработки ЮMoney. С 2018 года провожу собеседования на позицию QA-инженера. В этой статье поделюсь своим опытом и взглядом команды на этот процесс. Расскажу, как мы готовимся к интервью, почему кандидаты с идеальным резюме могут не подойти и на что мы смотрим, принимая итоговое решение. Ещё вы узнаете, почему иногда мы предлагаем кандидату не ту должность, на которую он претендовал.
Подготовка к интервью
За семь лет я никогда не приходил на собеседования неподготовленным. Продуктивная встреча требует усилий с обеих сторон. Моя подготовка выглядит так: я анализирую резюме кандидата и выписываю ключевые моменты, которые хочу прояснить. Чем подробнее резюме, тем больше вопросов возникает. Я смотрю на:
навыки и опыт — в каких проектах человек участвовал, какими инструментами владеет;
глубину знаний — насколько детально он знаком с заявленными технологиями;
трудовую историю — как часто соискатель меняет компании.
На основе этого я формирую вопросы. Например:
Если кандидат пишет, что разрабатывал фреймворк для тестирования, я спрошу о его личном вкладе. Часто выясняется, что человек просто «был в проекте», но не делал ничего существенного.
Если в резюме перечислен пул инструментов (Lens, Jenkins, TeamCity), я обязательно спрошу, как именно кандидат с ними работал. Иногда соискатель после единичного использования ПО выносит его в ключевые навыки. Мне важно понять реальный опыт использования технологии — условно, запускал ли человек готовые пайплайны или же самостоятельно правил и писал скрипты.
У меня нет жёсткого шаблона для всех интервью, но я всегда держу под рукой список вопросов как памятку и план. Интервью выстраиваю как глубокий диалог: задаю первый вопрос, слушаю ответ и цепляюсь за детали, уходя вглубь темы. Это помогает раскрыть реальный опыт собеседника и делает разговор живым.
Наблюдение: в резюме нередко преувеличивают знания и навыки, особенно соискатели-джуны. Многие составляют описание на несколько страниц. Но во время разговора выясняется, что половину из списка человек совсем не знает или не делал. Кандидаты с более лаконичными резюме часто оказываются сильнее.
Вывод: много текста ≠ много опыта. Не указывайте то, чем не владеете, — это быстро раскроется в диалоге.
Как проходит интервью
Для нас важно, чтобы кандидат чувствовал себя участником диалога, а не студентом, сдающим экзамен. У нас в команде царит дружелюбная атмосфера, и мы строим интервью в той же парадигме. Чтобы соискатель привык к обстановке, в начале встречи HR рассказывает ему, из чего будет состоять беседа. План обычно такой:
Знакомство. Кандидат рассказывает о своём опыте и проектах, а мы — о компании, команде и продуктах, над которыми работаем.
Теоретическая часть. Например, обсуждаем такие темы, как API, базы данных, клиент-серверную архитектуру, брокеры сообщений, сетевые протоколы.
Практическое задание. Предлагаем практическую задачу, похожую на те, которые мы решаем каждый день.
Ответы на вопросы. Обычно в конце кандидат задаёт нам вопросы — о проектах, инструментах, условиях.
Во время знакомства с командой новый сотрудник узнаёт о процессе адаптации, который поможет ему плавно влиться в работу. Также на первые три месяца за ним закрепляется наставник — опытный сотрудник команды, который помогает разобраться с задачами, инструментами и может ответить на любые технические вопросы.
Как мы проверяем техническую экспертизу
Техническую экспертизу мы проверяем в несколько этапов. Обычно в интервью участвует несколько человек: сотрудник, руководитель отдела, HR. Перед собеседованием мы обсуждаем, какие практические задачи предложить кандидату в зависимости от его опыта и требований позиции.
Встречу всегда начинаем с несложных вопросов. Это помогает кандидату настроиться на диалог, а нам оценить, как он разбирается в ключевых концепциях и принципах работы, какой у него кругозор в предметной области. По сути, соискатель на позицию QA-инженера должен быть IT-инженером, который умеет ориентироваться в популярных стандартах отрасли и протоколах, может доступно объяснить основные моменты. Нередко бывает, что даже с базовыми вопросами кандидат не справляется, поэтому дальнейшее общение теряет смысл.
Экспертизу мы оцениваем по нескольким критериям:
владение терминологией — понимает ли кандидат суть процессов;
глубина владения инструментами — насколько уверенно он знает технологии из своего стека;
способность разбираться в деталях — может ли кандидат объяснить нюансы и особенности технологии.
Так мы можем отличить шаблонные ответы от тех, которые основаны на реальном опыте. После беседы мы даём соискателю практическое задание, например:
Предлагаем документацию API, просим составить и отправить запрос через REST-клиент, затем интерпретировать ответ.
Просим подготовить тест-план по тестированию API.
Даём задание на модификацию запроса, чтобы получить определённую ошибку.
Таким образом мы проверяем не только навык работы с инструментом, но и логику, рассуждения человека — как он решает задачи и реагирует на ошибки.
Значимость софт-скиллов
На собеседовании мы оцениваем не только технические знания кандидата, но и его способность учиться. Даже если у соискателя есть небольшие пробелы в знаниях, но мы видим его интерес к предлагаемым задачам и готовность учиться, мы можем дать ему шанс проявить себя во время трёхмесячного испытательного срока.
Для нас софт-скиллы не менее важны, чем хард-скиллы. Это соответствует принципу Agile-манифеста: «Люди и взаимодействие важнее процессов и инструментов». С ним перекликается наш внутренний принцип ЮMoney: «Мы действуем как команда и ценим вклад каждого».
Я придерживаюсь позиции, что зачастую проще подтянуть технические навыки человека, чем изменить его личностные качества.
Оценка софт-скиллов — задача субъективная. Мы обращаем внимание на:
культуру общения — как кандидат разговаривает, умеет ли слушать или перебивает;
работу с информацией — насколько легко адаптируется к новым вводным;
умение отстаивать свою точку зрения — как человек это делает, если понимает, что прав.
Это позволяет понять, как быстро мы придём к взаимопониманию. Не менее важно, как человек просит о помощи и воспринимает подсказки. Например, если кандидат затрудняется с ответом, я предлагаю помощь и смотрю на его реакцию. Или добавляю в задание неочевидный момент и жду, задаст ли он уточняющий вопрос. Потому что, если сотрудник сталкивается с трудностями, нам нужно, чтобы он не молчал, а обращался за помощью — так проблема решается быстрее, а команда не срывает сроки.
Как принимаем итоговое решение
Сразу после собеседования мы обсуждаем, подходит ли нам кандидат. Каждый участник интервью делится впечатлениями. Мы анализируем технические навыки соискателя и оцениваем, насколько легко и продуктивно прошло общение.
На основании этого обсуждения формируется общая оценка. Такой формат помогает нам получить командное видение, а не полагаться на субъективное мнение одного человека.
Хотя окончательное решение остаётся за руководителем, оно никогда не бывает единоличным: руководитель учитывает мнение команды. Если мнения разделились и есть сомнения — можем назначить дополнительный этап собеседования и привлечь к нему других сотрудников отдела.
Мы всегда смотрим на потенциал кандидата. Если понимаем, что он не подходит на заявленную позицию (например, автоматизатора в команду разработки инструментов тестирования), но видим его сильные качества для другой роли (скажем, QA в команду тестирования мобильных приложений), мы можем предложить человеку альтернативную должность — при условии, что есть открытая вакансия.
Заключение
Наш метод — комплексная оценка. Нам нужен не просто специалист «из учебника», а человек с глубокими техническими знаниями, развитыми софт-скиллами и искренней мотивацией развиваться. Поэтому мы так тщательно готовимся к каждому интервью, смотрим на реальный опыт человека, а не на список пунктов в его резюме, и принимаем командное решение.
***
Как проходили ваши собеседования на позицию QA-инженера? Поделитесь своим опытом в комментариях!