A study of software engineers at a Fortune 500 firm found that engineers on co-located teams received 23.9% more code-review comments than those on split teams — and that when offices closed, the advantage narrowed by 18.3%, with new hires and young engineers losing the most (NBER Working Paper 31880). The same study found the cost ran the other way for seniors: experienced engineers wrote less code when they sat near the people they were teaching. That is the real price of a remote intern. It is not the stipend; it is your best engineer’s time, and remote work hides it until nobody is paying it.
Key takeaways
- Remote work does not measurably cost output — a randomised trial of 1,612 graduates found no difference in performance reviews or promotions over two years. What it costs is teaching.
- When offices closed, the lost feedback was disproportionately the helpful, actionable kind, and juniors lost the most of it.
- Mentoring is paid for in senior output. Treat it as a line in the sprint plan, owned by one named person.
- For a US startup with an intern in India, distance is not a variable you can reduce — so design the feedback in from day one.
Remote does not cost output. It costs teaching.
The output question has a good answer. Nicholas Bloom, Ruobing Han and James Liang randomly assigned 1,612 graduate employees at Trip.com to either full-time office work or two days a week at home, and published the result in Nature (Bloom, Han & Liang, 2024). The hybrid group resigned at a rate about one-third lower, and there was no significant difference in performance reviews or promotions over the following two years (BPS Research Digest).
The teaching question has a less comfortable one. In the Fortune 500 study, engineers near their teammates asked more follow-up questions and drew feedback from a wider set of colleagues. When distance took that away, the comments that vanished were disproportionately the ones a machine-learning classifier rated as helpful, actionable and well-reasoned. The benefit showed up in the code: after a three-day office mandate, engineers on co-located teams became 1.4 percentage points less likely to introduce bugs than engineers on distributed teams, and less-tenured and younger engineers saw roughly twice the average gain.
The bill lands on your best engineer
The authors are explicit that mentoring is not free: the experienced engineers who give the most feedback wrote less code when sitting near colleagues, and the gap closed when offices shut. The firm then did what many firms did. With mentoring harder, it shifted towards hiring older, already-trained engineers, and shifted back when offices reopened.
Their national estimate is the part a founder should notice: remote work accounts for 64% of the rise in unemployment among young college graduates in remotable US jobs between 2017–19 and 2022–24. Companies did not stop valuing junior engineers. They stopped being able to train them cheaply at a distance, so they stopped hiring them. That is a market inefficiency — and the startup that can train at a distance gets first pick of what everyone else walked away from.
Distance is binary, so design for it
One detail from the study changes how a small team should think about this. A ten-minute walk between two buildings reduced feedback as much as being several states away. And adding a single distant colleague to a co-located team cut feedback between the original teammates too, because meetings moved online to include them.
For a US startup with an intern in Bengaluru or Kharagpur, that settles the question. You are not choosing between near and far; you are already far, and the default outcome is the low-feedback one. Everything the office used to provide for free — the overheard question, the “come look at this” — has to be put back deliberately, in writing, by a named person. Review is the natural place: Google’s engineers describe education as a core purpose of code review, and spend around three hours a week on it (Sadowski et al., ICSE 2018). We covered the weekly review rhythm itself in the review loop that works. This post is about paying for it.
Budgeting the mentor: a checklist
- Name one mentor before the offer goes out. Not “the team”. If nobody can be named, you are not ready to hire an intern yet.
- Put the time in the sprint plan. A fixed weekly block, visible to whoever plans the mentor’s work. Mentoring done in leftover time is the first thing a deadline eats.
- Expect the mentor’s own output to dip, and say so. The study measured it. Planning for it stops the mentor from quietly cutting the mentoring instead.
- Replace the drop-by with a standing invitation. A channel or thread where questions are expected, answered inside your overlap window. The research found proximity works by making asking easy; remote, you have to make it easy on purpose.
- Add a second reviewer. Remote engineers draw feedback from fewer people. A second reviewer widens that at little extra cost and spreads the load.
- Write review comments that teach. Say why, not just what. The lost comments in the study were the explanatory ones — those are the ones worth the senior’s time.
- Track two numbers. Time to first review on the intern’s changes, and whether the same correction recurs. The first tells you if the budget is being spent; the second tells you if it is working.
- Review the budget at week three. Raise it, lower it, or end the internship — but decide, rather than letting it erode.
Buy the part you cannot train
Mentoring budget goes further when the intern arrives able to ship. Tierones matches US startups with students from IITs, NITs and IIITs on proof of work — real commits, contest ratings, shipped projects and a code walkthrough — so the senior hours go into your codebase, not into basics. It is free while the network grows, and stipends are set by you. For the first month, pair this with the 30-day onboarding plan, or start at tierones.io/employers.
FAQ
How much senior engineering time does a remote intern need?
Enough that one named person owns it and it appears in the sprint plan rather than in leftover time. For scale, Google’s engineers spend around three hours a week reviewing all code, and an intern’s early changes need more explanation per line. Set a fixed weekly block and revisit it after three weeks.
Does remote work hurt junior engineers more than senior ones?
The best current evidence says yes. In a Fortune 500 study, sitting near teammates increased feedback, the gains were concentrated among new and younger engineers, and the advantage narrowed by 18.3% when offices closed. Experienced engineers, meanwhile, wrote more code with nobody nearby to ask them questions.
Is it worth mentoring a remote intern if they might not stay?
Only if you decide so up front, because the cost is real either way. The same study found engineers trained on co-located teams were more likely to leave for better jobs. A startup’s return is the work shipped during the internship plus a first look at a future hire, so scope the internship to produce both.
Ready to spend mentoring time on someone who can already ship? Tell us what you need — we’ll show you proof, not CVs.