4 exercises — responding to things you don't know yet, handling technical pushback with data, clarifying misunderstandings diplomatically, and redirecting out-of-scope questions.
0 / 9 completed
1 / 9
A stakeholder asks: "How long will the API redesign take?" You don't have enough information to give a reliable estimate yet. Which response is most professional?
Option C uses the structured "I'll follow up" response:
1. Acknowledge: "Great question" — signals the question is important, not inconvenient 2. Name the specific missing information: "number of affected endpoints" and "backward compatibility" — not vague "more details needed" 3. Commit to a specific follow-up date: "by Monday" — makes the promise accountable 4. Frame as a range: "a range" — hedges appropriately without overpromising precision
Why A fails: Technically honest, but it closes the conversation and signals you haven't thought about the question
Why B fails: "Probably a few weeks" is a guess. If it takes three months, everyone remembers "a few weeks"
Why D fails: "Impossible to say" is pessimistic framing that reduces confidence in the team
Core principle: Never guess in public. Saying "I'll find out and get back to you by [date]" is more credible than a wrong number delivered helpfully.
2 / 9
After your technical presentation, a senior engineer pushes back: "That approach won't scale past 1,000 concurrent users." How do you respond?
Option B uses the validate → data → invite structure for handling pushback:
1. Validate the concern: "That's a fair concern" — don't dismiss a senior engineer's flag in front of an audience 2. Present your evidence: "Our load tests showed [X] concurrent users at [Y] latency" — data-first response 3. Invite specifics: "I'd like to understand where you see the bottleneck" — turns a confrontation into a technical collaboration
Why A fails: "You're wrong" starts a public argument. Even if you're right, you've lost the room
Why C fails: "Fine for current needs" concedes the scalability point and closes the conversation — it sounds defensive and short-sighted
Why D fails: "Let's discuss offline" is sometimes appropriate, but used immediately it can look like you're hiding something
Remember: Pushback is not an attack — it's signal that someone is engaged enough to challenge you. The best responses thank the engagement, add data, and invite dialogue.
3 / 9
During your talk, an audience member clearly misunderstood your point about eventual consistency. They say: "So you're saying our data will just be wrong sometimes?" Which is the best response?
Option C demonstrates diplomatic clarification:
1. Take responsibility for the misunderstanding: "I can see why it came across that way — let me rephrase" — never blame the audience for misunderstanding 2. Use concrete numbers: "milliseconds to seconds" — makes the abstract concrete 3. Use an analogy: "shared doc" — every technical audience member uses Google Docs; the analogy works 4. Verify comprehension: "Does that better match what you had in mind?" — closes the loop
Why A and B fail: Starting with "you misunderstood" or "that's not what I said" is confrontational and embarrasses the questioner in front of peers
Why D fails: "Technically, yes, but only temporarily" — a senior stakeholder in the room hears "yes, the data will be wrong." That's the exact misunderstanding you need to fix, and this answer deepens it
Clarification principle: If someone misunderstood, the communication was probably unclear. The presenter owns that.
4 / 9
At the end of your presentation, an audience member asks a long, detailed question that is clearly out of scope for this session. How do you handle it?
Option C redirects an out-of-scope question without dismissing it:
1. Validates the question's importance: "a really important area" — the person feels heard, not shut down 2. Names the topic they raised: shows you understood the question 3. Gives a respect-based reason to defer: "I don't want to give it a short answer it doesn't deserve" — this is not avoidance, it's care 4. Offers a concrete path forward: "30 minutes this week" or "a short group session" — the question doesn't die 5. Includes the broader group: "if others here are interested" — makes the follow-up feel collaborative, not a private conversation
Why A fails: "Outside scope, sorry" is technically correct but dismissive — it signals that their question doesn't matter
Why B fails: "We don't have time" is factually true but the worst framing — it makes the questioner feel they've taken too much space
Why D fails: "I'll answer all off-topic questions after" is a blanket promise you may not keep; it also groups this specific, apparently thoughtful question with generic off-topic noise
5 / 9
Sarah from the QA team sends you this Slack message: 'This new feature is *completely* broken! Users are getting 500 errors when trying to submit forms.' How should you respond initially?
Sarah's message highlights a critical issue. Responding with 'I'm on it!' without gathering more details is reactive and inefficient. Asking for specific information (error codes, URL, screenshots) allows you to diagnose the problem quickly and demonstrate that you are taking her concerns seriously. Option A is good *after* you have some data.
6 / 9
You're writing a PR description for a refactoring change to the user authentication module. Another developer comments: 'This looks great, but I'm not sure how this impacts our existing rate limiting strategy.' How do you best address this concern?
The reviewer has raised a valid point that needs addressing. Dismissing the concern or offering a vague acknowledgement doesn't show you're actively considering potential impacts. Option 3 is ideal because it invites further discussion and demonstrates your commitment to ensuring the change integrates correctly with existing systems. Option A is unprofessional; option D is misleading.
7 / 9
During a standup update, you state: 'I've implemented the new caching layer to improve API response times.' Your team lead asks: 'Can you quantify the performance improvement?' What's the most effective way to respond?
Providing concrete data – a measurable percentage improvement – demonstrates your technical rigor and provides valuable information to your team. While 'significantly reducing latency' is understandable, it lacks quantifiable evidence. Option A is insufficient; option D is too vague.
8 / 9
You're reviewing a pull request that introduces a new metric for tracking user engagement. The reviewer includes this comment: 'I'm concerned about the potential for data skewing due to sampling.' How should you respond?
The reviewer's concern about data skewing is crucial. Simply dismissing it or offering an unsubstantiated statement isn't helpful. Option 1 is dismissive and doesn't address the potential issue. Option 2 invites a collaborative discussion to find a solution – showing you value the reviewer's expertise and are willing to adapt your approach. Option 3 provides insufficient detail; option 4 is demonstrably false.
9 / 9
You're presenting a design proposal for a new microservice. A client asks: 'Will this integrate with our existing legacy system?' You realize the integration is technically complex and outside the scope of this current project. How do you handle this request professionally?
Providing false assurance or avoiding the question damages trust. Option 3 acknowledges the complexity while setting clear boundaries and offering to discuss it later – demonstrating professionalism and managing expectations effectively. Option A is dishonest; option B is passive; option D delegates without proper discussion.
What will I practice in "Handling Questions & Pushback — 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.