.NET Developer Job Description Template: What to Include and What to Cut

Most .NET developer job descriptions attract the wrong candidates not because the role is unclear to the hiring manager. The problem is that the written description fails to translate internal requirements into searchable, specific signal. A posting that says “experience with .NET and C#” will surface 4,000 applications from developers who have touched a tutorial, maintained a legacy Web Forms application, and shipped production ASP.NET Core microservices at scale. The JD cannot distinguish between them because it was not written to.

This post gives you a complete .NET developer job description template built for specificity. The template covers every section a modern JD needs, from role summary and reporting structure through granular technical requirements and working arrangement details. It also walks through what to strip from generic templates that HR departments recycle and how to adapt the whole thing for a nearshore hiring arrangement. In that context, English communication requirements belong in the requirements section, not as a soft preference buried in the nice-to-have list.

Why Most .NET Job Descriptions Fail Before Anyone Reads Them

The failure point in most .NET developer JDs happens before a single candidate applies. Job boards and ATS platforms use keyword matching to surface your posting to the right pool. Most .NET job descriptions are written so generically that they match every .NET developer regardless of seniority or framework specialization. The result is a high-volume, low-quality inbound pipeline that costs your recruiter two to three weeks of screening time on candidates who were never the right fit.

There are three structural failure patterns that appear repeatedly in .NET job descriptions across industries.

The version omission problem

Writing “.NET experience required” without specifying the runtime version or framework is the single most expensive mistake in a .NET JD. The .NET ecosystem in 2026 spans .NET 9, .NET 8 LTS, .NET 6, legacy .NET Framework 4.x, and .NET Core 3.1 codebases that were never migrated. A developer with five years of production .NET Framework 4.8 experience and one who has built greenfield .NET 9 minimal API services are not interchangeable. They have different mental models, different tooling habits, and different learning curves on your stack. Specifying “.NET 8 or .NET 9 required, .NET Framework experience a plus” instantly narrows the field and sets accurate expectations.

The framework conflation problem

ASP.NET Core, Blazor, WCF, and Windows Forms all exist under the .NET umbrella, and they require genuinely different skill sets. A developer who has spent three years building Blazor Server SPAs is not the same as one who has built REST APIs with ASP.NET Core controllers and the MediatR pipeline. Specifying “ASP.NET Core REST API development” removes Blazor developers who are not the right fit and keeps them from going through a screening process only to learn the role is not what they expected.

The soft-skills padding problem

Generic JD templates pad requirements sections with phrases like “strong problem-solving skills,” “collaborative team player,” and “excellent communication skills.” These add length without adding signal. Every candidate reads them and skips past them. In a nearshore context, “excellent communication skills” fails completely because it does not distinguish between skill levels. B1 English is adequate for written documentation, while B2+ English is required for real-time standup participation and live technical debates with US engineers. Replace soft-skills padding with observable, verifiable requirements.

Role and Reporting Structure

Every effective .NET developer JD starts with a clear role definition section that answers three questions. What will this person build, who will they report to, and how does this role connect to the broader engineering organization? These are not the same as the job title and they cannot be answered by the job title alone.

Seniority and scope

Mid-level and senior .NET developer roles require very different JD language. A mid-level role can specify that the developer will work within a defined architecture and implement features against existing design patterns. A senior role should specify architectural ownership: who will this person collaborate with on technical decisions, are they expected to mentor junior engineers, and will they participate in architecture reviews or lead them? If the role is a senior developer but the expectation is more mid-level execution, write the JD to match the real scope. Otherwise you will hire someone who is quickly frustrated by the gap.

Reporting line and team structure

State clearly whether this role reports to a VP of Engineering, a CTO, a lead architect, or an engineering manager. For nearshore roles, include whether the developer reports into a US-based team or a hybrid structure. This matters for candidates evaluating the role. A developer who wants close architectural mentorship has different needs than one who wants autonomy and a direct line to the product owner. Teams that run flat reporting structures should say so; teams that run traditional engineering ladders should say so. Ambiguity here is not candidate-friendly neutrality, it is a signal that the organization has not thought through the role.

Sprint and collaboration model

The JD should specify the sprint cadence (one-week, two-week), the planning and retrospective model (Scrum, Kanban, or hybrid), and the expected synchronous participation requirements. For nearshore .NET developers from Costa Rica operating at UTC-6, this section should state explicitly that standup and sprint ceremonies occur in US hours. It should also make clear that the role requires synchronous participation during those windows. A candidate who cannot commit to US morning hours for standups should know that before they apply, not after the first interview.

Technical Requirements That Actually Signal the Right Depth

The technical requirements section is where most .NET JDs lose specificity entirely. A list that includes “C#, .NET, SQL Server, REST APIs” is accurate but not useful. Every .NET developer in the market can check all four boxes. The goal of this section is to identify the depth and specific combination of skills that predicts success in your codebase, not to describe .NET development in general terms.

Framework and runtime specificity

List the exact .NET version your team targets. If you are on .NET 8 LTS with an upgrade path to .NET 9 in the next two quarters, write that. If your codebase includes a legacy .NET Framework 4.8 module that will not be migrated this year, note that as well. A developer who has only worked on greenfield .NET 8 projects needs to understand that they will encounter older patterns in your codebase. Hiding that produces an unhappy hire within 90 days.

