How to Hire .NET Developers: Skills, Interviews, Rates and Timelines
The first question is not simply whether someone knows C#. It is which version of .NET your application uses and what you need the new developer to do. A person who builds new cloud APIs may not be the right fit for an older WPF desktop system, while an experienced .NET Framework developer may need time to adapt to a modern cloud-native setup.
For a useful shortlist, describe the application in plain language, ask candidates for examples from similar projects, and have a technical colleague or hiring partner validate the deeper details. You do not need to become a .NET expert yourself. You need enough context to recognize relevant experience, ask consistent questions, and notice when an answer is too vague.
When you’re looking to hire dot NET developers, a precise brief makes the screening questions and the eventual price comparison much more useful. At Mobilunity, we usually provide the first matching CV within five business days, and often sooner, once the role and project requirements are clear.
What .NET Experience Does Your Project Need?
A .NET developer may build web applications and APIs, support services hosted in Azure, maintain an internal business system, work on an older WinForms or WPF desktop product, or develop a Unity game. These projects can all involve C# and .NET, but they call for different experience. Your job description and interview should reflect the work the person will actually inherit. The application context also matters, especially for legacy systems and .NET in regulated industries.
For a web product, the developer may work on business logic, database access, integrations, authentication, and releases. If the application runs in the cloud, the role may also include post-deployment configuration, monitoring, and troubleshooting. An enterprise system can add years of business rules and integrations with finance, reporting, or customer management tools.
Desktop maintenance is another profile. A WinForms or WPF application may rely on Windows-specific behavior, older libraries, and undocumented processes that the business still needs. Unity is different again because game-development experience, performance requirements, and release workflows matter more than conventional business-application experience.
The version of .NET helps you identify the kind of experience a candidate needs. Older .NET Framework applications are usually Windows-based and may require maintenance experience, while modern .NET applications are often built for web, cloud, or cross-platform use.
You do not need to understand every version number. Ask your current developer, vendor, or IT lead which .NET version and application type your project uses. Then look for candidates who have worked on similar systems – for example, desktop maintenance for an older WPF application or web and deployment experience for a modern API.
Because C# is the main language used across much of the platform, our hire a C# developer guide can help you understand the overlap.
Decide What You Are Hiring Before You Write the Job Ad
A clear vacancy lets suitable candidates recognize themselves and helps unsuitable candidates opt out early. Start with the project rather than a long list of technologies. Explain what the application does, which .NET version it uses, where it runs, what the developer will own, and what success should look like during the first three to six months.
Three common project shapes illustrate why this matters. A new ASP.NET Core service needs someone comfortable making decisions in a fresh codebase. A .NET Framework-to-.NET migration needs a developer who can preserve existing behavior while replacing old dependencies. WinForms or WPF maintenance needs patience with an established system and the ability to trace business rules that may not be documented.
A generic .NET developer job description might ask for “strong .NET experience” and “excellent problem-solving skills.” Those phrases do not help a candidate judge fit. A clearer version would say: “Maintain a .NET Framework 4.8 WPF application, investigate production issues, and replace a legacy integration during the next two quarters.” The second version tells applicants what they will work on and gives you a better basis for the first call.
Include the practical details candidates use to decide whether to apply: salary range, working hours, location or remote policy, team structure, benefits, and interview stages. Replace “competitive salary” with a real range. Replace “flexible” with the actual overlap hours and explain whether overtime is expected and compensated. Replace “innovative project” with one specific example of the product, users, or technical challenge.
If you are still defining the role, the same project-first approach applies when you hire developers by technology. Describe the business outcome and the system you already have, then let a technical reviewer help translate that need into the right profile.
Comparing the scope with an unrelated role, such as Java developers, is useful only when your company is still choosing a platform, not when the application is already built on .NET.
Before the vacancy goes live, make sure it answers five simple questions: What will this person work on? Which version and application type are involved? What will they own? Who will support their technical decisions? What are the pay range and working conditions? A candidate who can answer those questions from the ad is more likely to give you relevant examples in the interview.
The Five Skills to Test For, and How to Test Each
For each skill below, listen for the same pattern: the situation, the problem, what the candidate personally did, and the result.
Async and Await
Asynchronous code lets an application keep working while it waits for a database, file, or external service. Problems arise when that work is forced to run synchronously through calls such as.Result or .Wait(). Depending on the application, users may see slow requests, timeouts, or a screen that appears to hang.
Ask the candidate to describe an async problem they caused, diagnosed, or prevented. A strong answer connects a visible symptom to an investigation and a change. You do not need to decide whether it was technically a deadlock or thread starvation during the conversation. Your technical reviewer can confirm that later. You are checking whether the person has handled the problem in a real system and can explain it without hiding behind terminology.
Entity Framework and the N+1 Problem
Entity Framework Core lets .NET applications work with a database through code. It can also produce inefficient queries when used without understanding what happens underneath. One common example is the N+1 problem, where an application retrieves a list and then makes an additional database request for each item in that list.
Ask about a page, report, or API that became slow as the amount of data grew. A useful answer explains how the candidate found the database activity, what they changed, and what improved. Terms such as projection, Include, or AsNoTracking are meaningful only when the candidate connects them to a measured result. A weak answer defines N+1 correctly but cannot describe how they would notice it in an actual project.
Dependency Injection and Lifetimes
Dependency injection provides an application component with the services it needs. Those services can live for different lengths of time. A transient service is created when requested, a scoped service usually lives for one web request, and a singleton stays for the application’s lifetime.
For a non-technical interviewer, the key issue is whether the developer understands the consequences of a wrong choice. Ask for a time when a service kept data for too long, was disposed too early, or behaved differently under concurrent use. A useful answer names the affected service, the symptom, and the correction. A weak answer recites the three lifetime definitions but offers no example from a real project.
Cloud Operations
“Azure experience” can mean anything from reading logs to designing an entire cloud environment. Ask what the candidate personally deployed and operated. Which Azure or AWS service hosted the application? How did a change reach production? Where were configuration values stored? What happened when a release failed?
The answer should also reveal the boundary between the developer and a platform team. A .NET developer may own application configuration, App Service deployments, and troubleshooting while another team owns networking, governance, and Kubernetes. If your role includes the second set of responsibilities, define that explicitly and compare it with the scope of dedicated DevOps engineers.
Testing
Testing experience is easier to understand through an example than through a coverage percentage. Ask which behavior the candidate wanted to protect, what kind of test they wrote, and whether it caught a defect or made a later change safer. They may mention xUnit or NUnit, unit tests, integration tests, or tests that run automatically in CI.
Also ask what happened when a test suite became slow or unreliable. A useful answer may describe separating slower integration tests, repairing unstable test data, or changing a test that failed randomly. A weak answer lists tools but cannot explain what the tests protected. Your technical reviewer can inspect the code later; the first call should establish that the candidate treats testing as part of delivery.
Seven Interview Questions, and What a Good Answer Sounds Like
Use these .NET developer interview questions to get dated, project-specific examples. When an answer stays theoretical, ask what the candidate personally changed.
1. “Describe a deadlock you caused with async code.”
What to expect: The candidate explains what users or the team observed, such as hanging requests or timeouts, then describes how they traced the issue and changed the code. They may mention Result or .Wait() (), blocked threads, or using async code through the full call path.
Weak-answer signal: They say only that async code is “faster” or that developers should “always use async/await,” without describing a real symptom, investigation, or result.
2. “Scoped, transient, or singleton: tell me about a time you picked wrong.”
What to expect: The candidate identifies a service registered as scoped, transient, or singleton, explains what state it held, and describes the failure caused by the choice. They should be able to explain the fix in terms of the application, not only repeat definitions.
Weak-answer signal: They define the three lifetimes accurately but cannot connect any of them to a service they built, reviewed, or debugged.
3. “Walk me through an EF Core query you had to rewrite.”
What to expect: The candidate describes how they noticed the problem, such as a slow page or too many database calls. They explain how they inspected the SQL or query timings, what they changed, and how they checked the improvement.
Weak-answer signal: They list methods such as Include or AsNoTracking without explaining why one was appropriate or what changed after it was used.
4. “What is the difference between .NET Framework and .NET 8 for a buyer, not a developer?”
What to expect: The candidate relates the answer to the application. They explain that an older .NET Framework desktop system and a new service on a current .NET release require different maintenance, deployment, and migration experience.
Weak-answer signal: The answer becomes a list of platform features and version numbers, but the candidate cannot say which profile they would recommend for an older WPF application.
5. “What have you deployed to Azure, and what broke?”
What to expect: The candidate names one application, the hosting service, the deployment path, and an incident. Their answer makes it clear what they owned and what a platform or infrastructure team handled.
Weak-answer signal: They list Azure products but cannot describe a deployment, a production problem, or their own role in resolving it.
6. “A dependency has a CVE and no patched version. What do you do?”
What to expect: The candidate first checks whether the vulnerable component is used and reachable. They then consider alternatives, ways to reduce exposure, documentation, and escalation to the appropriate security or product owner.
Weak-answer signal: They answer “update the package” even though no fixed version is available, or they make a major replacement decision without assessing the actual exposure.
7. “When is .NET the wrong choice?”
What to expect: The candidate considers the existing platform, team experience, target device, deployment environment, delivery time, and cost. They give at least one situation where another option would fit better and explain the trade-off.
Weak-answer signal: They claim .NET is suitable for every project or criticize another technology without connecting the answer to project constraints.
If the candidate’s examples do not match the role, revisit the job brief before screening more people. The mismatch may come from the search criteria rather than the individual candidate.
A 90-Minute Screening Task You Can Send Today
This task is designed so a non-technical hiring manager can send it while an engineer, consultant, or hiring partner reviews the result. Prepare a small ASP.NET Core starter repository with a working local build, a simple database model, an Azure sandbox, and an existing CI workflow. The candidate should not lose most of the 90 minutes creating accounts or repairing the exercise itself.
Send the candidate this instruction:
Deploy the provided ASP.NET Core application to Azure App Service and connect it to the supplied SQL database. Add one small endpoint or page, keep secrets and configuration values out of source control, add one automated test, and make sure the test runs in the existing CI workflow. Update the README so someone outside the engineering team can understand how the application is configured, tested, and deployed.
Tell the candidate to stop after 90 minutes and add a short note about any unfinished work. Let them use a private repository and keep ownership of the code they produce. State the starter repository’s license and your submission terms before the task begins.
The technical reviewer can score one point for each of these outcomes:
- The application is deployed and reachable.
- Secrets are kept out of source control.
- At least one automated test runs in CI.
- The README explains setup and deployment clearly enough for a non-specialist to follow.
A score is only the start of the discussion. The reviewer should also note whether the candidate made reasonable choices, explained limitations, and kept the change within scope. If your role does not involve Azure, adapt the hosting step to the environment the developer will actually use.
What It Costs: Rates by Countries and In-house Comparison
A .NET developer salary, a freelance rate, and the monthly cost of a dedicated developer are different measures. Salary is compensation paid to an employee. An in-house budget may also include taxes, benefits, recruiting, equipment, and management time. A client hiring cost may include local HR and operational support. Compare the total cost of each option before deciding which is less expensive.
For Ukraine, the ranges below come from Mobilunity’s internal .NET hiring data and were checked in September 2026. Gross compensation is what the developer earns before deductions. Client hiring cost is the monthly amount paid under the hiring model and should not be presented as the developer’s salary.
| Seniority | Ukraine gross monthly compensation | Ukraine monthly client hiring cost |
| Junior | $1,000-$2,000 | $2,450-$3,500 |
| Middle | $2,000-$4,200 | $3,450-$5,700 |
| Senior | $4,200-$5,700 | $5,650-$7,200 |
| Team Lead | $5,700-$6,800 | $7,150-$8,300 |
As of September 2026
Salary is not the same as the cost of employing a developer in-house. The estimates below add mandatory employer-side payroll charges to the published annual .NET salary benchmark. They do not include recruiting, equipment, private health insurance, pension top-ups, training, paid leave beyond statutory requirements, or the cost of an unfilled role.
Salary is not the same as the cost of employing a .NET developer in-house. The table below adds 2026 employer-side statutory payroll charges to annual salary benchmarks. It excludes recruiting, equipment, private benefits, management time, office costs, and vacancy cost.
| Country | Annual .NET salary benchmark | Estimated employer payroll charges | Estimated annual statutory employer cost |
| United States | $109,408 | $8,412+ | $117,820+ |
| Netherlands | $81,035 | $21,475–$22,665+ | $102,510–$103,700+ |
| Spain | $44,970 | $13,783+ | $58,753+ |
| Canada | $49,026 | $3,884+ | $52,910+ |
| Poland | $18,213 | $3,730+ | $21,943+ |
Sources: Prosfy, IRS, Canada Revenue Agency, Dutch Tax Administration, Polish ZUS, boe.es
As of September 2026
Treat the figures as a starting point. The final cost depends on seniority, tech stack, location, time-zone overlap, English level, and industry knowledge. Legacy systems or rare skills can make a developer harder and more expensive to hire.
When comparing an in-house hire with a freelancer or dedicated team, check what the quoted rate includes: working hours, time off, HR and payroll, equipment, and replacement support. Refresh the figures before you decide.
Dedicated Team vs Freelancer vs In-house Hire
When you hire .NET developers, the right model depends on how long the work will continue, how much context the developer needs, and how much management your team can provide. An in-house employee is often appropriate for a permanent role with direct organizational ownership. A freelancer can be efficient for a contained assignment. Companies often hire dedicated .NET developers for ongoing work where continuity matters, but they do not want to build local recruiting and employment operations.
Hire in-house when the role is central to the organization, and you want direct responsibility for recruiting, employment, development, and retention. This model can work well when there is a strong local candidate pool, and your company already has the HR and engineering leadership to support the hire.
A freelancer can be the better choice for a small API, a contained integration, a short migration component, or temporary specialist input. The model becomes less predictable when the work depends on months of business context, frequent coordination, or long-term availability. A capable freelancer may also be serving several clients, which can affect scheduling.
A dedicated development team is designed for continuing work alongside your own people. At Mobilunity, we support recruiting and ongoing HR operations while the client keeps day-to-day control of priorities and technical direction. Our consultant trial-period success rate is 97%, and retention across client projects over the past 12 months is 94%. Retention still varies by client and project, so these figures should be read as our company results rather than an industry guarantee.
| Factor | In-house employee | Freelancer | Dedicated developer or team |
| Best fit | Permanent organizational role | Defined, bounded assignment | Ongoing product or enterprise work |
| Cost structure | Salary plus employer costs | Hourly or project fee | Recurring client hiring cost |
| Ramp-up | Recruiting, notice period, onboarding | Often short for a narrow scope | Candidate selection and onboarding |
| Continuity | Managed directly by the employer | Depends on individual availability | Supported by the provider and engagement model |
| IP and access | Employment agreement and company policy | Contract terms | Contract terms and provider process |
| Management | Full HR and technical management | Scope and contract management | Client leads the work; provider supports HR operations |
All three models still require clear ownership. Your team needs someone who can set priorities, review work, and keep source code and deployment access in company-controlled accounts. If you are deciding between models rather than hiring a fixed project team, an IT staff augmentation arrangement may provide the ongoing capacity you need without transferring product ownership.
Red Flags in a .NET CV and in the First Call
A red flag is a reason to ask a follow-up question, not an automatic rejection. A short CV may omit useful detail, while a long technology list may hide limited ownership. Look for recent, dated examples that match your application and give each candidate the same chance to explain missing information.
- No .NET versions or dates by project. You cannot tell whether the candidate’s recent work matches your runtime.
- Repeated .Result or .Wait() calls in a code sample. Ask the technical reviewer whether the candidate understands the risk in that application.
- Entity Framework is listed without any database or query example. Ask about a slow query the candidate diagnosed.
- Azure appears as a skill without a deployed service. Ask what the candidate operated and what happened during a failed release.
- No tests are mentioned. Ask whether tests were absent from the project or simply omitted from the CV.
- Older .NET Framework patterns are presented as the default for new work. Ask which decisions were inherited and what the candidate would choose today.
Use the first call to fill those gaps. Ask when the work happened, what the candidate personally owned, who else was involved, and what changed after their contribution. The aim is to replace assumptions with a clear, comparable example.
This longer sample looks credible at first glance, which is exactly why the missing detail matters. None of the flags proves that Alex lacks the skill. They show which questions will help you decide whether the experience matches your vacancy.
How Long It Takes, Brief to First CV
The first CV, accepted offer, start date, and first working commit are separate milestones. Keep them separate in the hiring plan so a delay in the notice period or system access is not confused with search time.
At Mobilunity, we provide the first matching CV within five business days in most searches, often sooner. This depends on the brief details. A search for a current ASP.NET Core developer is usually broader than a search that requires recent .NET Framework 4.8, WPF, WinForms, and a specific industry integration.
During the first week, we confirm the profile, search criteria, and early candidates. The next stage covers interviews, technical validation, selection, contracting, and the developer’s availability. The exact duration depends on the number of interview stages, decision speed, notice period, and whether the working environment is ready.
Before the start date, prepare repository access, credentials, documentation, a local setup path, and a person who can review the first change. A useful first-week assignment is a small bug fix, test, or configuration update. It confirms that access and expectations are working without asking a new developer to redesign the system immediately.
Legacy desktop roles can take longer because the shortlist must combine the right runtime, Windows technology, and recent maintenance experience. Mandatory cloud experience, a narrow time-zone overlap, or a long interview process can also extend the date. If timing is important, separate true requirements from skills the person could learn after joining.
