JPJobPrepfull-stack interview
RoadmapsJS CompilerStar on GitHub

Career roadmap

Performance Test Engineer

Find the breaking point before your users do, and turn the result into a specific engineering fix.

Time
4-7 months part-time
Entry bar
Testing, development or operations background.
Stages
5 · 25 topics
0/25 studied0%

Before you start Performance Testing

  • Understanding of HTTP and client/server architecture
  • Basic scripting ability
  • Comfort reading metrics and graphs

Performance fundamentals

3-5 weeks · 0/5 topics

Precise vocabulary. Most performance discussions fail on confused terminology.

  1. Throughput, latency, concurrency and utilisation, and how they relate.

    • Latency versus throughput
    • Concurrency, arrival rate and Little's Law
    • Utilisation and saturation
    • Percentiles and why averages mislead
  2. Load, stress, soak and spike tests answer different questions.

    • Load testing to expected volume
    • Stress testing to find the limit
    • Soak testing for leaks and degradation
    • Spike and scalability testing
  3. A test against an invented workload proves nothing.

    • Deriving requirements from business volumes
    • Realistic user journey mixes
    • Think time and pacing
    • Peak versus average modelling
  4. You cannot find the bottleneck without knowing the components.

    • Tiers, load balancers and caches
    • Connection pooling and thread models
    • Queues and asynchronous processing
    • Cloud autoscaling behaviour
  5. Distinguishing a real regression from run-to-run variance.

    • Percentiles and distribution shape
    • Variance between runs
    • Warm-up and steady state
    • Sample size and confidence

BuildWrite a performance test plan with explicit requirements, workload model and success criteria.

Building and running tests

4-6 weeks · 0/5 topics

Realistic, repeatable tests that produce results you can defend.

  1. k6, JMeter or Gatling. Code-based tools are increasingly preferred.

    • k6 scripting and scenarios
    • JMeter for enterprise contexts
    • Distributed load generation
    • Tool selection criteria
  2. Realistic scripts, with correlation and parameterisation done properly.

    • Correlation of dynamic values
    • Parameterisation and test data
    • Authentication and session handling
    • Assertions and error handling
  3. A test on hardware unlike production produces numbers unlike production.

    • Environment sizing and scaling factors
    • Data volume representativeness
    • Isolating from other traffic
    • Load generator capacity
  4. Small procedural mistakes invalidate an entire test cycle.

    • Ramp-up and steady state
    • Monitoring during the run
    • Recognising an invalid test
    • Repeatability and controls
  5. Server response time is only part of what the user experiences.

    • Core Web Vitals basics
    • Browser-based performance testing
    • Network condition simulation
    • Correlating client and server timing

BuildLoad test a real application to its breaking point and produce a report with the limiting resource identified.

Analysis and bottleneck hunting

4-6 weeks · 0/5 topics

The valuable half: turning a slow result into a specific, actionable cause.

  1. Response times tell you there is a problem; system metrics tell you where.

    • CPU, memory, disk and network saturation
    • JVM or runtime metrics
    • Database and connection pool metrics
    • Correlating layers on one timeline
  2. Going from 'the service is slow' to 'this method is slow'.

    • CPU profiling and flame graphs
    • Memory profiling and leak detection
    • Async and thread analysis
    • Profiling overhead considerations
  3. The most common root cause in application performance testing.

    • Slow query identification under load
    • Lock contention and deadlocks
    • Connection pool exhaustion
    • N+1 queries revealed by load
  4. Thread pools, locks and queues that serialise under pressure.

    • Thread pool sizing and starvation
    • Lock contention
    • Queue growth and backpressure
    • Timeout cascades
  5. The deliverable, and what interviewers ask to see.

    • Executive summary with the headline number
    • Evidence-backed root cause
    • Specific recommendations
    • Capacity conclusions

BuildDiagnose three different bottlenecks — database, thread pool and memory — with evidence for each.

Continuous performance

3-4 weeks · 0/5 topics

Testing once before release finds problems too late to fix cheaply.

  1. Short, targeted tests on every change rather than a big-bang cycle.

    • Smoke-level performance tests
    • Thresholds and pass/fail criteria
    • Managing variance in CI environments
    • Trend tracking across builds
  2. Component-level measurement, with all the ways it misleads.

    • Benchmark harnesses and warm-up
    • Avoiding dead code elimination
    • Statistical rigour in benchmarks
    • When microbenchmarks mislead
  3. Real users on real networks are the ultimate performance test.

    • Real user monitoring
    • APM and distributed tracing
    • Comparing test results to production
    • Capacity monitoring and alerts
  4. Turning test results into infrastructure and cost decisions.

    • Headroom targets
    • Growth forecasting
    • Autoscaling policy validation
    • Cost per transaction
  5. Systems behave differently when a dependency fails while under load.

    • Failure injection during load tests
    • Degradation behaviour
    • Recovery time after overload
    • Circuit breaker verification

BuildAdd automated performance tests to CI with thresholds that fail a regression.

Interview preparation

2-3 weeks · 0/5 topics

Interviews are scenario-driven: given these numbers, what is wrong.

  1. Precise definitions are tested, because imprecision causes bad tests.

    • Explain percentiles versus averages
    • Little's Law applied to a scenario
    • Load versus stress versus soak
    • Why the average response time is fine but users complain
  2. Given a graph, identify the bottleneck. The signature interview exercise.

    • Reading response time and throughput curves
    • Identifying saturation points
    • Distinguishing client from server limits
    • Recognising an invalid test
  3. Design a performance test programme for a described system.

    • Deriving a workload model
    • Environment and data strategy
    • Success criteria definition
    • Reporting plan
  4. Scripting questions on the tool the employer uses.

    • Writing a k6 or JMeter scenario
    • Correlation and parameterisation
    • Distributed execution setup
    • Results integration
  5. A well-written report is worth more than a certificate here.

    • A public performance report
    • Bottleneck case studies with evidence
    • CI performance gate implementation
    • Capacity model for a real system

BuildA public performance test report with methodology, findings and recommendations.

Performance Testing tools on your CV

  • k6
  • JMeter
  • Gatling
  • Grafana
  • Prometheus
  • APM tooling
  • Async Profiler

What Performance Testing employers ask to see

  • A published performance test report with root cause analysis
  • A CI performance gate that catches regressions
  • Three documented bottleneck investigations
  • A capacity model derived from test results

Concentrated where downtime is expensive: banking, telecoms, e-commerce and ticketing. A small specialism with consistently high day rates in consultancy.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.