How to onboard an external .NET engineer in two weeks: a checklist for engineering managers

When you add an external engineer to your team, the expensive part is rarely the search. It is the first two weeks: waiting for accounts, reading outdated documentation and asking questions nobody has time to answer. A senior engineer who spends ten days waiting for VPN access costs you the same as one who ships features.

This checklist is what we go through with engineering managers before a new Appstronauts engineer joins their team. It works for anyone joining an existing .NET codebase, external or not.

Before day one

• Accounts and access. Email or guest account, Git repository, CI/CD, issue tracker, chat, VPN and any cloud subscriptions (Azure DevOps, Azure portal with the right role). Request them at least five working days in advance. Access requests are the most common reason the first week is lost.
• A working development environment. Can a new person clone the repository and run the solution locally from the README alone? If not, write down the missing steps now: SDK versions, connection strings, secrets, local databases, certificates.
• A named buddy. One person on your team who answers questions in the first two weeks. Block an hour a day in their calendar for it.
• A first ticket. Choose a small, real task that touches the main flow of the system: a bug fix or a small feature, not documentation work. It should be possible to finish it in two or three days.

Week one: context, then code

• Day 1: architecture walkthrough. Sixty minutes with the tech lead: main components, data flow, external integrations, where the dragons are. Record it; the next person will need it too.
• Day 1–2: run everything locally. The new engineer builds the solution, runs the tests and runs the application. Every problem they hit becomes a fix in the README.
• Day 2–4: the first ticket. Pair on the first hour, then let them work. Review the pull request the same day.
• Day 3: join the rituals. Stand-up, planning, refinement and retro, from the first week. External engineers who skip the rituals stay external.
• Day 5: short check-in. Fifteen minutes with the engineering manager: what is unclear, what is blocking, what should change.

Week two: first sprint commitment

• Take normal tickets from the backlog, sized like for everyone else on the team.
• Agree on the Definition of Done: tests, code review rules, branching, release process. Write down what is implicit.
• Give production context: monitoring, logs, how incidents are handled, who is on call.
• Second check-in at the end of the sprint, with the vendor if you work with one. This is the moment to correct course, not after three months.

What the vendor should handle

If you extend your team through a partner, part of this list is their job, not yours. A good partner:

• sends profiles matched to your stack and codebase, not a stack of CVs,
• prepares the engineer before day one with the information you share,
• checks in with you after the first week and the first sprint,
• plans holidays and replacements, so your sprint does not stop when someone is away.

The short version

Accounts before day one. A working local setup. A buddy. A real first ticket. Rituals from the first week. Two check-ins. With that in place, two weeks from the first call to the first commit is realistic, also in a large, older .NET codebase.

If you are planning to add senior .NET or JavaScript engineers to your team, this is how team extension works at Appstronauts.

Appstronauts

Need senior .NET, JavaScript or Dynamics 365 engineers on your team?

Book 30 minutes with Rado, our co-founder. Tell us what your team needs and get a straight answer on whether we can help.

Book a call with Rado How team extension works →