Working from Kathmandu with European and US colleagues means my "morning" can be someone's "midnight." Time zones are the number one concern hiring managers have about international remote hires. Here's how to make them a non-issue.
Calculate your real overlap
Write down your working hours and the team's in UTC.
| Location | Typical working hours (local) | In UTC (example, standard time) |
|---|---|---|
| Kathmandu (UTC+5:45) | 10:00–18:00 | 04:15–12:15 |
| Berlin (UTC+1) | 09:00–17:00 | 08:00–16:00 |
| New York (UTC−5) | 09:00–17:00 | 14:00–22:00 |
Overlap with Berlin here is about 4 hours; with New York, none unless someone shifts. Daylight saving in Europe and the US changes this twice a year (Nepal doesn't observe it), so recheck in March and October/November.
Shifting a couple of hours (e.g. 12:00–20:00) can create overlap with both Europe and the US East Coast.
Async-first habits
- Write decisions down: issues, docs, ADRs (leading remotely)
- End-of-day handoff: done, blocked, next
- Record short videos for demos and walkthroughs
- Make PRs self-explanatory (code review)
- Batch questions so one exchange resolves several
Use overlap hours well
Reserve shared hours for:
- Discussions that need back-and-forth
- Pairing and unblocking
- Planning and retros
Not for status updates that could be written.
Telling hiring managers
In applications and interviews, say exactly:
"I'm available 12:00–20:00 Nepal time, which overlaps 4 hours with CET and 2 hours with US Eastern. I work async-first: daily written handoffs and detailed PRs."
Concrete beats "I'm flexible."