Сколько примерно сервисов у разработчиков

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

Не цифру, а карту системы у вас в голове: понимаете ли вы, из чего собран продукт, который вы тестировали, и где проходила граница вашей зоны. Заодно интервьюер прикидывает масштаб опыта: проверять одно приложение и проверять десяток сервисов, связанных очередями, это разная работа.

Как отвечать

Назовите порядок, а не точное число, и сразу переходите к тому, что за этим числом стоит:

• сколько сервисов было всего и сколько из них попадало в вашу зону;
• по какому признаку они разделены: домены, команды, куски бывшего монолита;
• как общаются: синхронно по HTTP или gRPC, асинхронно через очередь;
• откуда вы брали контракты: схема OpenAPI, спецификация в репозитории, слова разработчика.

Дальше самое ценное, как вы с этим работали. Поднимали ли весь набор локально через docker compose или хватало одного сервиса с заглушками на соседей, был ли общий стенд и как на нём разводились две команды, как готовили данные, которые лежат сразу в трёх базах, как понимали, в каком сервисе упало.

Если сервисов было немного, скажите честно и покажите, что разницу понимаете: маленькая система это не минус, выдуманная большая это провал на первом уточнении.

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

Называют число и замолкают. Само по себе оно ничего не стоит: интервьюер спросит, какие три сервиса вы трогали чаще всего, и ответ развалится, если за цифрой не было реальной работы.

Второе: считают сервисами всё подряд, включая базу, брокер и сторонние интеграции. Разговор сразу уходит в сторону, а собеседник делает вывод, что архитектуру системы вы не представляли.

Третье: говорят про количество, но не про связи. Для тестировщика важнее не сколько сервисов, а какие из них падают вместе и что происходит с заказом, когда соседний сервис не ответил. Именно туда и уйдёт следующий вопрос.