How far away can you hire a developer?
Further than most companies allow, and the constraint they usually impose is the wrong one. Timezone difference is not what causes remote hires to fail. What causes them to fail is a developer who cannot get an answer, working on a product nobody has written anything down about, and that arrangement fails at three hours of difference as reliably as at nine. The question worth asking is what specifically in your week needs a live human, because the list is shorter than it feels.
Does the timezone gap actually cause the problem?
Usually it amplifies an existing one. If decisions in your company are made in conversations that are never written down, a developer in the next room can catch up by overhearing and a developer eight hours away cannot. The distance did not create the gap, it removed the workaround.
The same applies to requirements. A vague ticket is survivable when clarification takes ten minutes and expensive when it takes a day. Companies that blame the timezone for slow delivery are commonly describing a specification problem with a longer feedback loop attached.
The practical consequence is that the fix is rarely to hire closer. It is to make the answer available without a conversation, which improves things for everyone including the people in the office.
What is different about a single remote developer?
The absence of a peer, which matters more than the hours. A developer in a remote team has someone to ask, someone to review their code, and someone who notices when they have been stuck for two days. A solo remote developer has none of that, and the failure mode is silent: work continues, and it drifts.
The second difference is that everything technical routes through one person, so the cost of them being asleep is not just delay, it is that nobody else can answer. A production problem at your midday is unattended until their morning, and no amount of goodwill changes that.
This is worth naming before hiring, because it changes what you should buy. A solo remote developer needs either a regular external review arrangement or a clear agreement about what happens during an incident, and both are cheaper to arrange at the start than after the first bad week.
How much overlap do you actually need?
It depends on which activities in your week genuinely require a live conversation. Four commonly do: unblocking, decisions with more than one plausible answer, incident handling, and the first few weeks of a new person. Everything else works in writing, often better.
| Overlap | Works when | Breaks when | What to change |
|---|---|---|---|
| None | Well-specified work, mature product, written culture | Requirements are vague or the product is new | Write specifications properly, or buy overlap |
| One to two hours | Most product work with a clear backlog | Incidents needing a human within the hour | Put the overlap at the start of their day |
| Three to four hours | Fast-changing products, frequent decisions | Rarely, though it costs a location premium | Protect it for questions, not for status updates |
| Full day | First month of a first hire, or live incident work | It is bought and then spent on a standup | Ask what you are using it for after month two |
Where should the overlap sit?
At the start of their working day, not the end of yours. A developer who hits an ambiguity in their first hour and can resolve it immediately loses twenty minutes; the same developer hitting it after your team has gone home loses a day. Two hours placed correctly outperforms four placed badly.
This means the calendar decision matters more than the geography decision, and it is under your control. Moving one recurring meeting can convert a marginal arrangement into a workable one without changing anybody's location.
Do not spend the overlap on status. Status is the thing that writes down best, and using live time for it is how companies conclude that they need more overlap when what they need is a different agenda.
What has to be written down?
Three things, and none of them is a large document. First, why decisions were made, kept as short notes near the code or in the ticket. Not the decision, which is visible in the code, but the alternative that was rejected and the reason, which is not.
Second, how to run and deploy the thing, tested by having somebody follow it from a clean machine. A setup document that only works for its author is the most common blocker in the first fortnight of a remote hire, and it is discovered at exactly the moment the author is asleep.
Third, who decides what. A remote developer stuck between two people who each think the other owns a decision will wait, politely, for days. A single line naming the owner of each area removes an entire class of delay.
How do you interview for async ability?
Send a deliberately ambiguous written question before any call and read the reply carefully. A candidate who states their assumptions, answers both interpretations briefly, and asks one precise question is showing you the exact skill the arrangement requires. One who writes a paragraph asking to jump on a call is showing you something else.
In conversation, ask how they handled being blocked in their last remote role. The strong answer includes a time limit: they describe how long they work on something before writing it up and asking, and what they do in the meantime. The absence of any such rule is the thing that produces silent weeks.
Finally, ask what they wrote down in their last job that other people used. It is a low-key question and it separates people who work in the open from people who work quietly and report at the end, which is the single most reliable predictor of whether a distant hire will go well.
Common questions
- How much timezone overlap do you need with a remote developer?
- One to two hours covers most product work with a clear backlog, provided it sits at the start of the developer's day rather than the end of yours. A developer who hits an ambiguity in their first hour and can resolve it immediately loses twenty minutes; the same ambiguity after your team has finished costs a full day. Placement matters more than length.
- Does hiring a developer in a distant timezone slow delivery?
- It amplifies whatever was already unclear. If decisions are made in conversations nobody writes down, distance removes the workaround of overhearing them. If tickets are vague, a clarification that took ten minutes now takes a day. Companies that blame the timezone are commonly describing a specification problem with a longer feedback loop attached, and hiring closer treats the symptom.
- What is different about hiring one remote developer rather than a remote team?
- The absence of a peer. A solo remote developer has nobody to ask, nobody reviewing their code, and nobody noticing when they have been stuck for two days, so the failure is silent rather than visible. Everything technical also routes through one person, meaning a production problem is unattended until their morning. Both are worth arranging for before hiring, through external review and an explicit incident agreement.
- What has to be written down for remote development to work?
- Three things: why decisions were made, meaning the rejected alternative and the reason rather than the decision itself; how to run and deploy the system, verified by someone following it from a clean machine; and who owns which decisions. The last one prevents a developer waiting politely for days between two people who each believe the other decides.
- How do you interview a developer for asynchronous working?
- Send a deliberately ambiguous written question before any call. A candidate who states assumptions, answers both interpretations briefly and asks one precise question is demonstrating the exact skill. Then ask how they handled being blocked in a previous remote role; a strong answer includes a time limit before they write it up and ask, and what they do while waiting.
