Performance testing interview questions

A load test holds the expected peak and asks whether the system meets its targets there. A stress test pushes past the expected peak until something gives, to find where the limit is and how the system behaves when it is crossed — degrading politely or falling over. A soak test holds a modest, realistic load for hours, looking for the things that only appear with time: memory leaks, connection pools that never return, log volumes, database bloat. Different questions, so different durations and different pass criteria.

What they are really asking: Whether you pick a test type from the question being asked, or run "a load test" by reflex. Say what each one would *tell* you and most interviewers stop there.

The average hides the tail, and the tail is what users complain about. A run averaging 200 ms can be 95% of requests at 90 ms and 5% at 2.3 seconds — the average looks healthy and one user in twenty is having a bad time. Percentiles describe the distribution: p90, p95 and p99 tell you what the slowest slice actually experienced. Quote the percentile alongside the load it was measured at, because a p95 with no context is a number, not a result.

What they are really asking: The follow-up is usually "so which percentile should we use?" There is no universal answer, and saying p95 with confidence is a worse answer than asking what the SLA says.

Writing performance requirements that can be tested

Concurrency = throughput x response time. If you need 50 requests per second and each takes 400 ms, you need about 20 concurrent users to generate it. It is the arithmetic that connects a business target ("2,000 orders an hour") to a load model ("this many virtual users with this think time"). It also catches nonsense early: if your target throughput and your measured response time imply 4,000 concurrent users and you planned for 50, one of those numbers is wrong.

What they are really asking: Whether you can derive a load model rather than guessing a thread count. Being able to do the sum out loud is worth more than naming the law.

Free load model calculator

Think time is the pause a real user takes between actions — reading a page, filling a form. Without it, virtual users hammer the system in a tight loop and you measure something no human would ever do: far higher throughput from far fewer users. Adding realistic think time changes the concurrency you need to hit a given throughput, which is why load models built without it are usually wrong in both directions at once.

What they are really asking: A common trap question. If you say "it makes the test realistic" and stop, expect "realistic how?" — the concrete answer is that it decouples user count from throughput.

A number, a condition, and a scope. "The site must be fast" is not testable. "The checkout page returns in under 1.5 seconds at p95, with 500 concurrent users, over a 30-minute steady state" is: it names the transaction, the statistic, the threshold, the load and the duration. If any of those is missing you cannot write a pass criterion, and you will end up in a meeting arguing about whether the result was good.

What they are really asking: Really asking whether you push back on vague requirements or quietly invent your own and hope nobody notices at report time.

Questions to ask before a performance test

Error rate, before any timing at all. A run with 40% errors has no meaningful response times, because failures are usually fast and they drag every percentile down — the result will look better than a healthy run. Once errors are understood, look at response time over the run rather than the summary: a flat line and a line climbing steadily to the same average mean completely different things. Then throughput against the target, then per-transaction breakdown.

What they are really asking: One of the best questions in the set. Candidates who start with "the average response time" have usually never had to defend a result.

Open a results file in your browser

Work down the stack and correlate by time, not by hunch. Confirm the load generator is not itself saturated. Then look at the application tier — CPU, heap, GC pauses, thread pool saturation, connection pool waits — then the database for slow queries, locking and connection limits, then the network and any component in between. The skill is lining metrics up on the same timeline as the response time curve: whatever turns at the same moment is where to look next.

What they are really asking: Open-ended by design. They want a method, not an answer. Saying "I would check the database" first, with no reasoning, is the weak version.

Start small and gate on something you trust. A short smoke-level run on every merge that fails on error rate and an obviously-wrong p95 catches the crude regressions without adding twenty minutes to every build. Keep the full load test on a schedule or a manual trigger, because it needs a stable environment and realistic data. The hard part is not running the tool in CI — it is having a threshold that fails only when something is genuinely wrong, or people will start ignoring it.

What they are really asking: They are listening for whether you have dealt with flaky gates. "We failed the build on p95 and everyone disabled it within a month" is a good, honest story to have.

Performance tests in GitHub Actions

Unique where uniqueness is enforced, realistic in shape and volume, and disposable. Reusing one login across 500 threads tests your cache, not your system. Data also has to match production distribution: a table with 100 rows behaves nothing like one with 10 million, and an index that looks fine on the small one will not be. Plan how it gets reset between runs too, because a test that only passes the first time is not a test.

What they are really asking: Follow-up is usually about production data. The correct instinct is that copying real user data into a test environment is a GDPR problem, not a convenience.

Test data for performance testing

Usually the model, not the tooling. Common causes: the workload mix did not match real traffic; think times were absent or unrealistic so the concurrency was wrong; the test used a handful of accounts and a warm cache; third-party integrations were stubbed; the environment was smaller or had different data volumes; or the test ran a clean journey while production has retries, mobile clients and bots. The honest answer names how you would find out — compare production telemetry against the model you tested, and fix the model.

What they are really asking: The single most useful question in an interview. They want to see how you reason about your own work being wrong, and whether you get defensive.

Derive them from what exists. Production telemetry gives real throughput, peak hours and current response times; analytics gives journey mix; the business can usually answer "how many orders an hour at Christmas" even when it cannot answer "what is your p95 target". Turn that into a proposed model and thresholds, write it down, and get someone to disagree with it in writing. A documented assumption that turns out wrong is a much better position than no requirement at all.

What they are really asking: Extremely common in practice, and they are testing initiative. "I would wait for the requirements" is a losing answer.

Questions to ask before a performance test