A ticket says "Improve the dashboard performance." Before starting, you need clarification. Which message is best?
Effective clarification requests are numbered, specific, and solution-oriented. Option B asks exactly three questions, each scoped to a real decision point (which page, which metric, what target), and offers a fallback ("I'll scope it myself") so the conversation doesn't stall. Option A is correct in identifying vagueness but provides no structure — it puts all the work back on the requester. Options C and D are blunt or passive-aggressive, which damages collaboration.
2 / 25
Complete this clarification request: "Before I _____ (start) the migration, I _____ (want) to confirm the rollback strategy. _____ (be) there a documented procedure if the schema change _____ (fail) in production?"
Before I start uses present simple in the time clause (not "will start" — English uses present tense in before/when/after clauses for future events). I want is the direct, professional phrasing for a genuine need — "am wanting" (continuous) is unnatural for a cognitive/mental state. Is there — yes/no questions use inverted subject-verb. If the schema change fails — again, present simple in conditional clauses, not "would fail" (that belongs in the main clause). This is the classic "if + present simple, … would …" conditional structure.
3 / 25
You receive requirements that contradict each other. Which message handles this most professionally?
When requirements conflict, the professional response is to name the conflict precisely, cite the specific sections, and offer paths forward. Option B: names the sections (3.2 and 5.1), describes the conflict in concrete terms (24-hour cache vs. real-time accuracy), asks the decision question (which takes priority?), and signals that two implementation options are ready — so the reply can immediately unlock progress. Option A is technically correct but sounds confrontational and unhelpful. Option C sounds vague and puts the burden on others without doing analysis work. Option D is risky — silently choosing can waste significant effort.
4 / 25
Which clarification email subject line is best?
A subject line should tell the recipient what the email is about, what's being asked, and when it matters. Option B: references the specific topic (API Rate Limits), states the quantity of questions (2 — so they know the scope), and anchors the urgency to a real event (design review on Thursday). This lets the recipient prioritize accurately. Option A is too vague — the inbox reader learns nothing. Option C uses "URGENT" which is often filtered or ignored, and doesn't specify what is urgent. Option D is similarly vague and the "ASAP" is imprecise.
5 / 25
Choose the correct phrasing to check your own understanding: "Just _____ (want) to make sure I _____ (understand) correctly — when you say the feature should 'scale', you _____ (mean) it should handle 10× current traffic without re-architecture, _____ (correct)?"
Wanted to make sure — using past tense ("wanted") softens the check slightly, making it sound like a background concern rather than a challenge. This is a common politeness strategy in professional English. I understand (present simple) describes your current state of understanding. You mean (present simple) checks the meaning in the current context — not "you meant" (past), which would imply the conversation is already over. Correct? — this is a tag used at the end of a paraphrase to invite confirmation. "Is that correct?" also works (option C), but the question structure mid-sentence is slightly awkward after a comma.
6 / 25
Sarah: 'Okay, I'm going to implement the new authentication flow. Can you confirm that the API endpoint for user creation uses OAuth 2.0? Also, is there a rate limit on requests?'
Mark: 'Sure, let me check.' After a few minutes, he replies with:
'Okay, it's using OAuth 2.0 and the rate limit is 100 requests per minute.'
Which of the following responses from Sarah best continues the conversation professionally and efficiently?
The key here is maintaining a productive conversation. Option B is overly enthusiastic and doesn't probe for further detail. Option A misinterprets the situation – Mark *did* provide the information. Option C correctly asks for clarification on a specific aspect of the confirmation (client ID/secret), demonstrating active engagement. Option D assumes changes are likely without requesting updates, which isn't efficient.
7 / 25
David: 'Hey team, I'm working on refactoring the payment processing module. Could someone double-check that the new error handling logic correctly logs all exceptions to CloudWatch Logs with a severity level of 'Error' and includes relevant transaction IDs?'
This question focuses on a common code review scenario. David is requesting specific details about the error handling implementation. The key here is that he's not just asking for general confirmation; he's specifying precise requirements regarding logging format and severity levels. Option 1 correctly reflects this detailed request – focusing on CloudWatch Logs, error severity, and transaction IDs. The other options present either overly broad requests or incorrect details about what David actually needs to verify.
8 / 25
Reviewer: 'The PR introduces a new dependency, `lib_x`. Can you elaborate on the rationale for choosing this library over alternatives like `lib_y`? Specifically, what performance characteristics were prioritized?'
This question demonstrates requesting clarification by pinpointing specific aspects of the decision-making process. The correct response, 'seeking clarification,' acknowledges the need for more information about the rationale behind choosing `lib_x` and highlights the importance of understanding performance priorities. The other options represent misunderstanding the purpose of a clarification request – it's not simply stating insufficient detail or blindly accepting the answer, but actively probing for crucial context.
9 / 25
John: 'I'm seeing a lot of timeouts on the API calls to Service B. Can you confirm that the circuit breaker is correctly configured and actively preventing cascading failures?'
This scenario requires clarifying the state of a critical system component – the circuit breaker. The key here is to acknowledge that brief outages are sometimes *expected* during high load, aligning with operational realities. Options A and B present overly prescriptive or technically incorrect assumptions about circuit breaker behavior. Option D suggests immediately digging into logs without first confirming if the basic health check indicates a problem.
10 / 25
{code}
During a code review, Liam comments: "I'm not sure about this caching strategy. Can you explain how it handles potential data inconsistencies if the underlying database schema changes?"
Which of the following responses from Maya is the most professional and effectively seeks clarification?
The correct response (option 2) directly addresses Liam's concern by acknowledging understanding and requesting further detail. It's a polite way to continue the conversation without immediately dismissing the question or stating an assumption. Options A is simply insufficient, B shows disinterest, and C is too vague and doesn't focus on the key issue of data inconsistency mitigation—the core of Liam's query was about potential problems and solutions.
11 / 25
Sarah: 'Okay, I'm going to implement the new authentication flow. Can you confirm that the API endpoint for user creation uses OAuth 2.0? Also, is there a rate limit on requests?'
Mark: 'Sure, let me check.' After a few minutes, he replies with:
'Okay, it's using OAuth 2.0 and the rate limit is 100 requests per minute.'
Which of the following responses from Sarah best continues the conversation professionally and efficiently?
The key here is maintaining a productive conversation. Option B is overly enthusiastic and doesn't probe for further detail. Option A misinterprets the situation – Mark *did* provide the information. Option C correctly asks for clarification on a specific aspect of the confirmation (client ID/secret), demonstrating active engagement. Option D assumes changes are likely without requesting updates, which isn't efficient.
12 / 25
David: 'Hey team, I'm working on refactoring the payment processing module. Could someone double-check that the new error handling logic correctly logs all exceptions to CloudWatch Logs with a severity level of 'Error' and includes relevant transaction IDs?'
This question focuses on a common code review scenario. David is requesting specific details about the error handling implementation. The key here is that he's not just asking for general confirmation; he's specifying precise requirements regarding logging format and severity levels. Option 1 correctly reflects this detailed request – focusing on CloudWatch Logs, error severity, and transaction IDs. The other options present either overly broad requests or incorrect details about what David actually needs to verify.
13 / 25
Reviewer: 'The PR introduces a new dependency, `lib_x`. Can you elaborate on the rationale for choosing this library over alternatives like `lib_y`? Specifically, what performance characteristics were prioritized?'
This question demonstrates requesting clarification by pinpointing specific aspects of the decision-making process. The correct response, 'seeking clarification,' acknowledges the need for more information about the rationale behind choosing `lib_x` and highlights the importance of understanding performance priorities. The other options represent misunderstanding the purpose of a clarification request – it's not simply stating insufficient detail or blindly accepting the answer, but actively probing for crucial context.
14 / 25
John: 'I'm seeing a lot of timeouts on the API calls to Service B. Can you confirm that the circuit breaker is correctly configured and actively preventing cascading failures?'
This scenario requires clarifying the state of a critical system component – the circuit breaker. The key here is to acknowledge that brief outages are sometimes *expected* during high load, aligning with operational realities. Options A and B present overly prescriptive or technically incorrect assumptions about circuit breaker behavior. Option D suggests immediately digging into logs without first confirming if the basic health check indicates a problem.
15 / 25
{code}
During a code review, Liam comments: "I'm not sure about this caching strategy. Can you explain how it handles potential data inconsistencies if the underlying database schema changes?"
Which of the following responses from Maya is the most professional and effectively seeks clarification?
The correct response (option 2) directly addresses Liam's concern by acknowledging understanding and requesting further detail. It's a polite way to continue the conversation without immediately dismissing the question or stating an assumption. Options A is simply insufficient, B shows disinterest, and C is too vague and doesn't focus on the key issue of data inconsistency mitigation—the core of Liam's query was about potential problems and solutions.
16 / 25
Sarah: 'Okay, I'm going to implement the new authentication flow. Can you confirm that the API endpoint for user creation uses OAuth 2.0? Also, is there a rate limit on requests?'
Mark: 'Sure, let me check.' After a few minutes, he replies with:
'Okay, it's using OAuth 2.0 and the rate limit is 100 requests per minute.'
Which of the following responses from Sarah best continues the conversation professionally and efficiently?
The key here is maintaining a productive conversation. Option B is overly enthusiastic and doesn't probe for further detail. Option A misinterprets the situation – Mark *did* provide the information. Option C correctly asks for clarification on a specific aspect of the confirmation (client ID/secret), demonstrating active engagement. Option D assumes changes are likely without requesting updates, which isn't efficient.
17 / 25
David: 'Hey team, I'm working on refactoring the payment processing module. Could someone double-check that the new error handling logic correctly logs all exceptions to CloudWatch Logs with a severity level of 'Error' and includes relevant transaction IDs?'
This question focuses on a common code review scenario. David is requesting specific details about the error handling implementation. The key here is that he's not just asking for general confirmation; he's specifying precise requirements regarding logging format and severity levels. Option 1 correctly reflects this detailed request – focusing on CloudWatch Logs, error severity, and transaction IDs. The other options present either overly broad requests or incorrect details about what David actually needs to verify.
18 / 25
Reviewer: 'The PR introduces a new dependency, `lib_x`. Can you elaborate on the rationale for choosing this library over alternatives like `lib_y`? Specifically, what performance characteristics were prioritized?'
This question demonstrates requesting clarification by pinpointing specific aspects of the decision-making process. The correct response, 'seeking clarification,' acknowledges the need for more information about the rationale behind choosing `lib_x` and highlights the importance of understanding performance priorities. The other options represent misunderstanding the purpose of a clarification request – it's not simply stating insufficient detail or blindly accepting the answer, but actively probing for crucial context.
19 / 25
John: 'I'm seeing a lot of timeouts on the API calls to Service B. Can you confirm that the circuit breaker is correctly configured and actively preventing cascading failures?'
This scenario requires clarifying the state of a critical system component – the circuit breaker. The key here is to acknowledge that brief outages are sometimes *expected* during high load, aligning with operational realities. Options A and B present overly prescriptive or technically incorrect assumptions about circuit breaker behavior. Option D suggests immediately digging into logs without first confirming if the basic health check indicates a problem.
20 / 25
{code}
During a code review, Liam comments: "I'm not sure about this caching strategy. Can you explain how it handles potential data inconsistencies if the underlying database schema changes?"
Which of the following responses from Maya is the most professional and effectively seeks clarification?
The correct response (option 2) directly addresses Liam's concern by acknowledging understanding and requesting further detail. It's a polite way to continue the conversation without immediately dismissing the question or stating an assumption. Options A is simply insufficient, B shows disinterest, and C is too vague and doesn't focus on the key issue of data inconsistency mitigation—the core of Liam's query was about potential problems and solutions.
21 / 25
Sarah: 'Okay, I'm going to implement the new authentication flow. Can you confirm that the API endpoint for user creation uses OAuth 2.0? Also, is there a rate limit on requests?'
Mark: 'Sure, let me check.' After a few minutes, he replies with:
'Okay, it's using OAuth 2.0 and the rate limit is 100 requests per minute.'
Which of the following responses from Sarah best continues the conversation professionally and efficiently?
The key here is maintaining a productive conversation. Option B is overly enthusiastic and doesn't probe for further detail. Option A misinterprets the situation – Mark *did* provide the information. Option C correctly asks for clarification on a specific aspect of the confirmation (client ID/secret), demonstrating active engagement. Option D assumes changes are likely without requesting updates, which isn't efficient.
22 / 25
David: 'Hey team, I'm working on refactoring the payment processing module. Could someone double-check that the new error handling logic correctly logs all exceptions to CloudWatch Logs with a severity level of 'Error' and includes relevant transaction IDs?'
This question focuses on a common code review scenario. David is requesting specific details about the error handling implementation. The key here is that he's not just asking for general confirmation; he's specifying precise requirements regarding logging format and severity levels. Option 1 correctly reflects this detailed request – focusing on CloudWatch Logs, error severity, and transaction IDs. The other options present either overly broad requests or incorrect details about what David actually needs to verify.
23 / 25
Reviewer: 'The PR introduces a new dependency, `lib_x`. Can you elaborate on the rationale for choosing this library over alternatives like `lib_y`? Specifically, what performance characteristics were prioritized?'
This question demonstrates requesting clarification by pinpointing specific aspects of the decision-making process. The correct response, 'seeking clarification,' acknowledges the need for more information about the rationale behind choosing `lib_x` and highlights the importance of understanding performance priorities. The other options represent misunderstanding the purpose of a clarification request – it's not simply stating insufficient detail or blindly accepting the answer, but actively probing for crucial context.
24 / 25
John: 'I'm seeing a lot of timeouts on the API calls to Service B. Can you confirm that the circuit breaker is correctly configured and actively preventing cascading failures?'
This scenario requires clarifying the state of a critical system component – the circuit breaker. The key here is to acknowledge that brief outages are sometimes *expected* during high load, aligning with operational realities. Options A and B present overly prescriptive or technically incorrect assumptions about circuit breaker behavior. Option D suggests immediately digging into logs without first confirming if the basic health check indicates a problem.
25 / 25
{code}
During a code review, Liam comments: "I'm not sure about this caching strategy. Can you explain how it handles potential data inconsistencies if the underlying database schema changes?"
Which of the following responses from Maya is the most professional and effectively seeks clarification?
The correct response (option 2) directly addresses Liam's concern by acknowledging understanding and requesting further detail. It's a polite way to continue the conversation without immediately dismissing the question or stating an assumption. Options A is simply insufficient, B shows disinterest, and C is too vague and doesn't focus on the key issue of data inconsistency mitigation—the core of Liam's query was about potential problems and solutions.
What does the "Requesting Clarification — Writing Exercise" exercise cover?
Practice writing professional clarification requests: numbered questions, handling contradictions, and confirming understanding. 5 interactive exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Requesting Clarification — Writing Exercise"?
This exercise has 25 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Email & Writing exercises?
Browse the full Email & Writing hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.