How to answer a System Design interview

What exactly is assessed in QA System Design

System Design for Senior QA Automation consists of two different parts. The first part is designing a test system. You are asked to design a framework, a CI pipeline, a test data strategy or a testing strategy for microservices. The second part is understanding the backend. You are shown a diagram "client, load balancer, services, cache, DB, queue" and asked what could break here and how you would test it.

The interviewer doesn't expect a perfect architecture. They look at four things:

whether you ask clarifying questions instead of starting to draw at once;
whether you think about scale: the number of tests, teams, environments, run time;
whether you see the trade-offs and can explain why you chose one thing over another;
whether you can measure the result: metrics, pipeline SLAs, the flaky level.

A typical Middle candidate's mistake: starting with a tool. "Let's take Playwright and Allure" is not design, it is picking a library. A Senior starts with the problem: who the framework's users are, how many tests, what time constraints, what the business risks are.

For fintech add risks that the interviewer will definitely appreciate: money can't be debited twice, a balance can't go negative without permission, every operation must be traceable. If you naturally mention idempotency and audit, it is a strong signal.

In an interview: I understand System Design for QA as two things: how to build a scalable test system and how to test a distributed system while understanding its architecture. I always start with requirements and constraints, not tools, and finish with the metrics by which we will know the solution works.

Answer structure: requirements, layers, solution, trade-offs, metrics

To avoid getting lost over 40-60 minutes, stick to one scheme. It works both for a test framework and for a backend task.

Requirements. Functional: what the system must do. Non-functional: how many tests, in what time, how many teams, which environments, which integrations. Clarify the numbers out loud.
Layers. Break the system into blocks: for a framework these are tests, business steps, page objects and API clients, fixtures, config, reporting. For a backend these are the client, LB, services, storages, queues.
Solution. For each layer say what exactly you do and why.
Trade-offs. What you pay for the solution: speed versus isolation, infrastructure cost versus feedback time, data realism versus stability.
Metrics. How you will know the solution worked: pipeline time, flaky rate, time to feedback on a PR, the number of bugs that reached production.

Requirements -> Layers -> Solution -> Trade-offs -> Metrics
  |          |         |           |            |
numbers    blocks    why so    what we pay   how we measure

A useful habit: after each block, briefly summarise and ask the interviewer whether to go deeper. That way you manage time and show that you can work with stakeholders.

In an interview: I answer by a scheme: first I clarify requirements and numbers, then break the system into layers, propose a solution for each, talk through the trade-offs and finish with success metrics. This keeps me from jumping into tool details before the problem is understood.

Which questions to clarify at the start

The first 5 minutes are the most important. Good clarifying questions immediately show your level. Here is a set worth having in your head.

For a test system:

How many tests are there now and how many in a year? Which types: unit, API, e2e?
What is the time target: feedback on a PR in 10 minutes or a nightly run?
How many teams write tests? One repository or several?
Which environments exist: local, ephemeral per PR, staging?
Which external dependencies: a payment provider, KYC, bank APIs?
What is the budget for CI infrastructure?

For a backend task:

What is the load: RPS, peak hours, growth?
What matters more: consistency or availability? For an account balance the answer is usually consistency.
What delivery guarantees does the queue have: at-least-once or something else?
Are there regulator requirements: audit, data retention, PCI DSS?

You don't need to ask all the questions. Choose the 4-6 most important, write down the answers and refer to them later. If the interviewer says "decide yourself", state your assumptions out loud: "Let's assume 2000 e2e tests, an average test of 20 seconds, a target of 15 minutes".

In an interview: I start with questions about scale, the time target, environments and external dependencies. If there are no numbers, I state assumptions out loud myself, so that all the calculations afterwards are transparent.