Как ты развиваешься как тестировщик
Что проверяют
Есть ли системность в развитии и превращаются ли новые знания в изменения на проекте. Формально вопрос про мотивацию, фактически про самостоятельность и способность приносить пользу без внешнего пинка.
Как отвечать
Разложить развитие на три слоя и по каждому дать конкретику.
- Фундамент. Техники тест-дизайна (классы эквивалентности, граничные значения, попарное тестирование, таблицы решений), сети и HTTP, SQL, устройство того продукта, который тестируешь. Это то, что не устаревает и что чаще всего проваливают на техническом интервью.
- Инструменты. Автоматизация на языке команды (Python с pytest, JavaScript с Playwright), тесты на уровне API, чтение логов и трейсов, CI, Docker, базовое понимание архитектуры сервиса и его зависимостей.
- Практика на своём проекте. Самая сильная часть ответа: что конкретно внедрил. Например, перенёс часть проверок с интерфейса на API и сократил регресс; добавил прогон тестов в pipeline; разобрал накопленные баги и нашёл общую причину, которая закрывалась одной правкой процесса.
Источники: документация и исходники своего продукта, книги по тест-дизайну, доклады с профильных конференций, публичные баг-трекеры чужих проектов, профессиональные сообщества. Сертификация вроде ISTQB даёт общий словарь, но сама по себе на собеседовании ничего не доказывает и заменой практике не служит.
Отдельно назвать привычку, которая двигает быстрее курсов: разбор каждого дефекта, ушедшего в прод. Вопрос ставится не «кто виноват», а «какой проверки не было и на каком уровне её дешевле добавить».
Цифры в ответе уместны, если они настоящие и объяснимы. Не «поднял покрытие до 90 процентов», а «полный регресс занимал два дня, после переноса части проверок на уровень API занимает четыре часа».
Где спотыкаются
Перечисляют пройденные курсы и сертификаты, не показав ни одного следа этих знаний в работе. Вторая типичная ошибка: круглые метрики вроде «ускорил тестирование на 30 процентов», которые кандидат не может разложить на составляющие.