These performance testing interview questions cover what interviewers ask about the discipline itself, whatever tool the job uses: the types of test, the metrics and how they relate, workload modelling, finding bottlenecks, and four scenario questions where you reason from a symptom to a cause. Where an answer quotes measured results, they come from load tests we ran in October 2026.
Tool questions are a separate interview round. For JMeter, our JMeter interview questions and answers checks every answer against the 5.6.3 manual.
Key Takeaways
- Define each test type by the question it answers: load testing checks the expected peak, stress testing finds the breaking point, soak testing looks for slow degradation.
- Quote percentiles, not averages, and know why: in one of our runs the average was 1.50 ms while the median was 236 µs.
- Know Little’s Law (requests in flight = throughput × response time) and use it to check results and size tests.
- Say whether a tool uses a closed or an open workload model. It changes what response times mean once the server is overloaded.
- In scenario questions, check the script and the load generator before blaming the server.
Basic performance testing interview questions
Interviews open with definitions to see whether you use the terms precisely. A good answer is short, says what question each test answers, and does not treat load, stress and performance testing as the same thing. Expect five or six of these before the harder rounds start.
What is performance testing?
Performance testing measures how fast, stable and resource-efficient a system is under a given workload. It answers questions such as “how quickly does checkout respond with 500 users?” and “how many requests per second can this API take before errors start?”. It is non-functional testing: it assumes the feature works and checks how well it works under load.
What are the types of performance testing?
Each type answers a different question, and the load shape follows from the question:
| Type | Question it answers | Load shape |
|---|---|---|
| Load test | Does the system meet its targets at the expected peak? | Ramp up to expected peak, hold |
| Stress test | Where and how does it break? | Increase past the expected peak until failure |
| Spike test | Does it survive a sudden surge and recover? | Jump from normal to a high load at once |
| Soak (endurance) test | Does it degrade over hours? | Normal load held for a long time |
| Volume test | Does it cope with large data sets? | Normal load, very large database or files |
| Scalability test | Does adding resources add capacity? | Same test on 1, 2 and 4 instances |
A strong answer adds that a smoke test, a few users for a few minutes, comes before all of them to prove the script and environment work.
What is the difference between load testing and stress testing?
A load test checks behaviour at the load you expect, usually the busiest hour plus a margin, against agreed targets such as a 95th percentile under 800 ms. A stress test goes past that load on purpose to find the breaking point, see how the system fails, and check that it recovers. Our article on load testing vs stress testing compares them in more detail.
What is a performance baseline?
A baseline is a recorded set of results from a known version of the system under a fixed test: response time percentiles, throughput, error rate and resource use. Every later run of the same test is compared with it, so a regression shows up as a difference from the baseline instead of an argument about whether 420 ms is good.
Why run a smoke test before a full load test?
To prove the script, the test data and the environment work before spending an hour of load on them. One to five users for a few minutes catches broken logins, expired tokens, missing test data and firewall blocks. A full test that fails on a script error wastes the slot and can leave results that look like a capacity problem.
Performance metrics interview questions
Metric questions check whether you can read results correctly. Interviewers want precise definitions, the relationships between the numbers, and an explanation of why averages mislead. If you can turn a definition into a quick calculation, as Little’s Law allows, you stand out from candidates who only recite terms.
What is the difference between response time, latency and throughput?
Response time is the time from sending a request to receiving the full response. Latency usually means the time to the first byte of the response, though some tools use it for the full response time, so say which definition you mean. Throughput is completed work per unit of time, usually requests or transactions per second.
Why use percentiles instead of the average response time?
Because a few slow requests pull the average far from what most users see, and the slow tail is what users complain about. In one of our runs against a local endpoint, the average was 1.50 ms, the median 236 µs and the 99th percentile 30.81 ms. Neither of the first two numbers says one request in a hundred took 30 ms or more. Targets are written as percentiles for this reason: “95% of checkout requests under 800 ms”. Our article on why percentiles beat averages goes further.
What is Little’s Law, and how do you use it in performance testing?
Little’s Law says the average number of items in a system equals the arrival rate multiplied by the average time each spends there: L = λW. In a load test, the requests in flight equal throughput multiplied by response time.
It works as a sanity check on results. In our test against an endpoint with 4 workers, 16 connections produced 151.99 requests per second at an average of 104.64 ms: 151.99 × 0.10464 ≈ 16, so the numbers agree. If they do not, something is queuing outside the measurement, often on the load generator. The same law sizes a test: users = throughput × (response time + think time), which is the basis of calculating concurrent users from analytics.
What is the difference between think time and pacing?
Think time is the pause between steps inside one user journey, standing in for a person reading a page or filling in a form. Pacing is the time from the start of one iteration of the journey to the start of the next, used to hold each user to a fixed rate. Think time shapes the requests inside a journey; pacing controls how often the journey repeats.
Without either, each virtual user sends requests back to back, and 50 virtual users produce far more load than 50 real people.
What should you monitor on the servers during a load test?
Google’s SRE book names four golden signals for a service: latency, traffic, errors and saturation. Brendan Gregg’s USE method checks utilization, saturation and errors for each resource: CPU, memory, disk, network, and the pools that run out first in practice, such as database connections and worker threads. Collect these during the run, because they explain the response times.
Workload modelling and planning questions
Planning questions separate testers who run scripts from testers who design tests. The interviewer wants to hear where the numbers come from, how real traffic turns into virtual users, and which conditions the environment and data must meet before the results mean anything. Answers that start from production data score highest.
How do you gather performance requirements?
Start from production data and the business, not from round numbers. Pull the busiest hour from analytics or server logs, the most used journeys and their mix, and growth expected from campaigns or seasons. Then agree measurable targets with the product owner: a percentile response time per transaction, a throughput, a maximum error rate, and the resource limits.
What is the difference between an open and a closed workload model?
In a closed model, a fixed number of users each sends a new request only after the previous one completes, plus think time. In an open model, new requests arrive at a set rate whether or not earlier ones have finished. Schroeder, Wierman and Harchol-Balter showed in 2006 that the two behave very differently under load.
The difference matters most when the server is overloaded. A closed-model tool slows down with the server, so it under-reports how bad things get. Real visitors to a website keep arriving, which an open model reproduces. JMeter’s thread groups are closed, and its throughput timers only pace them, so they stay closed when the server slows down. Tools with arrival-rate executors, such as k6’s, approximate an open model.
How do you decide how many virtual users to run?
Work it out from the target throughput and the journey time. With a target of 20 journeys per second and a journey that takes 10 seconds including think time, Little’s Law gives 20 × 10 = 200 virtual users. Then confirm it: run the test and check that the measured throughput matches the target, because slower responses stretch the journey and lower the rate.
How do you prepare the test environment and test data?
The environment should match production in the parts that limit performance: instance sizes, database size and indexes, caches, configuration, and third-party calls, which you stub or rate-limit by agreement. Test data must be large and varied enough that users do not all hit the same cached row, with enough distinct accounts for every virtual user.
Analysis and bottleneck questions
Analysis questions test whether you can explain a result instead of reporting it. The pattern interviewers look for is method: confirm the measurement is valid, find where throughput stops scaling, then match the response-time curve against server metrics to name the resource that ran out first.
How do you find a performance bottleneck?
Increase load in steps and watch where throughput stops rising while response time starts to climb. At that point, check the server metrics from the same minutes: the resource at its limit, or with a queue forming, is the bottleneck. It is often not CPU but a pool: database connections, worker threads, or a downstream API’s rate limit.
Throughput stops rising while response time keeps climbing. What does that mean?
The system has reached its capacity, and extra load is only adding queueing time. We measured exactly this against an endpoint with 4 workers taking 25 ms each:
| Connections | Requests/sec | Average response time |
|---|---|---|
| 4 | 150.36 | 26.58 ms |
| 8 | 152.07 | 52.47 ms |
| 16 | 151.99 | 104.64 ms |
| 32 | 149.40 | 210.96 ms |
Past 4 connections, every doubling doubled the response time while throughput stayed near 150. The capacity was the 4 workers. More load would not find a higher ceiling, only longer queues.
What is coordinated omission?
Coordinated omission is a measurement error in closed-model load tools. When the server stalls, each virtual user waits for its pending response instead of sending new requests, so the stall produces a handful of slow samples instead of the thousands real users would have suffered. Percentiles then understate the stall.
Gil Tene described the problem and wrote wrk2 to avoid it by sending at a constant rate. Our wrk load testing tutorial shows wrk 4’s correction for it with real runs: a 1-second server freeze left only 10 slow requests among about 40,000, too few to move a 99th percentile on their own, yet the corrected 99th percentile rose from about 210 ms to 830 ms.
How do you know the load generator is not the bottleneck?
Monitor the load generator’s own CPU, memory and network during the test, and keep it well below its limits. Then check Little’s Law on the results: if throughput × (response time + think time) does not match the configured users or connections, requests are waiting somewhere. A generator that runs out of CPU reports slow responses the server never produced.
Scenario-based performance testing interview questions
Senior interviews tend to end with scenario problems: a symptom from a real test and the question of what you would check first. The four questions below have no single right answer. The interviewer is scoring the order in which you check things and whether you rule out the test before blaming the system.
The load test passed, but users still say the site is slow. What do you check?
First, whether the test measured what users experience. A protocol-level test times server responses and skips browser rendering, JavaScript and third-party scripts, so measure the front end with a browser-based tool. Then compare the test with reality: the journey mix, the data volumes, users’ regions, and whether caches in the test environment were warmer than in production.
Response times grow steadily during a four-hour soak test. What is happening?
Something accumulates. The usual causes are a memory leak and the garbage collection it drives, connections or file handles that are not released, a table or index that grows with each transaction, a cache without eviction, or logs filling a disk. Plot memory, open connections and table sizes over the same four hours, and the one that grows with the response time is the lead.
Errors appear only above 300 users. How do you investigate?
Read the first errors in time, not the most frequent ones. Then look for a limit sized near 300: a database connection pool, a web server worker or thread limit, an operating system file descriptor limit, a load balancer queue, or a third-party rate limit. Also rule out the test: 300 users sharing 250 test accounts produce login conflicts that look like server errors.
How would you plan a test for a sales peak such as Black Friday?
Start from last year’s peak hour and the growth forecast for this year to set the target, then add a margin. Model the journey mix from that day’s analytics, which differs from an ordinary day. Run a load test at the target, a stress test past it to find the headroom, and a spike test for the opening minutes. Agree pass criteria per transaction beforehand.
Which tool questions should you expect?
Expect questions on whichever tool the job ad names, usually JMeter, k6, Gatling, Locust or LoadRunner. Interviewers ask how the tool generates load, how it handles correlation and test data, how to run it from the command line and in CI, and how to read its report. Run one real test in that tool before the interview.
For JMeter, our JMeter interview guide covers thread groups, timers, correlation, CLI mode and distributed testing. For the others, read the tool’s own documentation on how its virtual users work, because that shows whether its model is closed or open.
Practising with a real test
The fastest preparation is to run a test and explain the results aloud: the throughput ceiling, the percentiles, and what the server metrics showed. Ramp a small system you can watch past its capacity, note where throughput stops rising, and name the resource that ran out first. Those are the answers interviewers probe.
LoadFocus runs cloud load tests from 25+ regions, built in the browser or uploaded as JMeter or k6 scripts, so you can practise a load, stress and spike test against your own staging site without setting up load generators. The LoadFocus glossary also covers scalability testing and how it differs from load testing.
Frequently Asked Questions
What are the most common performance testing interview questions?
The most common ones ask for the types of performance test and their differences, the meaning of response time, throughput and percentiles, how to work out the number of virtual users, how to find a bottleneck, and what to monitor on the servers. Senior roles add workload modelling, open and closed models, and scenario questions.
How should I prepare for a performance testing interview?
Run one complete test yourself: a smoke test, then a stress test that ramps past the system’s capacity. Record the throughput ceiling, the percentiles and the server metrics at that point, and practise explaining why the response time rose. Interviewers ask about problems you have solved, and a real test gives you one.
What is the difference between performance testing and load testing?
Performance testing is the umbrella term for testing speed, stability and resource use under a workload. Load testing is one type of it: checking behaviour at the expected peak load against agreed targets. Stress, spike, soak, volume and scalability tests are the other common types.
Which performance testing tools should I learn?
Learn one well, and know where the others fit. JMeter appears in many job ads and runs many protocols. k6 and Gatling script tests as code and suit CI pipelines. Locust uses Python. LoadRunner is a long-established commercial tool in large enterprises. Interviewers value knowing why a tool fits a job over a list of names.
Sources
- Little, J. D. C. (1961). “A Proof for the Queuing Formula: L = λW”. Operations Research 9(3), 383-387. doi.org/10.1287/opre.9.3.383, checked 31 October 2026.
- Schroeder, B., Wierman, A. and Harchol-Balter, M. (2006). “Open Versus Closed: A Cautionary Tale”. 3rd USENIX Symposium on Networked Systems Design and Implementation. usenix.org, checked 31 October 2026.
- Google, Site Reliability Engineering, chapter 6, “Monitoring Distributed Systems”: the four golden signals. sre.google, checked 31 October 2026.
- Brendan Gregg, “The USE Method”. brendangregg.com, checked 31 October 2026.
- Coordinated omission and constant-rate load: github.com/giltene/wrk2, README, October 2026.
- Test runs: wrk 4.2.0 against a local Node.js 23.11.1 test API, including an endpoint with a pool of 4 workers at 25 ms per request, 31 October 2026. The laptop was running other work, so timings show patterns, not benchmarks.
