4 exercises — narrating charts, translating uptime to human time, presenting negative metrics with context, and using hedge language for uncertain data.
0 / 9 completed
1 / 9
You're presenting a bar chart showing that feature adoption increased from 12% to 34% after a UX redesign. Which narration is most effective?
Option C demonstrates data narration — turning a visual into a story:
1. Name what the chart shows: "feature adoption before and after the UX redesign" — the audience doesn't have to figure out the axes 2. Explain the baseline: "12% of active users" — gives the starting context 3. State the change with the multiplier: "34%" and "2.8× increase in 8 weeks" — percentages AND ratios because each audience member processes differently 4. Provide the causal explanation: "driven primarily by making the export button visible" — not just what changed, but WHY it changed
Why A and B fail: "Shows our data" and "the bar went up" force the audience to do the interpretive work you should have already done for them
Why D fails: "This is a good result" is a value judgment without explanation — what does "good" mean in the context of your target KPI?
Chart narration formula: "What this [chart type] shows is [topic]. The [reference element] represents [baseline with context]. After [change], that became [new value] — a [multiplier or %] [increase/decrease] over [timeframe], driven by [cause]."
2 / 9
You need to present 99.94% uptime to a non-technical VP. Which presentation is most effective?
Option C uses the percentage → human time → benchmark translation technique for non-technical executives:
1. Starts with the percentage: "99.94%" — the official metric your audience may know 2. Converts to human time: "5.3 hours across the full year" and "26 minutes per month" — a VP can understand "26 minutes a month" 3. Connects to the SLA target: "exceeded our target by 0.04pp" — shows you know the commitment and are tracking against it 4. Translates the delta into business terms: "3.5 fewer downtime hours per year than our contractual minimum" — now the VP can say "we're performing 3.5 hours/year better than we promised clients"
Why A fails: States the number without context — what does 99.94% mean at human scale?
Why B fails: "Very high" is a vague evaluation without a benchmark
Why D fails: "0.06% of the year" is even less intuitive than 99.94% — percentage of a percentage is the worst form for non-technical audiences
Your team's deployment frequency dropped from 14/week to 6/week last month due to a refactoring initiative. You need to present this to stakeholders. Which framing is most professional?
Option C uses the context → plan → future promise → tracking formula for presenting negative metrics:
1. States the change factually: "14 to 6 per week" — no hedging, no softening 2. Provides the causal context: "we front-loaded refactoring of test infrastructure" — explains WHY without deflecting 3. Gives a specific recovery timeline: "return to 14+ by end of April" and "20+/week by Q3" — stakeholders can hold you to a date 4. References the original plan: "tracking against our original project plan — currently on track" — shows this dip was anticipated, not a surprise
Why A fails: "Dropped significantly" without context invites questions you should have answered preemptively
Why B fails: "Not really our fault" is defensive and undermines trust — even if it's technically accurate
Why D fails: "Quality rather than quantity" is a vague justification that sounds like an excuse; it doesn't explain the metric drop or provide a recovery plan
Negative metric formula: [Exact change] → [Why it happened] → [When it recovers + to what level] → [Reference to plan to show it was expected]
4 / 9
You're presenting a chart showing a 15% improvement in p99 API latency. But you're not sure if the improvement is from your new caching layer or from a traffic pattern change. Which language handles the uncertainty most professionally?
Option D demonstrates professional uncertainty hedging — the language engineers use when data is promising but not yet causal:
1. States the observed fact: "15% improvement in p99 latency since caching deployment" — presents the measurement without overclaiming 2. States the hypothesis with appropriate confidence: "most likely contributing factor" — doesn't say "definitely" or "probably" 3. Names the confounding variable: "shift in traffic patterns during the same period" — shows analytical rigour, not weakness 4. States what you're doing about it: "controlled experiment in staging to separate the signals" — turns an uncertainty into a plan 5. Commits to a resolution date: "cleaner attribution by next week's review" — stakeholders aren't left with an open question
Why A fails: Claiming causality ("caching layer improved latency") without stated evidence — if you're wrong, credibility is lost
Why B fails: "We don't know why" without a follow-up plan sounds negligent
Why C fails: "Not confident in these numbers" is too broad — you can be confident in the measurement and uncertain about attribution simultaneously
Uncertainty hedging levels: • High confidence: "The data shows…" / "We can confirm…" • Medium confidence: "Based on [evidence], the most likely explanation is…" • Low confidence: "Preliminary data suggests… though this is early" • Unknown cause but known effect: "We observed X. We have a hypothesis and are testing it."
5 / 9
John, the Lead Backend Engineer, has just sent this Slack message during a code review: 'This function is slow. The average execution time is 2.3 seconds. Can you optimize it?' Which phrasing best communicates the urgency and problem to the reviewer?
Option 1 is correct because it acknowledges the severity of the performance issue (2.3 seconds) and immediately suggests action. Options A & D are too vague; option B is technically accurate but lacks a sense of urgency that's crucial in a code review context. Option C is misleading as it claims optimization has already occurred.
6 / 9
Sarah, a Data Analyst, needs to present the following API response to the product team: `{"status": "success", "data": {"page_views": 12345, "bounce_rate": 0.45}}`. Which sentence provides the most concise and actionable summary of this data?
Option 1 is correct because it clearly states the key metrics (page views and bounce rate) in a straightforward manner. Options A & D are overly verbose; option B provides raw numbers without context. While 'bounce_rate' is important, focusing on page views as the primary metric is more immediately useful for product decision-making.
7 / 9
David, a DevOps Engineer, is drafting a PR description for a deployment that reduced server latency by 18%. He wants to highlight this improvement. Which statement best balances technical detail with an understandable explanation?
Option 1 is correct because it provides a specific explanation of *how* the improvement was achieved (network routing & caching), demonstrating technical understanding. Options A & D are too vague; option B is overly complex for a PR description and doesn't clearly state the impact.
8 / 9
Maria, a Product Manager, is giving a standup update. 'Our daily active users increased by 7% last week.' Which follow-up question would be most effective to elicit further discussion and potential insights?
Option 0 is correct because it prompts Maria to investigate *why* the growth occurred by asking about the driving cohort—essential for understanding user behavior and potential opportunities. Options A & B are too broad; option C is dismissive and doesn't encourage deeper analysis.
9 / 9
Ben, a Senior Software Engineer, needs to present the following data during a performance review meeting: 'The average response time for our core API calls has decreased from 50ms to 25ms over the last quarter.' Which phrasing best communicates this improvement while acknowledging potential contributing factors?
Option 1 is correct because it provides context about the reduction (50ms) and suggests potential reasons for the improvement (code optimizations & server capacity). This demonstrates a balanced understanding of the situation. Options A & D are overly enthusiastic; option B is too technical for a general presentation.
What will I practice in "Presenting Data & Metrics — Presentations English Exercises"?
This is a Technical Presentations exercise set. It walks through 9 scenario-based multiple-choice questions built around real usage of technical presentations terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 9 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the technical presentations vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Technical Presentations exercises?
See the Technical Presentations exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — technical presentations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.