5 exercises — the same information can be correct or disastrously wrong depending on how formally you say it. Practise recognising the right level of formality for announcements, incidents, client email, and team communication.
Register levels in IT communication
Casual / team Slack — informal, fast, emoji OK, first names, contractions
Professional / formal Slack — clear, structured, minimal jargon, no filler
Incident communication — factual, templated, no emotion, precise
Client-facing email — formal, no internal jargon, confident, polite, proactive
0 / 15 completed
1 / 15
You need to announce a planned deployment to the entire engineering org. Which message is appropriate for a formal announcement Slack channel (#engineering-announcements)?
Formal announcement channels require precise, actionable information: what is being deployed, when (with timezone), the expected impact, and a contact point for questions. Option A ("thingy", "Should be fine 🤞") is too casual and shows low confidence. Options C and D are too vague — they omit the timezone and use casual language ("auth stuff", "Quick thing"). Option B hits the right register: concise, professional, gives all essential details. The structure of a good deployment announcement: [What] + [When with timezone] + [Impact] + [Contact]. Even in casual-culture organisations, announcements that affect other engineers deserve clarity — developers in different timezones rely on this information.
2 / 15
A SEV-1 production incident is happening: payments are failing for all users. Which message is correct for the incident Slack channel (#incidents)?
Incident communication has a specific format. In high-stress situations, emotions and vague language cause wasted time. The standard incident channel format includes: (1) Severity level (SEV-1), (2) What is broken (service name + symptom), (3) Impact (who is affected, to what extent), (4) Status (investigating / mitigating / resolved), and (5) Incident commander or owner. Option A is emotional and creates noise. Option B implies blame and offers speculation. Option D uses "I think" — dangerous when you should state facts and unknowns separately. Option C is factual, structured, and immediately useful. Many teams use an incident template: "SEV-[N] | [What is broken] | [Impact] | [IC: @person] | [Bridge: link]".
3 / 15
A non-technical client emails asking for a project status update. Which reply is the most professionally appropriate?
Client-facing communication requires confidence, precision, and professional language. "Hacking on it", "stuff", "TODOs", and "push to prod" are all internal jargon that a client might find confusing or concerning — "hacking" especially has a negative security connotation. Option D ("I think?", "if nothing breaks") signals low confidence and shifts the risk to the client. Option C uses clear structure: completed work → current status → estimated completion. Note it avoids internal jargon ("API" is acceptable with a technical client; for a non-technical client, say "the server-side logic"). Writing to clients: always translate tech language into business language. "The backend API is complete" → "The data layer is built and tested." "Deploying to production" → "Making the feature live."
4 / 15
You want to ask a colleague to review your pull request. Which message is most appropriate for a professional team chat?
The ideal review request gives the reviewer everything they need to prioritise and prepare: a link or ID, what the PR does, and why it matters. Option A is too casual ("Yo", "kinda urgent") and wastes the reader's time with informal padding. Option B lacks context — "urgent" without explanation creates friction. Option D ("immediately", "This is required") is too demanding and may come across as aggressive. Option C is the sweet spot: polite ("Could you"), contextual (what it does), and motivating (why it matters — sprint goal). A well-written PR request also reduces back-and-forth: the reviewer knows what to focus on before they open the code. Add a direct link when possible: "Could you review [PR #847](link)?"
5 / 15
You need to write an email to a client apologising for a delayed feature delivery. Which opening sentence strikes the right tone?
Apologising to a client professionally requires: (1) a clear, direct apology, (2) a brief, factual explanation — not excuses, and (3) a forward-looking statement. Option A ("stuff came up") is too vague and casual — it sounds like you didn't take the deadline seriously. Option C ("my bad") is too informal for a client email. Option D is over-apologising — it signals panic and damages confidence more than it helps. Option B is ideal: it acknowledges the delay directly, offers a factual (not emotional) explanation, and uses professional phrasing. The next sentence should give a new date and any mitigation steps: "We expect delivery by [date]. We have [specific action] to ensure this timeline is met." Avoid blaming tools, third parties, or the client's requirements in the explanation.
6 / 15
Liam (Senior Backend Engineer) is explaining a complex database query to Sarah (Junior Frontend Developer) via Slack. Which response is most appropriate for Liam to use?
Liam needs to adjust his register significantly. Using technical jargon like 'index optimization' and latency metrics is overwhelming for Sarah, who lacks that background knowledge. The best approach is to provide a concise explanation of the query's purpose and key aspects without getting bogged down in overly complex details. Option 1 is dismissive and unhelpful; options 2 & 3 are still too technical; option 4 avoids explaining altogether.
7 / 15
You're writing the description for a pull request that introduces a new API endpoint for user authentication. Which of the following descriptions best balances technical detail with clarity?
The correct response provides sufficient detail for reviewers to understand the scope of the change. It includes the key technologies (OAuth 2.0), specific features (token validation and rate limiting), and the endpoint URL. Option 2 is far too verbose and could overwhelm a reviewer. Options 3 & 4 are overly simplistic and lack essential technical information.
8 / 15
During a daily standup meeting, David (Software Engineer) says: 'I'm working on the integration with the third-party payment gateway. It's proving quite tricky because of their API.' Which response is most appropriate for the team lead to offer?
The team lead needs to acknowledge David's difficulty and offer assistance. Simply telling him to 'keep pushing out changes' is unhelpful. Asking about the specific challenges demonstrates empathy and provides an opportunity for collaboration. Option 3 is overly enthusiastic and doesn't address the problem; option 4 is too vague.
9 / 15
You receive this email from a client: 'Just checking in on how things are going with the new reporting module. Any updates?' Which response demonstrates the most professional and informative tone?
The best response provides a brief overview of the current status without dwelling on problems. Using phrases like 'making good progress' and 'currently focused on' demonstrates professionalism and confidence. Option 2 is overly negative; option 3 is too vague; option 4 avoids providing any information.
10 / 15
You need to draft a short message on the #devops channel to inform the team about an upcoming planned outage of the staging environment. Which of the following messages is most appropriate?
This message clearly states the purpose of the outage (maintenance), provides specific timeframes, and uses professional language suitable for a technical operations channel. Option 2 adds unnecessary formality; options 3 & 4 are too informal.
11 / 15
Liam (Senior Backend Engineer) is explaining a complex database query to Sarah (Junior Frontend Developer) via Slack. Which response is most appropriate for Liam to use?
Liam needs to adjust his register significantly. Using technical jargon like 'index optimization' and latency metrics is overwhelming for Sarah, who lacks that background knowledge. The best approach is to provide a concise explanation of the query's purpose and key aspects without getting bogged down in overly complex details. Option 1 is dismissive and unhelpful; options 2 & 3 are still too technical; option 4 avoids explaining altogether.
12 / 15
You're writing the description for a pull request that introduces a new API endpoint for user authentication. Which of the following descriptions best balances technical detail with clarity?
The correct response provides sufficient detail for reviewers to understand the scope of the change. It includes the key technologies (OAuth 2.0), specific features (token validation and rate limiting), and the endpoint URL. Option 2 is far too verbose and could overwhelm a reviewer. Options 3 & 4 are overly simplistic and lack essential technical information.
13 / 15
During a daily standup meeting, David (Software Engineer) says: 'I'm working on the integration with the third-party payment gateway. It's proving quite tricky because of their API.' Which response is most appropriate for the team lead to offer?
The team lead needs to acknowledge David's difficulty and offer assistance. Simply telling him to 'keep pushing out changes' is unhelpful. Asking about the specific challenges demonstrates empathy and provides an opportunity for collaboration. Option 3 is overly enthusiastic and doesn't address the problem; option 4 is too vague.
14 / 15
You receive this email from a client: 'Just checking in on how things are going with the new reporting module. Any updates?' Which response demonstrates the most professional and informative tone?
The best response provides a brief overview of the current status without dwelling on problems. Using phrases like 'making good progress' and 'currently focused on' demonstrates professionalism and confidence. Option 2 is overly negative; option 3 is too vague; option 4 avoids providing any information.
15 / 15
You need to draft a short message on the #devops channel to inform the team about an upcoming planned outage of the staging environment. Which of the following messages is most appropriate?
This message clearly states the purpose of the outage (maintenance), provides specific timeframes, and uses professional language suitable for a technical operations channel. Option 2 adds unnecessary formality; options 3 & 4 are too informal.
What will I practise in "Choosing the Right Register — IT Communication Exercises"?How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
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.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the idiom's meaning and the tone it carries — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Idioms & Expressions exercises?
Browse the full Idioms & Expressions hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain idioms and their context in prose; this exercise tests and reinforces that recognition through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.