Day one looks like any new hire's first day: accounts provisioned, a Slack handle, access to the repo. By day three, the real test starts. Can this engineer actually ship something real without you holding their hand through every decision? Here's what the first two weeks of adding a remote developer to an existing team actually look like, not the sanitized version from a sales deck.
What happens in the first 48 hours?
Access and context, in that order. GitHub or GitLab, Slack or Microsoft Teams, Jira or Linear, your CI/CD pipeline, and whatever internal docs exist in Notion or Confluence. A good engineer spends day one reading, not writing: the codebase's actual architecture, not just the README, plus the last 10 or so closed PRs to see how your team actually reviews code versus how the style guide says it should work. If someone's assigned a ticket and shipping code within the first few hours, that's usually a red flag, not a win. It means they skipped the reading.
When does the new engineer actually start writing real code?
Usually day 3 or 4, on something small and low-risk by design. A bug fix, a small feature with a clear spec, a test suite gap. The goal isn't speed yet, it's calibration: does their code match your conventions, do their PRs come with the right context, do they ask good questions when something's ambiguous instead of guessing and shipping anyway. Week one is diagnostic. Anyone selling "productive from hour one" is selling a myth, or selling a developer who got lucky with an unusually simple first ticket.
What should the standups actually look like in week one?
More check-ins than usual, tapering fast. Daily 1:1s with whoever's onboarding them for the first 3 to 5 days, not just the regular team standup. The new engineer should be asking more questions than they answer in week one. If they're quiet in standups and their PRs come back clean on the first review, that's the actual signal things are going well, not a 15-minute daily scrum ritual where nobody says anything useful.
How much should a new remote engineer actually ship in the first two weeks?
Less than you'd think, and that's fine. One to three shipped PRs of real size by the end of week two is a reasonable bar for a senior engineer joining a codebase they've never seen, more if the task is narrow and well-scoped, less if your codebase has unusual architecture or thin documentation. Judging week-two output against a developer who's been on your team for 2 years is comparing two different jobs. Context takes time to build regardless of seniority.
What goes wrong most often in the first two weeks?
Two things, almost every time. First, nobody owns onboarding, so the new engineer bounces between three people's half-remembered explanations of how the system works, and pieces together a wrong mental model nobody catches until week three. Second, the engineer gets handed an ambiguous, high-stakes ticket on day two because "they're senior, they'll figure it out," which tests the wrong thing at the wrong time. A dedicated onboarding owner and a deliberately low-stakes first ticket fix both.
How do you actually know by day 14 if the fit is right?
Three signals matter more than velocity. Does their code need major rework after review, or just the normal nitpicks every PR gets? Are they asking sharper questions in week two than week one, meaning their mental model is actually improving? And do they flag risk before you ask, the kind of thing covered in depth in hire dedicated developers who actually take ownership. If all three point the right way, the engagement is working. If none of them do by day 14, that's worth a direct conversation, not a wait-and-see extension.
If you're about to add a remote engineer and want the onboarding structured properly from day one, see our dedicated full-stack developers or backend engineers pages, or read how we actually run engagements before you commit. For what should happen next, see the first 30 days with a new dedicated engineer, and if you're still deciding whether this is augmentation or a replacement hire, read augmenting vs replacing. And if retention after the first few months is the bigger worry, why teams stay with us 18+ months covers what we do differently.