40 Performance Testing Interview Questions (With Answers)

How This List Was Compiled

These questions come from 300+ mock interviews conducted over 2 years, across companies from Series A startups to FAANG. Each question is weighted by frequency and ability to differentiate candidates.

The format: question → what they're really asking → strong answer.

---

Foundation Questions (Junior Level)

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

What they're really asking: Do you understand the spectrum of performance testing goals, or do you just run load tests?

Strong answer:

• Load testing: Validate system behavior under expected peak load. Goal: verify SLAs hold.
• Stress testing: Find the breaking point by increasing load past expected levels. Goal: understand failure modes.
• Spike testing: Apply sudden large load increases. Goal: test elasticity and recovery behavior.
• Soak/endurance testing: Sustained load over hours/days. Goal: catch memory leaks and resource exhaustion.

A weak answer only mentions "load testing" and describes it vaguely. A strong answer gives specific examples of when you'd run each type.

2. What metrics do you capture in a load test?

Strong answer (minimum):

• Response time: P50, P90, P95, P99 (not just average — averages lie)
• Throughput: requests/second, transactions/second
• Error rate: 4xx and 5xx separately
• Saturation: CPU, memory, disk I/O, network

Strong answer (differentiating): Also mention: connection pool utilization, GC pause time (for JVM), database connection count, queue depth, thread pool saturation.

3. What is Little's Law?

Strong answer: L = λ × W where L = number of items in system, λ = arrival rate, W = average time in system.

Applied to performance testing: if your API handles 100 RPS and each request takes 50ms, you need 5 concurrent "slots" (threads, connections, etc.) to handle the load without queuing.

---

Bottleneck Analysis (Middle Level)

4. Walk me through how you diagnose a database bottleneck.

Strong answer structure:

Start with symptoms (slow queries in APM, high DB latency in dashboards)

Check pg_stat_activity for long-running queries, lock waits

Run EXPLAIN ANALYZE on slow queries

Check table sizes and index usage (pg_stat_user_tables)

Look at system resources: disk I/O, CPU on DB host

Formulate hypothesis, test fix in staging

What separates seniors: Mentioning that "slow DB" often isn't the database — it's the application holding connections too long, N+1 queries, or missing connection pooling.

5. A service is responding slowly but CPU is at 30% and there are no errors. What's wrong?

This is a thread/connection starvation question.

Strong answer: Low CPU with high latency usually means threads are waiting, not working. Check:

• Thread pool utilization (are all threads active but blocking on I/O?)
• Connection pool (connections exhausted?)
• External service calls (is a downstream dependency slow?)
• Lock contention (database or application-level locks?)

The answer "add more CPU" is wrong. The system is CPU-idle because threads are blocked, not computing.

6. Describe the N+1 query problem and how to detect it in a load test.

Strong answer: N+1 occurs when code fetches 1 parent record then N child records with separate queries: 1 query for orders, then 1 query per order for items = N+1 queries.

Detection in load tests: monitor query count per request in APM (DataDog, New Relic). At 100 RPS, N+1 with N=10 generates 1000 queries/sec instead of 100. Total DB load scales with record count, not request count.

Fix: JPA/Hibernate FETCH JOIN, or explicit batch loading.

---

Tool Knowledge (Middle Level)

7. How do you choose between JMeter, k6, and Gatling?

Strong answer:

• JMeter: GUI-based, XML scripts, vast plugin ecosystem, resource-heavy. Choose when: team prefers GUI, need complex protocols (JDBC, JMS), existing JMeter investment.
• k6: JavaScript scripts, modern CI/CD friendly, good cloud integration (k6 Cloud). Choose when: developers will write tests, need Git-friendly scripts, running in Kubernetes.
• Gatling: Scala/Java DSL, excellent HTML reports, high performance (Akka-based). Choose when: team is Java/Scala developers, need very detailed reports, testing for long durations.

Weak answer: "They all do load testing, I've used JMeter."

Strong differentiator: "I chose k6 for our microservices because tests live in the same repo as the code and run in CI on every PR."

---

System Design for Performance (Senior Level)

8. How would you load test a payment processing API without charging real cards?

This tests understanding of test data isolation.

Strong answer:

• Use payment gateway sandbox environments (Stripe test mode, PayPal sandbox)
• Mock the external payment gateway in some tests to isolate your API from 3rd party latency
• Use test card numbers that don't trigger real charges
• Isolate test traffic to a staging environment with a shadow production database
• Never load test against production payment systems

9. Your load test shows P99 = 2 seconds, but users are complaining about slowness not reflected in this metric. Why?

Strong answer: Several possibilities:

The load test doesn't represent real user traffic (patterns, data distribution)

P99 is the wrong metric — P99.9 might be much higher

The load test uses test data that hits cache; real users hit uncached paths

Geographic/CDN differences not captured in the test

Specific user flows (checkout, search) are slow while simple GETs are fast — need scenario-based breakdown

---

Behavioral Questions

10. Tell me about a time you found a performance issue that wasn't visible in dashboards.

What they're really asking: Can you go beyond obvious metrics? Do you dig into root causes?

Structure your answer with:

• The context (service, load pattern)
• What dashboards showed (and what they didn't show)
• How you discovered the real issue (thread dumps, heap analysis, slow query logs)
• The root cause and fix
• What monitoring you added afterward

---

[Questions 11-40 cover: SLA/SLO design, capacity planning, chaos engineering, cloud cost vs. performance trade-offs, distributed tracing, and "teach me something about performance testing I might not know."]

Practice the Real Thing

Reading about performance issues is one thing. Diagnosing them under time pressure is another.

Start with these interactive cases — same format as a real incident:

→ [DB-005: Connection Pool Exhaustion](/cases/database/postgresql/db-005-connection-pool) (Middle, 25 min)

→ [APP-012: JVM Memory Leak](/cases/application/jvm/app-012-memory-leak) (Senior, 35 min)

→ [INF-003: Nginx Load Balancer](/cases/infrastructure/nginx/inf-003-lb-config) (Junior, 20 min)