Насколько готов тестировать чисто backend

Что проверяют

Хотят понять две вещи: не уйдёте ли вы через полгода, заскучав без интерфейса, и есть ли у вас навыки, без которых на бэкенде делать нечего. Следом обычно просят рассказать, как вы проверите конкретную ручку API, или дают написать SQL-запрос.

Как отвечать

Начните с прямого ответа и мотивации, а потом подтвердите его навыками из своего опыта:

• API: запросы в Postman или curl, чтение OpenAPI-спецификации, проверка кодов ответа, схемы тела, заголовков, идемпотентности. Если в проекте есть gRPC, упомяните grpcurl;
• данные: SQL на уровне JOIN, группировок и подзапросов, чтобы убедиться, что запрос действительно изменил состояние в базе, а не только вернул 200;
• асинхронные процессы: очереди вроде Kafka или RabbitMQ, проверка, что сообщение ушло и обработано ровно так, как задумано, включая повторную доставку;
• логи и метрики: поиск запроса по trace id в Kibana или Grafana;
• автоматизация: например Java с RestAssured и JUnit 5 или Python с pytest и httpx, окружение в Docker, базы через Testcontainers. Нагрузку, если спросят, через JMeter, Gatling или k6.

Опирайтесь на свои примеры: какой сервис тестировали, сколько автотестов написали, какой баг нашли только через базу или логи. Цифры и детали нужны ваши, а не из шаблона.

Если опыта в чистом бэкенде мало, скажите об этом прямо и покажите мост: вы уже смотрели запросы во вкладке Network, воспроизводили баги через Postman, писали SQL для проверки данных. Добавьте, что закроете в первый месяц, например автотесты на API в стеке команды.

Где спотыкаются

Отвечают «готов на всё» без единого инструмента. Это звучит как желание получить оффер, а не как навык.

Называют Selenium инструментом для тестирования бэкенда. Он управляет браузером и к проверке API отношения не имеет.

Проверяют только ответ ручки и не заглядывают в базу и очереди, хотя половина серьёзных багов бэкенда живёт именно там.