За свою карьеру я провёл десятки собеседований. С каждым годом убеждаюсь: успешное интервью – это не про шпаргалки и выученные определения. Я не даю тест «угадай термин из ISTQB», потому что те, кто действительно умеет тестировать, это покажут и без зубрёжки.
Вот что я обычно спрашиваю у кандидатов и почему.
Всё зависит от проекта
Сначала – немного очевидного. Нет универсального шаблона собеседования. Всё зависит от задач:
- Если проект – это API и база данных, значит, нужны SQL и логика.
- Если проект – UI-heavy и фокус на UX, значит, важны внимательность, чувство интерфейса, коммуникация.
- Если это продукт в постоянной разработке без документации – пригодятся гибкость и мышление, а не 100% знание всех техник.
Я не «гоняю» по теории. Потому что, если человек не знает базу, он всё равно не справится с моими задачами. А если знает, это сразу станет видно по его действиям и рассуждениям.
Техники тест-дизайна – наше всё
Тест-дизайн – это первое, что показывает, умеет ли человек думать как тестировщик.
Я даю практическую задачу, и для её выполнения нужно составить набор проверок, а без знания техник можно напроверять лишнего или не проверить нужное.
И тут становится видно:
- думает ли человек о граничных значениях;
- видит ли классы эквивалентности;
- умеет ли структурировать свои проверки.
Это простая задача, но она очень быстро всё показывает.
SQL и базы данных — по ситуации
Если на проекте нужны БД – будет задача. Она может быть довольно простая, с запросом и объединением данных из двух таблиц, группировкой.
И тут я смотрю:
- как быстро кандидат начнёт писать или проговаривать запрос;
- как хорошо знает синтаксис;
- умеет ли пользоваться JOIN-ами.
Troubleshooting – моя любимая часть
Это не совсем вопрос, а скорее сценарий для размышлений.
Я даю какую-то ситуацию, например: «Пользователь жалуется, что не может залогиниться. Что ты будешь делать?»
И дальше наблюдаю:
- какие версии проблемы предлагает кандидат;
- какие уточняющие вопросы задаёт;
- какие инструменты использует (DevTools, Postman, логи);
- как рассуждает, если не знает ответа;
- умеет ли признавать, что чего-то не знает.
В этой задаче нет правильного ответа. Мне важен подход и рассуждения.
Ограничение по времени – и что ты будешь делать?
Одна из моих «любимых» ситуаций: «Приходит Project Manager и заявляет, что у тебя один день на тестирование огромной фичи (вместо двух дней).»
Что сделал бы кандидат в этом случае?
Здесь смотрю:
- умеет ли кандидат приоритизировать;
- понимает ли, что такое smoke testing, критические пути, риски;
- может ли объяснить свою позицию руководителю;
- как преподнесёт компромисс менеджменту.
Это не про “угодить всем”, а про зрелое решение в условиях ограничений.
А ещё – софт-скиллы
Пока мы всё это обсуждаем, я наблюдаю:
- как человек слушает;
- перебивает ли;
- как аргументирует, соглашается, отстаивает;
- как держится, если не знает ответа.
Я сразу прикидываю как он впишется в команду, смогут ли к нему подойти джуны, найдёт ли общий язык с разработчиками?
Иногда именно эти детали перевешивают технический скилл.
Технические знания можно подтянуть сравнительно быстро, а вот на прокачку софт-скиллов могут уйти годы.
Вместо вывода
Я не ищу идеального кандидата. Я ищу человека, с которым можно работать, расти и вместе решать задачи.
Если вы умеете думать, готовы учиться, умеете признавать своё «не знаю» и при этом не теряться – вы справитесь. Всё остальное – вопрос времени и практики.
Какие странные или интересные вопросы/задания вам попадались на собеседованиях? Давайте обсудим в комментариях!