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