For the framework layer, be specific about the API surface your team uses. “ASP.NET Core development” covers controllers, minimal APIs, Razor Pages, and gRPC services. Say so explicitly if you are building a REST API with controller-based routing and Swagger/OpenAPI documentation. Note it as well if you are migrating to minimal APIs. Blazor should be listed separately from the REST API work when it is in the stack. The two require different skills and attract different candidates.

Data access and ORM requirements

Specify your ORM and usage pattern explicitly. Entity Framework Core 8 with code-first migrations and Fluent API configuration is a different working environment than Dapper with raw SQL stored procedures. If your team uses both, list both and indicate the primary data access layer. EF Core version matters because EF Core 8 introduced features like complex types, raw SQL improvements, and JSON column support that differ meaningfully from EF Core 6 or 7. A developer who learned EF Core on a tutorial in 2021 and has not kept pace with the version progression will have gaps in real production scenarios.

Cloud and infrastructure requirements

If your stack runs on Azure, list the specific Azure services the developer will work with. Azure App Service deployment, Azure Service Bus messaging, and Azure Functions for serverless event processing are distinct skills within the Azure ecosystem. So are Azure Blob Storage and Azure AD for authentication via MSAL. A developer who has deployed an ASP.NET Core app to Azure App Service has not necessarily worked with Azure Service Bus. They may also have no experience configuring Azure AD B2C tenant flows. The more specific you are, the more accurately candidates can self-assess their fit before applying.

Testing and CI/CD expectations

List the testing framework (xUnit is the current .NET community standard; NUnit remains common in older codebases), the mocking library (Moq or NSubstitute), and whether you require integration tests using WebApplicationFactory. If your CI pipeline enforces a minimum test coverage threshold via dotnet test with Coverlet, include that number. Engineers who have shipped in test-enforced environments have different habits than those who wrote tests when they felt like it. Stating your testing culture in the JD filters for cultural fit before the first call.

The Complete .NET Developer Job Description Template

Use this template as a starting point. Replace the bracketed fields with your specific stack details before posting. Every section exists for a reason; resist the urge to remove sections because they seem “too detailed.” Specificity is the point.

What to Cut from Generic JD Templates

Most .NET job descriptions that get recycled across organizations contain sections and phrases that add word count while actively reducing the quality of the candidate pool. Here is what to remove and why each cut improves the JD.

Cut: “proficiency in Microsoft technologies”

This phrase is so broad that it is meaningless as a filter. SQL Server, Azure, SharePoint, Power BI, Office 365, Active Directory, and Dynamics 365 are all Microsoft technologies. A .NET developer JD that lists “Microsoft technologies” as a requirement without specifying which ones sends the wrong signal. It tells candidates that the hiring team does not know its own stack well enough to write it down. Replace this with a specific list of the Microsoft tools the developer will actually use in the role.

Cut: “experience with Agile methodologies”

Every modern engineering team claims to practice Agile. What candidates and hiring teams actually mean when they write this varies widely. It can mean anything from certified Scrum teams with rigorous sprint discipline to teams that have a weekly meeting they call standup. Replace this phrase with the actual sprint model you use. For example: “2-week Scrum sprints with planning on Monday, daily standup at 9am CT, retrospective on the last Friday of each sprint.” This gives candidates accurate signal about the working rhythm and eliminates the mismatch between candidates who expect structured Scrum and teams that run loose Kanban.

Cut: years of experience as the primary filter

Requiring “5+ years of .NET experience” filters out a developer who has shipped three production ASP.NET Core applications with EF Core 8, xUnit test suites, and Azure DevOps CI pipelines in three years. At the same time, it admits a developer with six years of maintaining a stagnant .NET Framework 2.0 application. Years are a proxy for skills, and they are an imprecise one. Replace a years-of-experience gate with specific skills and a question in the application about which .NET version and frameworks the candidate has shipped to production. The answer is more predictive than a year count.

Cut: “strong communication skills” (without specifics)

Every job posting includes this phrase. No candidate has ever read it and thought “that disqualifies me.” It adds no filter because every applicant self-assesses as a strong communicator. For a nearshore or remote .NET role, replace this with a verifiable English requirement: “B2+ English proficiency required. Must be able to participate in live standup calls, write clear PR descriptions in English, and communicate blockers asynchronously via Slack without requiring interpretation.” This is a real requirement that candidates can accurately self-assess against and that recruiters can evaluate in a written screen before the first call.

Cut: duplicate skill listings across sections

Many JD templates list C# in the requirements section and again in the nice-to-have section. Others list Azure in the technical skills and again in the job summary paragraph. Duplication wastes the reader’s time and makes the document look like it was assembled by copy-pasting from multiple templates without editing. Do one pass for requirements and one pass for nice-to-haves. Every item should appear exactly once, in the section where its absence is actually disqualifying (requirements) or merely a preference (nice-to-have).

Cut: company history paragraphs longer than two sentences

