Practise writing technical content in plain language: active voice, short sentences, clear vocabulary, and avoiding unnecessary jargon.
0 / 10 completed
1 / 10
Which sentence best demonstrates plain language writing?
Plain language: short sentences, active voice (Use), direct vocabulary (get data). Avoid nominalisation, passive voice, and unnecessary words.
2 / 10
Active voice in technical writing means:
Active voice makes writing clearer and more direct. Technical documentation predominantly uses active voice for instructions and descriptions.
3 / 10
Which instruction is clearest for a technical user?
Second person (you), active voice (must log in), and direct language (before you can continue) make instructions immediately actionable.
4 / 10
Nominalisation in technical writing refers to:
Excessive nominalisation: 'The implementation of the feature' (heavy) vs. 'Implement the feature' (direct). Good technical writing prefers verb forms where possible.
5 / 10
When defining a technical term for the first time in a document, best practice is to:
The standard convention: spell out on first use with the abbreviation in parentheses, then use the abbreviation consistently. This serves both readers who know and don't know the term.
6 / 10
Alex: 'The API endpoint returns a 403 Forbidden error due to insufficient permissions.'
Which of the following revisions best exemplifies plain language in this code review comment?
This original sentence uses overly formal and technical phrasing like 'authorization error' and 'insufficient privileges,' which can be confusing for someone less familiar with these terms. Option A is much more direct and easily understood by a broader audience – it avoids jargon and clearly states the problem. Options C and D are also too verbose, while option B is still quite complex.
7 / 10
Sarah sends this Slack message to her team: 'Implementing the lambda function will necessitate a synchronous call to the database service.'
Which phrasing is more appropriate for a quick update in Slack?
Sarah's original message uses complex vocabulary ('necessitate,' 'synchronous') that isn't helpful in a fast-paced communication channel like Slack. Option A provides a concise and understandable summary of the change. The other options are overly technical and don't convey the core information clearly.
8 / 10
API Response:
```json
{
"status": "error",
"code": 400,
"message": "Invalid request parameters: 'userId' is required."
}
```
Which of the following descriptions would be clearest for a junior developer unfamiliar with the API?
While technically accurate, the original response uses phrases like 'validation failure' and 'exception was thrown,' which can be confusing. Option A clearly states the core problem: the 'userId' parameter is required. This simplified explanation allows the developer to immediately understand what needs to be fixed in their code.
9 / 10
PR Description:
'This PR refactors the data access layer utilizing a more robust and scalable design pattern incorporating a dependency injection framework for enhanced testability.'
Which revision of this description is clearer and more effective?
The original description is overly detailed and uses jargon that might not be immediately understood. Option A provides a high-level explanation of the changes in terms that are more accessible to a wider audience. It focuses on the *benefit* (easier testing) rather than technical details.
10 / 10
Standup Update: 'We've implemented the new caching mechanism utilizing Redis to optimize query performance.'
Which of the following is a better way for David to communicate this information during the daily stand-up?
David's original statement is overly technical and focuses on the implementation details. Option B is more concise and clearly explains the purpose of the change – using Redis to cache data for faster query performance. This aligns with the typical focus of a stand-up update: what was accomplished and why it matters.
This exercise, "Plain Language in Technical Writing", tests your understanding of technical writing vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Technical Writing exercise for?
It's designed for IT professionals and learners who want to sound natural discussing technical writing topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Technical Writing exercises?
Browse the full Technical Writing exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.