Practise writing async standup updates: yesterday/today/blockers, being specific, flagging help needed, and linking context.
0 / 10 completed
1 / 10
A classic async standup format covers what you did, what you'll do, and your ___.
The yesterday/today/blockers structure surfaces progress and obstacles so teammates can unblock you without a meeting.
2 / 10
Which update is specific enough to be useful?
Concrete updates tell the team exactly where the work stands, which is the whole point of an async standup.
3 / 10
A good way to surface a dependency is to write ___.
Explicitly naming the blocker and who can resolve it lets the right person act, even across time zones.
4 / 10
Linking the relevant ticket or PR in your update provides ___.
Links give readers one-click context so they can dig in without asking you, which is essential in async work.
5 / 10
Async standups are valuable largely because they avoid the cost of ___.
Written updates let distributed teammates stay aligned on their own schedule, removing the need to all be online at once.
6 / 10
During a Slack thread discussing the performance of the customer-service API, Sarah replies: 'I've added some caching to reduce latency. It seems like the initial requests are still slow.' What is the most appropriate way for Mark to respond, acknowledging Sarah's work and offering further assistance?
Option 1 is best because it acknowledges Sarah's effort and immediately highlights a key metric (response times) that needs further investigation. Options A & B are too terse; option C dismisses her work without providing constructive feedback, and option D introduces an unrelated potential issue.
7 / 10
You're writing the description for a Pull Request introducing a new feature: user profile image uploads. The PR contains several hundred lines of code and addresses multiple related issues. What's the most effective way to frame your PR description to ensure reviewers understand the scope and impact?
Option 1 is too vague and doesn't provide context. Option 2 clearly outlines the scope of work, mentions related issues (linking back to tracking), and highlights key aspects like error handling and validation – all crucial for reviewers. Options A & D are insufficient; option B simply states what was done without explaining *why*.
8 / 10
During your daily standup, you need to update the team on your progress. You've finished implementing a new authentication flow and are now working on integrating it with the existing reporting dashboard. What's the most concise and effective way to communicate this to the team?
Option 1 provides only partial information. Option 2 clearly states what you completed and what you're currently working on, providing context for the team. Options A & C are vague and unhelpful; option B focuses on problems rather than progress.
9 / 10
As a senior developer, you're reviewing a code change proposed by David. He's added a new API endpoint to handle user data requests. The response from the API is in JSON format: `{"status": "success", "data": {"user_id": 1234, "name": "John Doe"}}`. What's the most effective way for David to ensure you understand the data structure and potential issues within this response?
Option 3 is crucial because it provides you with the *actual* data structure – the JSON response itself. This allows you to immediately verify the data's correctness and identify potential problems before delving deeper into the code. Options A, B & D are too abstract; they don't give you the concrete information needed for a review.
10 / 10
During your standup update, you mention that you've resolved a bug impacting user login functionality. You also state that you'll be investigating an issue with the background data synchronization process. What is the primary benefit of explicitly stating both these items during your standup?
Option 2 is correct because it highlights the core purpose of async standups – maintaining visibility into ongoing tasks and their associated dependencies. By clearly outlining both issues you're addressing, the team can understand how they relate to each other and potential impacts on the overall project timeline.
This is a Remote & Async exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of remote & async 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 10 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 remote & async 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 Remote & Async exercises?
See the Remote & Async 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 — remote & async vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.