A guide to hiring a Microsoft developer
Microsoft makes a wide range of tools for people who build software, and a lot of businesses depend on them. When a company says it needs a Microsoft developer, it usually means a person who writes C# on the .NET platform and works with the tools around it, such as ASP.NET Core, SQL Server and Azure. Read on for what the work includes, how to judge a candidate and how to run the day to day with a remote engineer. It helps most when your systems already run on Microsoft software, or soon will.
What a Microsoft developer works on
The core of the job is C#, a language used for web apps, services, desktop programs and background jobs. Around it sit the pieces that make a system useful. A database such as SQL Server keeps the data. A hosting setup such as Azure runs the app. Sign-in connects to the accounts staff already use. Because the parts are designed to work together, one person can often move across all of them, which saves time on hand-offs.
Where the roles differ
A back-end developer may work in many languages, and .NET is one of them. A WinForms developer or a Prism developer focuses on Windows desktop screens. A Xamarin developer focuses on mobile apps written in C#. A SQL developer focuses on the database. A Microsoft developer is the wider role: the person who looks after the whole system and brings in a specialist when one is needed.
When a Microsoft developer makes sense
- Your main business software is written in C# and the original developers have gone.
- You want a new web app or portal that works with the Microsoft tools your staff use.
- An older .NET Framework app needs repair, security updates or a move to a current version.
- You plan to move servers to the cloud and want code and hosting handled by one person.
- You need your software to read or write mail, calendars or files in Microsoft’s office tools.
If your system uses a different language end to end, a Microsoft developer is probably not the right first hire. Hiring for the stack you really use will save you money.
Reading a Microsoft developer’s background
Ask for examples of systems that stayed in use for a long time. Good answers explain what the developer inherited, what they changed and how they avoided breaking things. Treat a background that is only a list of product names with caution. Real skill shows in the choices a person made, such as how they handled a slow report or a risky upgrade.
Interview questions to try
- How would you find out why a page in a C# web app is slow?
- What do you check first when a database query takes far too long?
- How would you move an old .NET Framework app to a current version without a long outage?
- Where do you keep passwords and keys for an app that runs in the cloud?
- How do you decide what to test in a project with no tests at all?
Listen for clear reasoning and real examples. Doubt anyone who answers every question with a product name and no explanation.
Try a paid mini project
Give each finalist one small piece of real work, for example fixing a slow query, adding a page to an existing app or writing a short upgrade plan. Pay for the hours. Then judge how readable the code is, what questions the person asks and how clearly they explain their choices.
Plan the access carefully
Microsoft systems often hold staff records, customer data and financial figures. Give your developer only the access the job needs, use accounts owned by your company and review who has what from time to time. Keep source code in a repository you own. When the work ends, remove the access the same day.
Working with your team
Share a simple map of your systems, even if it is a rough drawing. Explain which parts are fragile and which are safe to change. A weekly call and a shared task list keep people in step, and a written note after each change helps whoever opens the code next.
Define the scope early
Microsoft projects tend to grow, because every system touches another one. Before work starts, write down which apps, databases and accounts are in scope and which are not. Agree what finished looks like for the first month. A clear boundary helps your developer give an honest estimate, and it protects you from surprise costs when an old system turns out to be tied to something nobody mentioned.
Mistakes to avoid
- Hiring for a long list of products when the job needs only two or three.
- Skipping a review before an upgrade and finding the problems on release day.
- Giving full administrator rights to every new person.
- Leaving the only copy of important code on a personal laptop.
Want a narrower role? See our WinForms developers for Windows desktop apps, or our SQL developers for database work.