4 exercises — write clear async status updates, blockers, handoffs, and standups for distributed teams.
0 / 9 completed
1 / 9
You need to write an async status update for your team. You've completed the authentication refactor and are now blocked on a backend API endpoint. Which update format communicates this best?
Option B uses BLUF structure (Bottom Line Up Front) and async communication best practices:
BLUF structure: 1. Completed work — specific, verifiable ("auth refactor done ✅") 2. Blocker with context — names what's blocking, who owns it, why it matters ("payment integration on hold") 3. Direct ask — specific person, specific request, specific deadline ("@backend: ETA by EOD today?") 4. Self-unblocking plan — "starting error-handling module" — shows no passive waiting
Why BLUF matters async: • In async communication, readers scan messages — most important info must be first • If they only read the first line, they should still understand the key status • Save context and explanation for after the headline
You're changing the scope of an upcoming feature because of a technical constraint. You need to communicate this asynchronously to the PM and two other engineers. Which update is most effective?
Option C is a professional async decision/scope change communication using the Decision Memo format:
Decision Memo structure: 1. Header — "SCOPE CHANGE" + identifier (version) — makes it scannable and searchable 2. What's changing — precise, not vague ("dropping X, replacing with Y") 3. Why — the reasoning, with specifics ("3 weeks of DevOps work not in scope") 4. Impact — honest trade-off ("slightly less instant, all functional requirements met") 5. Stakeholders named explicitly — @mentions for visibility 6. Consent by silence deadline — "objections by EOD Thursday" — prevents endless back-and-forth 7. Decision log link — preserves institutional memory
Urgency labels for async messages: • URGENT: — response same day required • INPUT NEEDED: — respond by [date] • FYI: — no response needed, for awareness • DECISION: — requires explicit approval • SCOPE CHANGE: — impacts current work
3 / 9
Your backend engineer colleague is signing off for the day (they're UTC+1). A junior developer on your team (UTC-6) will need to pick up their in-progress work. Write the handoff message.
Option B is a complete async handoff message. It eliminates the need for any back-and-forth by providing every piece of context the next engineer needs:
Complete handoff message contains: 1. Timezone + local time — so recipients can calculate overlap and response windows 2. Named recipient — @mention, not implicit 3. Precise work status per component — not "almost done" (useless) but "streaming module 70% done, specific TODO at file:line" 4. Open blockers with named person — "rate-limit config unclear, cc @architect" — prevents junior from spinning on an unanswerable question 5. Test suite status — current pass rate + root cause of failures + known fix approach 6. Exact next steps in order — so the junior doesn't have to guess what to prioritize 7. How to reach you — response window for async questions ("08:00 UTC+1 tomorrow")
Rule: A good handoff message should let the next person start working within 5 minutes without any clarifying questions.
4 / 9
Which of these async standup formats (written standup replacement) provides the most useful information for a distributed team?
Option C is a complete async standup update. Most useful standup updates follow the Yesterday/Today/Blockers/FYI structure with these elements per section:
Yesterday (what was completed): • Specific artifact (PR #288, not "worked on auth") • Discovery or side effect worth noting • Link to review-ready work
Today (what you will work on): • Named tasks with rough time estimates ("est. 4h") • Names collaborators needing your attention (@alice's PR)
Blockers: • Specific ask, named person, specific deadline ("by noon UTC") • Context needed for them to unblock you (Figma link)
FYI (team awareness): • Anything that affects others' work today
Why "Nothing to report" is harmful async: In async teams, silence is indistinguishable from being stuck. Writing "on track" provides false reassurance with zero actionable information. Even on smooth days, share what you finished and what you're starting — this allows the team to spot duplicated work and offer help proactively.
5 / 9
Alice, a senior backend engineer, just posted a code review comment on your new user registration service. The comment reads: 'This section needs further validation – consider adding checks for email format and password complexity.' Which Slack message would be the MOST appropriate response to acknowledge her feedback and indicate you'll investigate?
The best response demonstrates appreciation for Alice's expertise and commitment to quality. Option A is polite and acknowledges her feedback directly. Options B & C are dismissive or postpone action, while option D provides misleading information suggesting completion without actual investigation – all of which could frustrate a senior engineer.
6 / 9
Ben, the API developer, has just returned an error response from the payment gateway integration: `HTTP 403 - Forbidden`. The documentation states this usually indicates insufficient permissions. You need to update the PR description explaining the issue to the team. Which statement is MOST effective in communicating this information clearly and concisely?
A good PR description should clearly state the problem, its cause (as much as is known), and the immediate next steps. Option 2 provides this detail – it identifies the error code, the likely root cause based on documentation, and indicates investigation. Options A & B are too vague; option D is an oversimplification.
7 / 9
Charlie, a DevOps engineer, has alerted you to a degraded performance metric for the user dashboard. The monitoring system shows a sustained increase in response times (90th percentile > 5 seconds). You need to quickly inform your team about this issue and request assistance. Which of these messages is MOST suitable for a brief update during a daily stand-up?
Charlie's update needs to be informative without causing panic. Option 1 is too vague; option 3 suggests a single cause, which could be misleading. Option 2 clearly states the problem, acknowledges investigation, and invites collaboration – essential for a stand-up context.
8 / 9
David, the team lead, needs to explain a change in requirements to the frontend developers. The original plan was to allow users to upload images directly; however, due to security concerns, this has been removed. Which asynchronous communication method would be MOST effective for conveying this update?
Slack is ideal for quick, targeted communication within a team. Option 1 creates unnecessary documentation; option 3 is overly formal and cumbersome; and option 4 is entirely impractical in a modern development environment. Option 2 provides clarity, context (security), and encourages questions.
9 / 9
Emily is transitioning responsibility for a critical microservice to another team. She's sending out an update to stakeholders. Which statement best describes the level of detail Emily should include in her asynchronous communication?
Effective handover communication balances clarity with conciseness. Option 1 would be overwhelming; option 3 is insufficient and potentially confusing; and option 4 provides irrelevant historical data. Option 2 outlines the essential elements: roles, contacts, and a realistic transition plan – crucial for a smooth handover.
What will I practice in "Async Written Updates — Remote Communication Exercise"?
This is a Remote & Async exercise set. It walks through 9 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 9 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.