5 exercises — Practise communicating performance findings: presenting results, diagnosing metrics, translating for stakeholders, and articulating trade-offs.
0 / 10 completed
1 / 10
You have completed a performance optimisation and need to present results to your team. Which opening sentence is most effective?
Performance results must be specific, measured, and contextual.
A strong performance result statement includes:
• Metric name: p99 latency (not just "speed")
• Before and after values: 1,240 ms → 187 ms
• Magnitude of improvement: 85% reduction
• Scope: specific endpoint (/checkout)
• Test conditions: under 500 concurrent users
Why "p99" matters:
• Average (mean) hides outliers — a fast average can mask terrible tail latency
• p99 (99th percentile) = "99% of requests completed in X ms or less"
• p95, p99, p99.9 are standard metrics in SRE and performance engineering
Key vocabulary:
• p99 latency — the 99th percentile response time; 1% of requests take longer
• baseline — the "before" measurement used for comparison
• concurrent users — users making requests simultaneously during a load test
• percentage reduction — (old - new) / old × 100; the standard way to express improvement
2 / 10
A stakeholder asks: "The new feature is live, but our monitoring shows a 40% increase in CPU usage. Should we be worried?"
Which response demonstrates the best performance engineering communication?
Performance diagnosis always starts with correlation analysis before drawing conclusions.
The right framework for evaluating a metric increase: 1. Is the increase proportional to traffic?
• CPU up 40% + traffic up 40% = linear scaling = expected
• CPU up 40% + traffic flat = efficiency regression = investigate
• CPU up 40% + traffic up 10% = super-linear growth = potential issue
2. Are other metrics affected?
• CPU spike + error rate up → likely a real problem
• CPU spike + latency unchanged + errors unchanged → may be acceptable
3. Is the absolute value concerning?
• 40% of what baseline? 40% of 10% → 14% total; 40% of 70% → approaching saturation
• "Headroom" — how close are we to capacity limits?
Key vocabulary:
• correlation — the relationship between two metrics (does metric A move with metric B?)
• proportional scaling — CPU/memory growing linearly with load (expected behaviour)
• super-linear growth — resource usage growing faster than the load driving it (a warning sign)
• headroom — the remaining capacity before a resource becomes a bottleneck
3 / 10
After a load test, you are presenting findings to leadership. Which way of communicating the results is most effective for a non-technical audience?
Non-technical stakeholders need business context, not technical metrics. Translate performance findings into user experience and business impact.
Translation formula for leadership presentations:
• p99 latency 2,340ms → "checkout takes 2.3 seconds" (user experience)
• "10× traffic spike" → "Black Friday scenario" (business context)
• "connection pool saturation" → "we need to scale the database layer" (actionable)
• Technical root cause → "to fix this, we need X" (investment request)
The STAR format for performance findings:
• Situation: current state and test scenario
• Target: the performance goal (e.g., "under 1 second for 95% of users")
• Assessment: did we meet the target? Where did we fail?
• Recommendation: what investment is needed to meet the target?
Key vocabulary for leadership communication:
• "user experience" — use this instead of "latency" when talking to non-technical stakeholders
• "under load" — simpler than "under concurrent traffic conditions"
• "scale" — acceptable technical term that non-technical audiences understand
• "target" or "SLA" — clearer than "SLO" for non-engineering audiences
4 / 10
During a performance review, a colleague asks: "Why is the memory usage trending upward over 72 hours but the CPU is flat?"
Which explanation is most accurate?
Trending resource usage over time (while the application is otherwise stable) is the classic signature of a resource leak.
Memory leak diagnostic pattern:
• CPU flat → the application isn't doing more work
• Memory growing → memory isn't being released after use
• This combination = strong signal of a memory leak or unbounded cache
Common causes in web applications:
• Event listeners added but never removed when a component is destroyed
• Closures holding references to large objects that can't be garbage collected
• Caches without eviction — storing items forever without a max-size policy (e.g., LRU eviction)
• Database connections opened but not returned to the pool
• WebSocket/stream objects not cleaned up on disconnect
How to investigate:
• Take heap dumps at T+0 and T+72h; compare retained objects
• Look for objects that are growing in count
• Use memory profiler (Java: JProfiler; Node: --inspect + Chrome DevTools; Python: memory_profiler)
Key vocabulary:
• memory leak — a bug where memory is allocated but never freed, causing gradual consumption
• heap — the region of memory where dynamically allocated objects live
• garbage collection (GC) — the automatic process of reclaiming memory from objects no longer in use
• eviction policy — the rule that determines when cached items are removed (e.g., LRU, TTL)
5 / 10
You are writing a performance optimisation proposal. Which sentence best describes the trade-off between a proposed caching layer?
Effective performance proposals quantify both the benefit AND the trade-offs — this is how engineers build credibility with technical and non-technical reviewers.
The anatomy of a strong performance trade-off statement:
• What: Redis cache in front of the database
• Benefit (quantified): read latency 45ms → 2ms
• Scope: frequently accessed product data (hot path)
• Cost (technical): eventual consistency, 60s TTL
• Cost (financial): ~$180/month for the Redis instance
• Conclusion: the trade-off is justified for hot-path reads
Why acknowledging trade-offs is important:
• Caching introduces cache invalidation complexity
• TTL creates a window where users see stale data
• Cache misses (cold start, TTL expiry) result in "thundering herd" problems if not handled
• Memory cost and operational overhead of another service
Language patterns for trade-off discussions:
• "at the cost of…" — introduces the downside
• "the trade-off is justified because…" — signals that you've weighed both sides
• "for the hot path / for read-heavy workloads" — scoping the benefit to where it applies
Key vocabulary:
• eventual consistency — a model where reads may return stale data for a short window after a write
• TTL (Time-to-Live) — how long a cached item is considered valid before being discarded
• hot path — the most frequently executed code path or most-accessed data
• thundering herd — a situation where many cache misses simultaneously overwhelm the backend
6 / 10
Alex: 'The latency on the API endpoint has increased significantly. We need to investigate immediately!' Which of the following responses best communicates Alex's concern to the team while focusing on actionable steps?
Option 2 is the most effective because it combines acknowledging the issue with a request for information (data) and setting a clear expectation for a follow-up. Options A and D are too vague, while option B doesn't actively drive investigation; effectively, it's just agreement. This demonstrates proactive communication crucial in performance discussions.
7 / 10
Sarah (a Senior Engineer) is drafting a Slack message to the team about a recent database query optimization. Which of the following messages best balances technical detail with clarity for a wider audience?
Option 3 provides specific details about the optimization (index improvements) and quantifies the impact (30% reduction). This demonstrates technical understanding without overwhelming non-technical colleagues. Options A is too terse, B lacks context, and C is misleading – it doesn't explain *why* the query was slow.
8 / 10
Ben, during a standup update, states: 'We refactored the user authentication flow.' Which phrasing would be most helpful to his team for understanding the potential performance implications?
Option 3 is crucial because it explains *how* the change impacts performance – specifically mentioning reduced server load and improved response times. The other options are too vague and don't convey any relevant information about potential performance effects. This demonstrates an understanding of how code changes can influence system behavior.
9 / 10
You've received the following API response from a monitoring service: `{"status":"error", "code":429,"message":"Too Many Requests".` Which of the following is the MOST effective way to communicate this issue to your team, acknowledging the potential performance bottleneck?
Option 3 goes beyond simply stating the error; it identifies the *cause* (high volume of requests), proposes a possible solution (rate limiting/capacity), and suggests further investigation. This demonstrates analytical thinking and proactive problem-solving – key skills in performance engineering.
10 / 10
David is writing a PR description for a caching layer implementation. Which sentence best captures the core trade-off being made?
Option 3 explicitly states the trade-off: reduced database load (positive) versus increased memory usage (negative). This demonstrates a clear understanding of the resource constraints involved in performance optimization. Options A and B are too simplistic, while C is vague – it's important to highlight *both* sides of the equation.
What will I practise in "Performance Review Discussion Language"?
This module focuses on Performance Profiling — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Performance Profiling exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around performance profiling — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Performance Profiling exercises?
See the Performance Profiling hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.