Performance Engineer Resume
Skills & ATS Keywords

Aim for 32 to 46 specific load tools, profilers, APM names, and runtime-tuning patterns, grouped into 7 to 9 short rows. Below 24 reads like you have only watched a load test from across the room; past 50 starts to look like a category list rather than a track record. Each entry should be defensible inside a bullet that names a percentile, a baseline, and the workload it ran under. The skills row is the promise; the latency win is the receipt.

Drop it straight under the Profile Summary, above Work Experience. Hiring managers scan the file in one pass and several parsers (Workday, Greenhouse, Ashby) weight a tool name harder when it sits inside a labeled block near the top. Push it onto page two and your profiler-and-load-tool signal softens. Hold the line at 7 to 9 grouped rows so a staff engineer reading you can pick up the perf stack in three seconds.

Pull the JD into a scratch file and mark every load tool, profiler, APM product, percentile target, and runtime named. Underline anything that repeats. Cross-check the underlined names against your skills rows and your bullets. If a recurring tool is in the posting but not in your file, add it (only if you can defend it under a tech-screen) to the right row and surface it inside a bullet that already carries the work. Run the result through an ATS Checker to confirm the parser is still pulling the structured fields you expect.

A Performance Engineer resume reads as characterization work: load profiles authored in k6 or JMeter, p99 latency wins under named workloads, profiling sessions on async-profiler or pprof with before-and-after flame graphs, capacity-planning models that name headroom and Little's Law assumptions, and perf-budget gates wired into CI. An SRE resume reads as reliability ownership: SLO targets defended, error budgets enforced, pager rotations chaired, postmortems written, runbook automation shipped. Performance Engineers produce the latency and headroom numbers that SREs then defend with SLOs. If your bullets are mostly about p99 under stress, JVM-tuning campaigns, and 3x peak rehearsals, you are a Performance Engineer. If they are mostly about on-call hygiene, burn-rate alerts, and game-day chaos drills, you are an SRE. Pitching across both bands shrinks the load-and-profile authorship signal a perf hiring manager is screening for.

Lead with the side that matches the posting and back it up with one credible bullet from the other. Most 2026 PE roles split into a server-heavy track (API gateways, JVM and Go services, database query plans, capacity headroom) or a client-heavy track (Core Web Vitals, RUM, bundle size, CDN tuning, INP). At Senior+ levels hiring panels expect you can talk about both because end-to-end p99 is half-server, half-network-and-browser. A clean shape: one specialty named in two or three bullets, the other shown in one or two supporting bullets, the connective tissue between them surfaced in the Profile Summary.

Every credible perf win needs three coordinates. Pick the percentile that matters for the surface: p50 for steady-state read paths, p95 for typical user impact, p99 for tail latency and bot fanout. Pin the baseline: the prior reading, the window it was sampled over, and the workload mix (peak-traffic mirror, 70 percent reads plus 30 writes, a Black-Friday rehearsal). Name the load: concurrent users or RPS, the duration of the soak, and whether the test ran against staging-parity infrastructure or against a scaled-down clone. A bullet that says cut checkout p99 from 1,840ms to 420ms at 24k concurrent users on a 30-minute soak against a staging-parity cluster lands in the panel; cut latency 75 percent does not.

Five numbers tend to carry the weight on a perf-engineering resume. Latency percentiles paired with the surface (p99 on the checkout API under N RPS, p95 on the search service under M RPS). Throughput and saturation (RPS sustained at steady-state, the breaking-point RPS where the service falls over). Cost-per-RPS or cost-per-request shifts (right-sized instances, eliminated head-of-line waste, cut compute spend per unit of traffic). Headroom percentage held against forecast traffic (steady-state utilization moved from 35 percent to 62 percent, peak coverage held at 3x). And, when the org runs SLOs, the error-budget impact you handed off to SRE (perf wins that bought back N percent of monthly budget). Round metrics with no workload, no percentile, and no surface read as filler in 2026; a tight bullet ties one or two of these to the specific service, the load you ran, and the runtime or query change that drove the move.