What is the difference between load testing, stress testing, and spike testing?

Load testing: measure performance under expected user volume (e.g., 1000 concurrent users). Stress testing: push beyond expected limits to find the breaking point (e.g., ramp to 10,000 users until errors appear). Spike testing: sudden burst of traffic (e.g., 0 to 5000 users in 10 seconds) to test auto-scaling and recovery. Each answers a different question: "Can we handle normal traffic?" vs. "When do we break?" vs. "Can we handle sudden surges?"

What key performance metrics should you monitor during a load test?

Response time (p50, p95, p99, not just average), throughput (requests per second), error rate (% of failed requests), concurrent users, and resource utilization (CPU, memory, disk I/O, network). p95 and p99 are more important than average - they show worst-case user experience. Also monitor: database query times, connection pool usage, queue depth, and garbage collection pauses.

Compare JMeter, k6, and Gatling. When would you use each?

JMeter: GUI-based, Java, huge plugin ecosystem, great for complex protocols (SOAP, JMS, JDBC), but resource-heavy per thread. k6: JavaScript-based, lightweight Go runtime, modern API, excellent for CI/CD integration and developer-written tests, but fewer protocols than JMeter. Gatling: Scala-based, code-first approach, excellent reports, efficient non-blocking architecture. Choose k6 for developer teams and CI integration, JMeter for complex enterprise protocols, Gatling for high-performance Scala shops.

How do you identify performance bottlenecks from load test results?

Systematic approach: (1) Correlate response time degradation with resource metrics, does CPU spike when response times increase? (2) Check database - slow queries (enable slow query log), connection pool exhaustion, lock contention. (3) Check application - thread pool saturation, memory leaks (heap growth over time), GC pauses. (4) Check infrastructure - network bandwidth, disk I/O, load balancer distribution. (5) Use APM tools (Datadog, New Relic) to trace individual slow requests through the stack.

How do you write a k6 load test script?

Basic structure: define `options` (stages for ramp-up/down, thresholds for pass/fail), export a `default function` with HTTP requests and checks. Example: `export const options = { stages: [{ duration: "2m", target: 100 }, { duration: "5m", target: 100 }, { duration: "2m", target: 0 }], thresholds: { http_req_duration: ["p(95)<500"] } }`. Use `check()` for assertions, `group()` for logical grouping, and `sleep()` for think time between requests.

What is think time and why is it important in load testing?

Think time simulates the pause between user actions, a real user reads a page for 5-30 seconds before clicking the next link. Without think time, your load test generates unrealistically high request rates (each virtual user fires requests back-to-back), making results inaccurate. Too much think time underestimates load. Use realistic think times based on analytics data. In k6: `sleep(Math.random() * 5 + 2)` for 2-7 second random pauses.

How do you test the performance of a database-heavy application?

Beyond HTTP load testing, directly test the database layer: (1) Query performance, EXPLAIN plans for critical queries, index coverage. (2) Connection pooling - test pool exhaustion under load. (3) Read/write ratio - mirror production patterns. (4) Data volume - test with production-scale data (not a tiny dev DB). (5) Lock contention - concurrent updates to the same rows. (6) Replication lag - test read-replica consistency under write-heavy load. Monitor: query time percentiles, connection wait time, deadlock frequency.

How do you set performance testing thresholds and SLAs?

Base thresholds on: (1) Business requirements, "checkout must complete in under 3 seconds." (2) Current baseline - measure existing performance, set thresholds to detect regressions (e.g., p95 must not exceed 1.2x baseline). (3) Industry standards - Google recommends Z rps. Fail the build in CI if thresholds are breached.

What is the difference between vertical and horizontal scaling? How do you test for each?

Vertical: more CPU/RAM on a single machine, simpler but has a ceiling. Horizontal: more machines behind a load balancer - scales further but adds complexity (session management, data consistency). Test vertical: increase load until resources max out, note the ceiling. Test horizontal: verify load balancer distributes evenly, test with N and N+1 instances, verify auto-scaling triggers at the right threshold, and test instance startup time under sudden load.