A JD is not a marketing brochure. Candidates who reach the first screening call have already researched the company. Four-paragraph company origin stories at the top of a JD push the actual role requirements below the fold. That reduces the keyword density that job boards use to match the posting to relevant candidates. Keep the company description to two sentences maximum: what the company does and why the engineering team is an interesting place to work. Link to the careers page for more context.

Adapting the Template for Nearshore .NET Roles

A nearshore .NET developer JD shares 80% of its structure with a domestic JD. The differences are concentrated in three specific areas: the working arrangement section, the English proficiency requirement, and the compensation framing. Getting all three right matters. It separates a nearshore JD that attracts qualified Costa Rica candidates from one that generates confusion and misaligned applications.

Working arrangement: time zone, not just “remote”

A JD that says “remote” without specifying time zone expectations will attract applications from developers in UTC+5:30, UTC+3, UTC+8, and UTC-6. For a nearshore role where the entire value proposition is real-time US overlap, this is counterproductive. Specify UTC-6 (Costa Rica operates at this offset year-round with no daylight saving adjustment) and the US time zones that overlap. State clearly which ceremonies require synchronous participation. For example: “Daily standup at 9:00 AM CT, sprint planning on Monday mornings, and async availability by 8:00 AM CT for ad hoc Slack communication.” Candidates in the right time zone will self-select; candidates in incompatible zones will move on.

English proficiency: in the requirements, not the nice-to-have

For a nearshore .NET developer role, the developer participates in US engineering ceremonies in English every day. That makes English proficiency a hard requirement, not a preference. List it explicitly in the technical requirements section with a specific level: “B2 or higher English proficiency required. Must communicate clearly in spoken English during daily standups and written English in PR descriptions, Jira tickets, and Slack updates.” Including a brief written English test in the application process is the most efficient way to enforce this requirement without investing recruiter time in calls that will not advance. Candidates simply respond in writing to a technical question before the first call.

Compensation framing for nearshore candidates

Candidates applying for nearshore roles through a staffing agency are aware that the rate structure differs from a direct hire salary. You do not need to explain the agency model in the JD. You should, however, indicate whether compensation is posted as a fixed monthly rate or an hourly equivalent, and whether the posted rate is all-inclusive of local employment costs or base compensation only. Candidates who have worked through nearshore staffing agencies before already understand the model. The monthly rate covers salary plus benefits administered by the agency in Costa Rica. Candidates who are new to the model appreciate a one-line clarification. If you are posting the role through a staffing partner like Kore BPO, the staffing partner handles this conversation directly with candidates. You can omit the compensation details from the JD entirely.

Common .NET Job Description Mistakes

These are the most predictable errors that appear in .NET developer JDs after the first draft is reviewed. Most of them are easy to fix once you know what to look for.

Listing every .NET technology that has ever existed

Requirements sections that include .NET Framework, .NET Core, .NET 5, .NET 6, .NET 8, .NET 9, WCF, WPF, Windows Forms, Xamarin, MAUI, Blazor, ASP.NET MVC, ASP.NET Web API, and SignalR in a single list are signaling something specific. It tells candidates the JD was written by someone who searched “.NET technologies” and pasted the results. No developer has production depth in all of these. A list this broad tells candidates nothing about what the role actually requires. It also tells experienced developers that the hiring team does not have a real technical opinion about its own stack. Pick the four to six technologies that are genuinely required and list those.

Confusing the job posting with the job brief

An internal job brief is a detailed document your engineering manager and recruiting team use to align on what you need. A job posting is a public document candidates use to decide whether to apply. These are different audiences with different information needs. The brief can include internal context like team dynamics, technical debt the new hire will inherit, and longer-term career trajectory. The posting should contain the role description, technical requirements, working arrangement, and a clear application step. If your job posting reads like an internal memo, it has not been adapted for external consumption.

Missing a clear application step

The most common omission in .NET JDs is the absence of a specific, actionable next step for the candidate. “Send your resume to jobs@company.com” is functional but misses an opportunity to pre-screen. For a technical role, the application step can include a one-question written technical prompt that candidates answer before the first call. Ask them to describe in three to five sentences how they have structured dependency injection in a recent ASP.NET Core project. Have them explain why they made those choices. The response simultaneously evaluates English writing clarity and ASP.NET Core knowledge. Candidates who send a blank email with an attached resume without addressing the prompt self-select out of the process without recruiter time investment.

Posting the same JD for multiple seniority levels

A single JD that lists “Mid-level to Senior .NET Developer” with requirements written for a senior role will attract senior candidates. It will also push away mid-level candidates who meet 70% of the requirements. If you are open to either seniority level, write two short sections under the requirements: “Required for all levels” and “Required for senior candidates.” This structure lets a strong mid-level developer see that they are qualified for the base role. It also lets a senior developer see what additional ownership the senior version of the role carries. It also gives recruiters a clearer framework for screening conversations.

Frequently Asked Questions

Disclosure: Kore BPO is a nearshore and offshore staffing agency. This article reflects our direct experience placing .NET and C# developers from Costa Rica with US engineering teams. Recommendations in this post are based on JD review and placement outcomes across multiple engagements.