3 exercises — communicate meeting times, availability, and scheduling across multiple timezones clearly.
0 / 8 completed
1 / 8
You're sending a meeting invitation to team members in Warsaw (UTC+1), New York (UTC-5), and Singapore (UTC+8). The meeting is at 09:00 UTC. Which invitation text handles timezones correctly?
Option B is a professional timezone-aware meeting invitation:
Required elements in cross-timezone invitations: 1. UTC as the anchor time — neutral reference all can convert from 2. Pre-calculated local times — recipients shouldn't have to do math ("10:00 Warsaw / 04:00 NY / 17:00 Singapore") 3. Acknowledging inconvenient times — "04:00 is very early for NY" shows awareness and respect 4. Async alternative offer — recording option for off-hours participants is inclusive practice 5. Agenda — necessary for time-zone scheduling especially; let people decide if attendance is worth the hour
Meeting scheduling tools that help: • worldtimebuddy.com — visual timezone overlap tool • Every Time Zone (everytimezone.com) — quick reference • Calendar apps: when you set a recurring meeting, set it in UTC to avoid DST drift issues
DST warning: "10am every Monday" will shift by 1 hour twice yearly for parts of your team. UTC times don't drift. Always anchor in UTC for international teams.
2 / 8
When scheduling a meeting with a colleague in a different timezone, which phrasing is clearest?
Option C is the gold standard for cross-timezone scheduling communication:
What makes it clear: • UTC anchor — "14:00 UTC" is unambiguous regardless of where either person is • Pre-calculated local times for both parties — no mental math required, no DST confusion • Alternative provided — "or 16:00 UTC" — reduces back-and-forth
Problems with "Does 2pm work?": • Whose 2pm? Ambiguity caused many missed meetings • Even with "2pm EST", confusion arises during DST transitions (EST vs EDT) • UTC avoids all of this
Pattern for timezone scheduling: "Does [HH:MM] UTC work? That's [local-time] for you in [their city], and [local-time] for me in [my city]."
If you use named timezones: Prefer "CET" over "German time", "JST" over "Japan time", and always specify whether DST is in effect. For truly global teams, use only UTC offsets.
3 / 8
You need to communicate your availability windows for the week to a distributed team with members in UTC-8, UTC+0, and UTC+9. Which availability message works best for everyone?
Option C is a complete async availability declaration for distributed teams:
What effective availability communication includes: 1. UTC hours — anchor, not "my local time" 2. Pre-calculated local conversions for each major team timezone — so anyone can reference it at a glance 3. Named overlap window — "best overlap: 13:00–15:00 UTC" — highlights the golden hours where synchronous collaboration is practical 4. Async response commitment — "respond within 8 hours" — sets expectations for messages outside working hours 5. Urgent escalation path — "Slack @ mentions" — tells people how to reach you if something truly can't wait
"Working agreement" template for distributed teams: Many remote teams publish a shared working agreement document containing everyone's: • UTC working hours + overlap windows • Async response time SLA • Communication channels by urgency level • Days off and holiday patterns
This document eliminates the need to re-negotiate expectations every time a new collaboration starts.
4 / 8
Sarah from Berlin (UTC+1) is reviewing a pull request submitted by Mark in Los Angeles (UTC-8). Mark has commented on the code with: 'I've fixed the issue. Let me know if you have any questions.' Sarah replies, 'Thanks! Could you please update the documentation to reflect these changes?'. Which response from Sarah is most appropriate considering the time difference and professional communication best practices?
The key here is to clearly state the desired action (updating the documentation) and why it's important. Option 1 avoids ambiguity and directly requests the necessary follow-up. Options 2 and 3 are too demanding or vague, while option 4 introduces unnecessary complexity by asking for more details before requesting a specific task.
5 / 8
David, based in London (UTC+0), is sending an update to his team via Slack. He needs to inform them that he's blocked on receiving a response from the New York team (UTC-5) regarding a critical API integration. Which of the following messages best conveys this situation?
Option 2 is direct and clearly states the blockage. However, it's slightly informal; the best practice is to politely acknowledge the delay without blaming. Option 1 is too vague. Option 3 proactively requests action, which is good, but still avoids directly stating the problem. Option 4 simply repeats the situation without offering a solution.
6 / 8
Elena needs to include a timezone note in her pull request description for a change that affects the scheduling of automated tests. The tests run nightly at 23:00 UTC. Which sentence is most effective?
Option 2 explicitly states the time (23:00 UTC) and includes a reminder to consider it. This is crucial for developers in different timezones who need to understand when the tests will run and potentially impact their work. Options 1 and 4 are too general while option 3 is overly verbose.
7 / 8
Tom is giving a standup update to his team, which includes information about the progress on a feature. He's working in Tokyo (UTC+9) and his teammates are spread across London (UTC+0), New York (UTC-5), and Sydney (UTC+11). Which statement would be clearest for everyone to understand?
Option 3 provides specific information about the progress and sets expectations for the future. This is more informative than simply stating that 'good progress' has been made. It allows team members to gauge how close Tom is to finishing and helps manage expectations across all timezones. The other options are too vague or lack crucial details.
8 / 8
Maria receives an API response from a server in San Francisco (UTC-8). The response includes a timestamp: '2024-10-27T14:30:00Z'. She needs to convert this timestamp into UTC+1 (her local timezone) for logging purposes. Which conversion is correct?
The API response indicates UTC. To convert from UTC to UTC+1 (which is UTC +1 hour), you need to add one hour to the UTC timestamp. Therefore, '2024-10-27T14:30:00Z' + 1 hour = '2024-10-27T15:30:00Z' becomes '2024-10-27T18:30:00Z'.
What will I practice in "Time-Zone Communication — Remote Communication Exercise"?
This is a Remote & Async exercise set. It walks through 8 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 8 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.