6 exercises — decide when to write the full form vs. the abbreviation in RFCs, Slack messages, conference slides, user-facing articles, blog posts, and postmortems.
0 / 23 completed
1 / 23
You are writing the introduction to a technical RFC (Request for Comments) document. The document will be read by engineers across multiple teams, some of whom may not be specialists in your area. Which is the best approach for introducing the abbreviation "CRDT" on first use?
Option B — parenthetical introduction on first use, then abbreviation throughout — this is the standard technical writing convention: write "Full Form (ABBR)" on the first occurrence of an abbreviation and use the abbreviation thereafter. Option A creates friction for any reader who doesn't know the abbreviation. Option C adds significant length and repetition that makes documents harder to read. Option D (glossary only) is acceptable as a supplementary tool but does not replace the first-occurrence introduction, and forces readers to cross-reference throughout. The parenthetical-first-then-abbreviate pattern is used in IEEE standards, academic papers, and most internal engineering documentation style guides.
2 / 23
You are writing an internal Slack message to your team: "Just deployed the fix — the TTL on the Redis cache was set to 0 which caused the OOM condition in prod." Should you expand TTL, OOM, or Redis?
Option C — do not expand when the audience clearly knows the abbreviations — The key principle is audience awareness. TTL (Time to Live), OOM (Out of Memory), and Redis are standard vocabulary for backend engineers. Expanding them in a quick Slack message to your own team would sound overly formal and slow down communication. The "expand on first use" rule applies to documents with mixed or unknown audiences (RFCs, public docs, onboarding materials, blog posts). For team-internal async text like Slack, Jira comments, or PR descriptions, you calibrate to the reader's knowledge level. Expanding widely-known abbreviations in team chat is often perceived as condescending.
3 / 23
You are preparing slides for a conference talk. Your audience is "software developers" — a broad category. The slide uses "ACID" to describe database transaction properties. Should you expand ACID on the first slide it appears?
Option B — expand on first slide appearance — Conference audiences are broader than your immediate team. "Software developers" includes frontend engineers, mobile developers, product engineers, and more recent graduates who may not have worked with relational databases extensively. ACID is well-known to backend and database engineers but not universal across all developer roles. For presentations, the convention is to expand the abbreviation on its first visual appearance (either in the slide text or speaker notes read aloud). This takes one extra line and ensures no one is confused, without slowing veteran listeners — they simply confirm what they already know.
4 / 23
You are writing a user-facing help article for a SaaS product. The article explains that "two-factor authentication has been enabled on your account." The abbreviation "2FA" appears in the UI. Should you expand it in the article?
Option B — expand with parenthetical, confirming the UI abbreviation — User-facing documentation serves non-technical users as well as tech-savvy ones. Writing "two-factor authentication (2FA)" on first use: (1) ensures the reader understands the concept even if they don't know "2FA", (2) connects the long form to the short form so they recognise "2FA" in the product UI, and (3) follows plain language guidelines for consumer documentation (UK Government Digital Service, US Plain Language Act, Apple Human Interface Guidelines all recommend expand-first for abbreviations). Option C (never abbreviate) makes the text longer; Option D (only abbreviate) leaves non-familiar users behind.
5 / 23
You are writing inline CMS content for a developer blog post titled "How we reduced p99 latency by 40%." The post uses the abbreviation "p99" frequently. What is the best approach?
Option A — expand on first use even for a developer audience on a public blog — Even technical blog posts on developer sites reach a wide range of readers: students, developers from different domains, non-native English speakers, and people outside the observability/SRE specialisation who are learning. "p99" is well-known in infrastructure engineering but not universal. Expanding it once as "99th percentile (p99)" costs one sentence and enables all readers to follow the argument. Subsequent occurrences of "p99" are then clear. Option C is common but represents a decision to exclude some of your potential audience. Option D removes a useful shorthand that makes comparisons concise ("p50", "p95", "p99", "p999" are easier to compare than the full forms).
6 / 23
Which of the following is the most appropriate way to introduce "MTTR" in a postmortem document to be shared across engineering, product, and customer success teams?
Option A — "mean time to recover (MTTR)" — this is the cleanest standard form: full form first, abbreviation in parentheses, continuation of the sentence. The cross-functional audience (engineering + product + customer success) means MTTR cannot be assumed. Option B is backwards — introducing the abbreviation before the definition breaks the reading flow (readers see "MTTR" before knowing what it means). Option C is redundant — "mean time to recover (mean time to recover, or MTTR)" restates the full form twice. Option D uses the abbreviation with no introduction, which leaves non-engineering readers without context. Postmortem documents are often shared with leadership, so clear terminology matters for trust and comprehension.
7 / 23
Reviewer: 'The API response is returning a 500 error. Can you investigate the root cause? Seems like there's an issue with the gRPC implementation.'
As the developer responsible for this API, how should you respond to this comment to ensure clarity and avoid further confusion?
The correct response is to expand 'gRPC' as 'Google Remote Procedure Call' and briefly explain its purpose. While acknowledging the error is important, the reviewer likely doesn't immediately understand what gRPC is, which could delay troubleshooting. Providing a clear definition avoids assumptions and ensures everyone is on the same page regarding the underlying technology. Option A is technically correct but doesn't address the immediate need for clarification; option D puts the onus on the reviewer without proactively resolving the knowledge gap.
8 / 23
You're drafting a pull request description for a change to the user authentication service. The PR introduces a new feature: "Single Sign-On (SSO)". This term might not be familiar to all reviewers – including some in QA and Operations. Which of the following is the MOST effective way to introduce 'SSO' within the PR description itself?
Option 1 is best because it provides a clear and concise definition of SSO alongside its benefits. The other options either oversimplify the concept or focus solely on technical implementation details without explaining *why* SSO is being used or its impact. Introducing the term with context is crucial for ensuring everyone understands the change's purpose, especially those outside the core development team.
9 / 23
You are reviewing a code change that implements a new caching layer for an API endpoint. The developer has used the abbreviation 'LRU' to describe the caching algorithm. Which of the following is the MOST appropriate response in your code review comment?
While acknowledging 'LRU' is acceptable, it's crucial to ensure everyone understands. Asking for a brief explanation forces the developer to clarify the meaning of the abbreviation and promotes better communication within the team. Ignoring or simply accepting it could lead to misunderstandings later on.
10 / 23
Reviewer: 'The API response is returning a 500 error. Can you investigate the root cause? Seems like there's an issue with the gRPC implementation.'
As the developer responsible for this API, how should you respond to this comment to ensure clarity and avoid further confusion?
The correct response is to expand 'gRPC' as 'Google Remote Procedure Call' and briefly explain its purpose. While acknowledging the error is important, the reviewer likely doesn't immediately understand what gRPC is, which could delay troubleshooting. Providing a clear definition avoids assumptions and ensures everyone is on the same page regarding the underlying technology. Option A is technically correct but doesn't address the immediate need for clarification; option D puts the onus on the reviewer without proactively resolving the knowledge gap.
11 / 23
You're drafting a pull request description for a change to the user authentication service. The PR introduces a new feature: "Single Sign-On (SSO)". This term might not be familiar to all reviewers – including some in QA and Operations. Which of the following is the MOST effective way to introduce 'SSO' within the PR description itself?
Option 1 is best because it provides a clear and concise definition of SSO alongside its benefits. The other options either oversimplify the concept or focus solely on technical implementation details without explaining *why* SSO is being used or its impact. Introducing the term with context is crucial for ensuring everyone understands the change's purpose, especially those outside the core development team.
12 / 23
You are reviewing a code change that implements a new caching layer for an API endpoint. The developer has used the abbreviation 'LRU' to describe the caching algorithm. Which of the following is the MOST appropriate response in your code review comment?
While acknowledging 'LRU' is acceptable, it's crucial to ensure everyone understands. Asking for a brief explanation forces the developer to clarify the meaning of the abbreviation and promotes better communication within the team. Ignoring or simply accepting it could lead to misunderstandings later on.
13 / 23
Reviewer: 'The API response is returning a 500 error. Can you investigate the root cause? Seems like there's an issue with the gRPC implementation.'
As the developer responsible for this API, how should you respond to this comment to ensure clarity and avoid further confusion?
The correct response is to expand 'gRPC' as 'Google Remote Procedure Call' and briefly explain its purpose. While acknowledging the error is important, the reviewer likely doesn't immediately understand what gRPC is, which could delay troubleshooting. Providing a clear definition avoids assumptions and ensures everyone is on the same page regarding the underlying technology. Option A is technically correct but doesn't address the immediate need for clarification; option D puts the onus on the reviewer without proactively resolving the knowledge gap.
14 / 23
You're drafting a pull request description for a change to the user authentication service. The PR introduces a new feature: "Single Sign-On (SSO)". This term might not be familiar to all reviewers – including some in QA and Operations. Which of the following is the MOST effective way to introduce 'SSO' within the PR description itself?
Option 1 is best because it provides a clear and concise definition of SSO alongside its benefits. The other options either oversimplify the concept or focus solely on technical implementation details without explaining *why* SSO is being used or its impact. Introducing the term with context is crucial for ensuring everyone understands the change's purpose, especially those outside the core development team.
15 / 23
You are reviewing a code change that implements a new caching layer for an API endpoint. The developer has used the abbreviation 'LRU' to describe the caching algorithm. Which of the following is the MOST appropriate response in your code review comment?
While acknowledging 'LRU' is acceptable, it's crucial to ensure everyone understands. Asking for a brief explanation forces the developer to clarify the meaning of the abbreviation and promotes better communication within the team. Ignoring or simply accepting it could lead to misunderstandings later on.
16 / 23
Reviewer: 'The API response is returning a 500 error. Can you investigate the root cause? Seems like there's an issue with the gRPC implementation.'
As the developer responsible for this API, how should you respond to this comment to ensure clarity and avoid further confusion?
The correct response is to expand 'gRPC' as 'Google Remote Procedure Call' and briefly explain its purpose. While acknowledging the error is important, the reviewer likely doesn't immediately understand what gRPC is, which could delay troubleshooting. Providing a clear definition avoids assumptions and ensures everyone is on the same page regarding the underlying technology. Option A is technically correct but doesn't address the immediate need for clarification; option D puts the onus on the reviewer without proactively resolving the knowledge gap.
17 / 23
You're drafting a pull request description for a change to the user authentication service. The PR introduces a new feature: "Single Sign-On (SSO)". This term might not be familiar to all reviewers – including some in QA and Operations. Which of the following is the MOST effective way to introduce 'SSO' within the PR description itself?
Option 1 is best because it provides a clear and concise definition of SSO alongside its benefits. The other options either oversimplify the concept or focus solely on technical implementation details without explaining *why* SSO is being used or its impact. Introducing the term with context is crucial for ensuring everyone understands the change's purpose, especially those outside the core development team.
18 / 23
You are reviewing a code change that implements a new caching layer for an API endpoint. The developer has used the abbreviation 'LRU' to describe the caching algorithm. Which of the following is the MOST appropriate response in your code review comment?
While acknowledging 'LRU' is acceptable, it's crucial to ensure everyone understands. Asking for a brief explanation forces the developer to clarify the meaning of the abbreviation and promotes better communication within the team. Ignoring or simply accepting it could lead to misunderstandings later on.
19 / 23
Sarah, a senior engineer, comments on a code review: 'The service is experiencing high latency. Can you investigate the root cause? Seems like there's an issue with the gRPC implementation.' As the developer responsible for this service, what's the MOST effective way to respond in your commit message?
The question mirrors a real-world code review comment. Option A is too vague and doesn't provide enough detail for context. Option B is simply repeating the problem statement without offering a solution. Option D, while technically correct, lacks the crucial explanation of *why* the change was made - the core principle of good commit messages. Option C directly addresses the reviewer's concern and provides sufficient information.
20 / 23
During a daily standup meeting, David mentions: 'We're seeing frequent timeouts on our microservice A API. It looks like we need to implement Circuit Breaker patterns.' What's the best way to clarify this for your team?
This scenario focuses on communicating technical concepts during a team meeting. Option A is unprofessional and doesn't convey information effectively. Option B directly states the solution being considered, which is suitable for a standup context. Options D is a less specific alternative that doesn't fully explain the need for a circuit breaker.
21 / 23
You're writing a pull request description for a change to a database schema. The PR introduces a new index on the `user_id` column in the `orders` table. What's the most accurate way to explain this to your team?
This tests understanding of indexing. Option A is too general. While true, it doesn't explain *why* the index was added. Options C and D are overly vague descriptions. Option B clearly explains the purpose – to speed up queries that filter by `user_id`, which is a key benefit of an index.
22 / 23
You receive an API response with the following message: '503 Service Unavailable.' The system monitoring dashboard shows high CPU utilization on your application server. How should you describe this situation in a Slack message to your team?
This assesses concise communication in a Slack environment. Option A is alarmist and doesn't provide context. Option B accurately describes the problem and its likely cause. Options C and D are too generic or simply state the need for action without detail.
23 / 23
During a code review discussion, another developer suggests using 'CQRS' to separate concerns in your application. You're unsure if this is the right approach. How should you respond to solicit more information?
This tests your ability to respectfully seek clarification on a potentially unfamiliar term. Option A jumps to implementation without understanding. Option D shuts down discussion prematurely. Option C demonstrates not knowing something – which is perfectly acceptable if you ask for help. Option B prompts the other developer to explain CQRS and its relevance, fostering collaboration.
What will I practice in "When to Expand — IT Abbreviations Exercises"?
This is an IT Abbreviations exercise set. It walks through 23 scenario-based multiple-choice questions built around real usage of IT Abbreviations 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 23 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 IT Abbreviations 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 IT Abbreviations exercises?
See the IT Abbreviations 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 — IT Abbreviations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.