New Relic Performance Engineer common mistakes
New Relic Performance Engineer · Understand the traps and how to avoid them.
When asked to diagnose slow transactions, the candidate jumps straight to the transaction trace and reads it top-down, accepting the first slow span as the root cause instead of comparing the transaction's total time against its own breakdown to find which segment dominates.
Candidates study the APM UI by clicking around and learn that traces show slow database calls, so they treat any slow span as the answer. They never practice the discipline of first asking whether the time is in the app, in an external service, or in queueing, so they anchor on a plausible-looking span.
What to do instead
Before opening any trace, state the total response time and its split into application, database, external service, and queue time. Only then drill into the segment with the largest share, and confirm with the trace. Practice by taking five sample transactions and writing the split first, then verifying.
The candidate confuses Apdex thresholds and the meaning of the T value, or reports an Apdex score without stating the threshold in use, then recommends changes that would not move the score.
Apdex is presented as a single number in dashboards, so candidates memorize '0.94 is good' without internalizing that T is the target response time and that satisfied, tolerating, and frustrated counts are defined relative to it. They also forget that Apdex is per-transaction, not per-application.
What to do instead
For each Apdex question, write the T value, the satisfied boundary (T), the tolerating boundary (4T), and the frustrated boundary above that. Recompute a small sample by hand. When recommending fixes, state which bucket the affected transactions fall into and how the change moves them.
When asked why a browser page is slow, the candidate blames the backend without checking the Browser (digital experience) data for front-end timing, or conversely attributes all slowness to the front end without correlating to backend transaction time.
Candidates learn APM and Browser as separate products and never practice the join between them. The exam often presents a symptom where the backend is fast but the page is slow due to resource loading, and candidates default to the domain they studied most.
What to do instead
Always decompose page load into backend time, network time, and front-end resource time before answering. Identify which component the symptom implicates, then name the specific Browser metric (for example time to first byte, DOM processing, or resource timing) that would confirm it.
The candidate treats Synthetic monitors and real user monitoring as interchangeable, or recommends a synthetic check to detect a problem that only real user data can reveal, such as a device-specific rendering issue.
Both live under digital experience, so candidates blur them. They do not practice articulating the tradeoff: synthetics give controlled, repeatable, location-based checks on a schedule; real user data reflects actual traffic, devices, and geographies but only where users exist.
What to do instead
For every monitoring recommendation, state the question being answered (availability from a location versus experience of actual users), then pick the tool. Memorize that synthetics catch availability and regression from known locations, while real user data catches long-tail device and network effects.
When asked how to reduce alert noise or route incidents, the candidate proposes a static threshold on a raw metric instead of using the platform's anomaly detection, baseline, or alert policy conditions appropriate to the signal.
Static thresholds are the simplest mental model and the first thing candidates learn. They do not practice mapping signal types (seasonal traffic, spiky latency, error-rate spikes) to the right condition type, so they over-alert or miss slow drifts.
What to do instead
Build a small decision table: for each signal, note whether a static threshold, a baseline/anomaly condition, or a gap in data is appropriate, and justify it by the signal's variance and seasonality. When answering, name the condition type and the reason it fits.
The candidate describes AI-assisted features as magic that 'finds the root cause' without stating what data the feature consumes, what it outputs, and where a human must verify the result.
Vendor messaging emphasizes automation, so candidates repeat marketing phrasing. They do not practice explaining the input signals, the confidence or ranking of outputs, and the failure modes when telemetry is incomplete or mislabeled.
What to do instead
For any intelligent feature, answer in three parts: what telemetry it ingests, what it produces (ranked suspects, correlated events, predicted thresholds), and how an engineer validates it against traces, logs, or deploys. Never claim it replaces diagnosis.
When diagnosing a host or container problem, the candidate looks only at CPU and memory and ignores the infrastructure entity model, such as which host runs which container, and how that maps to the application reporting the symptom.
Candidates memorize a short list of host metrics and stop there. They do not practice navigating from an application symptom down to the hosting entity, so they miss the layer where the fault actually lives, such as disk saturation or a noisy neighbor.
What to do instead
Practice the top-down path: application symptom, then the entity (host, container, or cloud service) it depends on, then that entity's resource metrics. Always check at least one saturation metric beyond CPU and memory, such as disk I/O or network, and state the entity relationship explicitly.
The candidate treats log data as a separate silo and, when asked to correlate an error spike with a deployment or infrastructure change, searches logs alone without joining to APM events or change events.
Log management is studied as query syntax and parsing rules, so candidates focus on writing queries rather than on cross-signal correlation. They forget that the platform stores deployments, infrastructure events, and application errors as queryable event types.
What to do instead
For correlation questions, name the event types you would query (application errors, deployment or change events, infrastructure samples) and the join key (entity, time window, or trace ID). Practice writing one query that filters logs by trace ID and one that overlays deployments on an error-rate chart.
The candidate answers data-retention or data-ingestion questions with a single blanket number, ignoring that retention and sampling differ by data type and account tier, and that some data is aggregated rather than stored raw.
Candidates memorize one retention figure and apply it everywhere. They do not distinguish event data, metric data, and log data, nor do they account for how aggregation and sampling change what can be queried later.
What to do instead
Build a table with one row per data type and columns for retention, granularity, and whether raw events are queryable. When answering, state the data type first, then the retention and query implications, and flag any figure you are not certain of rather than guessing.
The candidate proposes a fix without stating how it will be verified in the platform, such as which chart, alert, or query would show improvement, and over what time window.
Exam questions often ask for a recommendation, and candidates treat the answer as a diagnosis-only exercise. They do not practice closing the loop, so their answers lack the measurable acceptance criteria that distinguish a performance engineer from a troubleshooter.
What to do instead
End every remediation answer with a verification statement: the specific metric or query, the expected direction of change, the baseline window, and the alert that should stop firing. Practice by writing one sentence of verification for each diagnosis you make.