Two different .NET jobs, and most adverts do not say which.
Building something new on .NET 8 and maintaining a WebForms application from 2011 are not the same role, are not the same person, and should not be the same job description. We staff both, deliberately.
public partial class Orders : System.Web.UI.Page
{
protected void Page_Load(object s, EventArgs e)
{
if (!IsPostBack)
grid.DataSource = Db.GetOrders(
Convert.ToInt32(Request["custId"]));
grid.DataBind();
}
}app.MapGet("/orders/{custId:int}",
async (int custId, AppDb db, CancellationToken ct) =>
await db.Orders
.Where(o => o.CustomerId == custId)
.Select(o => o.ToDto())
.ToListAsync(ct));Greenfield .NET and Framework maintenance are different hires.
A strong .NET 8 engineer may never have seen a page lifecycle, a ViewState problem or a WCF binding. That is not a gap in their ability, those things have been gone from new development for a decade. Put them on a 2011 WebForms application and they will be slow, frustrated and looking for another role.
The reverse is just as true. An engineer who has spent ten years maintaining Framework applications may not have used dependency injection, async/await throughout, or minimal APIs, and dropping them into a modern codebase without support produces code that looks like 2012 with newer syntax.
We ask which you have before proposing anybody, and where the answer is both, which is common, because most organisations are running the old thing while building the new one; we staff for both, not pretending one person covers it comfortably.
The engineers who span both exist, and they are usually the ones who have done a migration. That is a specific and valuable profile, and it is the one we would put on a modernization programme rather than on either side alone.
What you are on, and what it means for the hire.
The word “.NET” covers about fifteen years of substantially different platforms. This is the first thing we establish.
| What you are running | The hire you need | Note |
|---|---|---|
| .NET 8 / 9, ASP.NET Core | Current-stack engineer | The straightforward case |
| .NET 6 / 7 | Current-stack engineer | Upgrade path is usually short; worth doing |
| .NET Core 3.1 | Current-stack engineer | Out of support, the upgrade is the first conversation |
| .NET Framework 4.8 MVC | Either, with a preference for migration experience | Most common enterprise position |
| WebForms | Legacy-capable engineer | A genuinely different skill set; scarce and worth paying for |
| WCF services | Legacy-capable engineer | Migration target is usually gRPC or REST |
| Mixed estate | One of each, or a migration profile | The honest answer for most organisations |
| Coming from ColdFusion | Migration profile | See ColdFusion to .NET |
What we ask a .NET engineer.
Language questions filter almost nobody at senior level. These are the ones where the answers actually diverge.
How do you handle a long-running operation in a request?
We are listening for a queue and a background service, not for a longer timeout. It is the fastest way to find out whether someone has operated a system under load.
EF Core or Dapper, and why?
There is no right answer. There is a wrong one, which is having no opinion or holding one that does not reference the shape of the queries.
Where do you put business logic?
Controllers, services, domain objects, and crucially, why. This predicts what the codebase will look like in a year better than anything else we ask.
What breaks when you scale to two instances?
In-memory caching, session state, singletons holding mutable data, scheduled jobs firing twice. Anyone who has done it lists these immediately.
How is this tested?
We want to hear about seams and injected dependencies. Candidates who describe testing as a separate later activity write code that cannot be tested.
Talk us through a migration you have done.
Framework to Core, or something older. This is the profile most of our clients need and it is the hardest to verify from a CV.
Four contexts, and what each one demands.
Rate is the same across these. What differs is the profile we would put forward, and getting that wrong is more expensive than any rate difference.
- Building new services on .NET 8. Clean architecture, minimal APIs, containers, CI. The most straightforward brief and the easiest to hire for.
- Keeping a Framework application alive. WebForms and MVC5 estates that still run the business. Scarce skills, low drama, and enormous value to the organisations that depend on them.
- Migrating Framework to Core. The profile that spans both, working incrementally behind a router. See legacy modernization.
- Migrating ColdFusion to .NET. Engineers who read CFML and write C#, which is a combination almost nobody else fields. See ColdFusion to .NET.
- Extending line-of-business systems. The unglamorous majority of .NET work: reports, integrations, workflow, and the regulatory change that arrives every year.
- Data and integration work. SQL Server, SSIS estates, message queues and the API surface between systems that were never designed to talk to each other.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring .NET engineers.
Including the one about our own legacy bias.
Will an engineer who works on our legacy system be any good?
This is a fair worry and the honest answer is that it depends on why they are doing it. An engineer who ended up on legacy work because they could not keep up is a real phenomenon and we do not put those people forward. An engineer who chooses this work because they like systems that carry real business weight, and who is also current on modern .NET, is a different profile entirely and is exactly who you want, they will maintain what you have without quietly resenting it, and they will be useful when you decide to modernise. You interview them, so you can form your own view. We would rather you turned somebody down than accepted a profile you were unsure about.
We are on .NET Framework. Should we upgrade before hiring?
No, hire first, upgrade with help. Upgrading an application whose behaviour is not fully documented is precisely the kind of work that goes wrong when a team attempts it alone while also keeping the lights on. What we would do is put an engineer with migration experience alongside your team, spend the first weeks establishing what the application does, and then move it incrementally with both versions running. That sequencing also means you do not have to make the platform decision under time pressure, which is when organisations pick the fashionable option instead of the right one.
Do your .NET engineers work on Azure?
Most of them, yes, and it is worth being specific about what that means. Building and deploying .NET applications to App Service, Functions, Container Apps and SQL Database is routine for our engineers and does not need a separate hire. Designing a landing zone, setting up networking and identity across subscriptions, or owning cost governance is a different discipline and we would put a cloud engineer on it — see cloud engineers, who cover Azure as well as AWS despite the URL. Asking a .NET developer to do both is how you get an application that works and an environment nobody can audit.