Як відповідати на System Design співбесіді

Що саме перевіряють у QA System Design

System Design для Senior QA Automation складається з двох різних частин. Перша частина: дизайн тест-системи. Вас просять спроектувати фреймворк, CI-пайплайн, стратегію тестових даних або стратегію тестування для мікросервісів. Друга частина: розуміння бекенду. Вам показують схему "клієнт, load balancer, сервіси, кеш, БД, черга" і питають, що тут може зламатися і як ви це протестуєте.

Інтерв'юер не чекає ідеальної архітектури. Він дивиться на чотири речі:

• чи ставите ви уточнювальні питання замість того, щоб одразу малювати;
• чи думаєте ви про масштаб: кількість тестів, команд, середовищ, час прогону;
• чи бачите ви компроміси і можете пояснити, чому обрали одне, а не інше;
• чи вмієте ви виміряти результат: метрики, SLA пайплайна, рівень flaky.

Типова помилка Middle-кандидата: почати з інструменту. "Візьмемо Playwright і Allure" - це не дизайн, це вибір бібліотеки. Senior починає з проблеми: хто користувачі фреймворку, скільки тестів, які обмеження за часом, які ризики бізнесу.

Для фінтеху додайте ризики, які інтерв'юер точно оцінить: гроші не можна списати двічі, баланс не може піти в мінус без дозволу, кожна операція має бути відстежуваною. Якщо ви природно згадуєте ідемпотентність і аудит, це сильний сигнал.

Структура відповіді: вимоги, шари, рішення, trade-offs, метрики

Щоб не загубитися за 40-60 хвилин, тримайтеся однієї схеми. Вона працює і для тест-фреймворку, і для бекенд-задачі.

1. Вимоги. Функціональні: що система має робити. Нефункціональні: скільки тестів, за який час, скільки команд, які середовища, які інтеграції. Уточніть цифри вголос.
2. Шари. Розкладіть систему на блоки: для фреймворку це тести, бізнес-кроки, page objects і API-клієнти, фікстури, конфіг, звітність. Для бекенду це клієнт, LB, сервіси, сховища, черги.
3. Рішення. Для кожного шару скажіть, що конкретно ви робите і чому.
4. Trade-offs. Чим ви платите за рішення: швидкість проти ізоляції, вартість інфраструктури проти часу фідбеку, реалістичність даних проти стабільності.
5. Метрики. Як ви зрозумієте, що рішення спрацювало: час пайплайна, flaky rate, час до фідбеку на PR, кількість багів, що пройшли в прод.

Вимоги -> Шари -> Рішення -> Trade-offs -> Метрики
  |          |         |           |            |
 цифри    блоки    чому так    чим платимо   як міряємо

Корисна звичка: після кожного блоку коротко підсумовувати і питати інтерв'юера, чи йти глибше. Так ви керуєте часом і показуєте, що вмієте працювати зі стейкхолдерами.

Які питання уточнити на старті

Перші 5 хвилин - найважливіші. Хороші уточнювальні питання одразу показують рівень. Ось набір, який варто мати в голові.

Для тест-системи:

• Скільки тестів зараз і скільки буде через рік? Які типи: unit, API, e2e?
• Яка ціль за часом: фідбек на PR за 10 хвилин чи нічний прогін?
• Скільки команд пишуть тести? Один репозиторій чи кілька?
• Які середовища є: локальне, ephemeral на PR, staging?
• Які зовнішні залежності: платіжний провайдер, KYC, банківські API?
• Який бюджет на CI-інфраструктуру?

Для бекенд-задачі:

• Яке навантаження: RPS, пікові години, ріст?
• Що важливіше: консистентність чи доступність? Для балансу рахунку відповідь зазвичай консистентність.
• Які гарантії доставки в черзі: at-least-once чи інше?
• Чи є вимоги регулятора: аудит, зберігання даних, PCI DSS?

Не треба ставити всі питання. Оберіть 4-6 найважливіших, запишіть відповіді і далі посилайтеся на них. Якщо інтерв'юер каже "вирішіть самі", назвіть припущення вголос: "Припустимо 2000 e2e тестів, середній тест 20 секунд, ціль 15 хвилин".