Learn vocabulary for writing step-by-step how-to guides: numbered steps, prerequisites, warnings, and verification steps.
0 / 10 completed
1 / 10
What is the recommended structure for a how-to guide?
How-to guide structure: Goal (what the reader will accomplish), Prerequisites (what they need before starting: access, installed tools, knowledge), Steps (numbered, one action per step, with expected output), Verification (how to confirm success), Troubleshooting (common errors and fixes). Scannable format: headers, numbered steps, code blocks.
2 / 10
What is 'prerequisite' language in a how-to guide?
Prerequisites save frustration: 'Before you begin: You need Admin access to the AWS console, AWS CLI v2 installed and configured, and the ARN of your S3 bucket.' Readers who don't meet prerequisites find out immediately — not after completing half the steps. Prerequisite clarity is a hallmark of professional technical documentation.
3 / 10
What does 'expected output' mean in a step-by-step guide?
Expected output after each step: 'You should see a message like: Successfully configured AWS profile. If you see an error, see Troubleshooting below.' Expected output lets readers self-check. It transforms a guide from a list of commands into a verifiable procedure — drastically reducing support requests.
4 / 10
What is the 'note / warning / danger' callout convention in technical writing?
Callout hierarchy: Note/Info (additional helpful context), Warning (could cause problems if ignored — e.g., 'This will overwrite existing files'), Danger/Caution (irreversible consequences — e.g., 'This permanently deletes the database'). Visually distinct (icons, colored boxes) so scanners cannot miss them. Critical for runbooks and operations guides.
5 / 10
What is 'audience targeting' in internal documentation writing?
Audience targeting: 'This guide is for backend engineers setting up their local development environment for the first time. Assumes basic familiarity with the terminal but no prior knowledge of our stack.' This tells readers if the guide is for them and tells writers what to explain vs. what to assume. Without it, guides are written for an imaginary average reader who may not exist.
6 / 10
Alex from the Support team sent this Slack message to the #devs channel: 'To update your API key, follow these steps…'. Which of the following best describes the purpose of this message in a how-to guide?
This message aims for brevity and assumes a basic understanding of APIs. A true how-to guide would provide exhaustive steps. The other options represent misinterpretations – it's not a support request or a discussion starter, nor does it delve into security vulnerabilities (though those might be addressed later). The core goal is to quickly direct users to the necessary actions.
7 / 10
You're writing a PR description for a new feature that uses a complex data transformation library. Which phrase best encapsulates the need for detailed instructions in the guide?
While the other options describe aspects of the code, they don't address the *how*. A how-to guide needs to explain *how* developers should use the transformation library. The correct option highlights the importance of clear instructions for successful implementation and integration – reproducibility is key in a technical environment.
8 / 10
Ben left this comment on a code review: 'I'm not sure how to handle the error case where the database connection fails. The guide should include steps for gracefully handling this scenario.' What is Ben primarily suggesting regarding the structure of the how-to guide?
Ben's comment points to a crucial element often overlooked: anticipating errors. A good how-to guide doesn't just describe *what* works; it must detail what happens when things go wrong and how to handle those situations. The other options represent incorrect priorities – exhaustive detail isn't always necessary, and performance shouldn't overshadow error handling.
9 / 10
You are drafting a 'Note / Warning / Danger' callout for a guide on deploying a new microservice. The message reads: 'Deploying this service requires downtime and could impact dependent services.' What is the *primary* purpose of this callout?
The 'Note / Warning / Danger' callout is reserved for critical information – in this case, the potential impact of the deployment. It's not about technical specs or timelines; it's about alerting users to possible problems and encouraging them to proceed with caution. The other options represent less urgent concerns.
10 / 10
A senior developer asks you: 'When writing documentation for our internal API, should I target the junior developers or the experienced architects?' What is the MOST appropriate response?
Effective documentation caters to varying levels of expertise. While junior developers need foundational explanations, experienced architects benefit from deeper dives into technical aspects. A balanced approach ensures that all users can effectively utilize the API, regardless of their background – providing tiered content is key.
What will I practise in "How-To Guide Writing — Vocabulary and Structure"?
Learn vocabulary for writing step-by-step how-to guides: numbered steps, prerequisites, warnings, and verification steps.
How many exercises are in this module?
This module has 10 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 vocabulary and reasoning behind it — 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 Knowledge Base Writing exercises?
Browse the full Knowledge Base Writing 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 vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary 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.