How do you perform capacity planning based on load test results?

Process: (1) Establish current capacity, what load does the system handle within SLA thresholds? (2) Model growth - if traffic is growing 20% quarterly, when will current capacity be exceeded? (3) Test scaling scenarios - does adding 2x instances give 2x capacity (linear scaling) or less (bottleneck elsewhere)? (4) Identify the constraint - DB, network, CPU, or specific service. (5) Build a capacity model: users × avg requests per session × peak multiplier = required throughput. Re-validate quarterly.

35Questions · All Levels

QUESTIONS / performance-testing

Performance & Load Testing interview questions.

Questions on JMeter, k6, Gatling, load testing strategy, performance metrics, bottleneck analysis, and capacity planning.

Practice Live with AI

Free to start · 7-day trial on paid plans

APPROACH / PERFORMANCE-TESTING.STRATEGY

How to approach performance questions.

Performance testing interviews are unusual because most candidates have read about percentiles and very few have actually been on the hook for a launch where p99 mattered. Interviewers can tell within two questions which group you are in. The fastest way to land in the second group is to talk about the test you actually ran, the metric you actually watched, and the threshold you actually breached.

Start with workload modelling, not tool choice. A senior interviewer will ask "how would you load test this?" and the wrong answer is "I would use k6 with 1000 virtual users." The right answer walks through traffic shape: peak versus average, burst versus sustained, read-heavy versus write-heavy, geographic distribution. Pick the workload that maps to the product, then justify your tool. JMeter for protocol-level scenarios on Java stacks, k6 for scriptable JavaScript-driven runs that fit modern CI, Gatling when you need precise timing in Scala-friendly environments.

Talk in percentiles, not averages. "Average response time was 250ms" is the answer that ends the conversation. "p50 was 120ms, p95 climbed past our 500ms SLO at 800 RPS, and p99 fell off a cliff at 1000 RPS where the connection pool saturated" is the answer that earns a follow-up. Have at least one war story where you correlated a percentile shift to a specific bottleneck (DB pool, GC pause, downstream timeout, CPU steal on a noisy neighbor).

Capacity planning is the senior question. Be ready to describe how you turn a load test into a sizing decision: how you extrapolate from a soak test to a six-month growth forecast, how you incorporate failure budgets, and where you draw the line between adding capacity and fixing the architecture. If you have ever pushed back on adding hardware because the slow path was an N+1 query, lead with that story.

What hiring managers are listening for

Workload modelling
You design the load shape from product traffic, not from tool defaults.
Percentile literacy
You read p50/p95/p99 separately and explain why each matters.
Bottleneck triage
You correlate metrics across application, database, and infrastructure layers.
Capacity instincts
You can translate a soak test into a sizing or scaling recommendation.

Common pitfall

Do not assume the interview is about tools. The question "how do you write a JMeter test?" is a setup. The follow-up is "and how do you know that test reflects production?" If you have not thought about think time, ramp profiles, and warm caches versus cold ones, the second question will catch you flat.

Practice by Tool & Technology

Dive deeper with tool-specific interview questions.

All Tool & Technology Questions Playwright Interview Questions Selenium Interview Questions Postman Interview Questions JMeter Interview Questions Jenkins Interview Questions

EXEC.NOW

Ready to Ace Your QA Interview?

Stop reading answers, start practicing them live with AI that knows QA.

Join 1,200+ QA engineers already practicing with AssertHired.

Start your free QA interview

FREE.TO.START · 7.DAY.TRIAL ON PAID PLANS

Written by Aston Cook, Senior QA EngineerLast updated: March 2026

Performance & Load Testing interview questions.

How to approach performance questions.

What hiring managers are listening for

More Question Categories

Practice by Tool & Technology

Ready to Ace Your QA Interview?