.NET Web Developer Interview Questions and Scorecard
Six question sets for the employer running the interview: C# fundamentals, ASP.NET Core, data and performance, security and deployment, an owner screen that needs no .NET knowledge, and a scoring rubric with red flags. Download as DOCX.
The first .NET developer I ever hired interviewed beautifully and could not, when I finally asked, tell me how his own code reached the server. The answer turned out to be a remote desktop session and a folder of copied files. Nothing in my question list had gone anywhere near it, because I had been asking about the language instead of about the job.
That is the trap in hiring a .NET web developer at a small business. The candidate-facing internet is full of C# trivia, and almost none of it tells you whether this person can own your application. At FirstHR, we build for owners and managers who make this call themselves, usually without an HR department and often without a second technical opinion in the building.
This page gives you six question sets written for the employer: what to ask, why the question is worth asking, and what a strong answer sounds like. One of them needs no .NET knowledge at all. The last one is a scorecard, which is the piece almost every question list leaves out.
TL;DR
Interview a .NET web developer across five areas: C# and .NET fundamentals, ASP.NET Core application design, data and performance, security and deployment, and ownership. If you are not technical, run the owner screening set first and buy one paid hour of a trusted developer for the technical round. Score six areas 1 to 5 on a rubric. Web developers reported a median wage of $92,650 a year. Download six sets and a scorecard as DOCX.
What a .NET Web Developer Actually Does
A .NET web developer builds and maintains web applications on Microsoft's platform: server code written in C#, pages or APIs built with ASP.NET Core, a database reached through Entity Framework Core, and hosting on a Windows server or a cloud app service. In practice they own a running system, not a set of files.
At a small business the role stretches further than the title implies. The same person usually designs the database, deploys the changes, watches the error logs, and answers the phone when checkout stops working on a Saturday. That is why the sets below cover deployment and monitoring as seriously as they cover the language. If you are still writing the posting, the web developer job description and the broader software developer job description both work as a starting point for a .NET role.
The Stack Terms Worth Recognizing
You do not need to understand these terms to hire well, but you do need to recognize them, because a candidate who blurs them together is telling you something. Six words cover most of what will come up in the interview.
C#
The language almost all .NET web code is written in. If a candidate says .NET, they mean C# unless they say otherwise.
ASP.NET Core
The web framework itself. MVC, Razor Pages, and minimal APIs are ways of building pages and endpoints inside it.
Blazor
A way to write interactive browser interfaces in C# instead of JavaScript. Useful to know, not required for every role.
Entity Framework Core
The layer that maps C# objects to database tables. Most performance problems on a .NET site start here.
NuGet
The package manager. Ask how they decide to add a package, since every one is a dependency you inherit.
IIS and app services
Where the application runs: the Windows web server, a cloud app service, or containers. It determines who can support you later.
One Question That Sorts Most Candidates
Ask which .NET versions the candidate has worked in and what their current code targets. A strong answer separates the older Windows-only .NET Framework from modern, cross-platform .NET without being prompted, and knows whether the version in question still receives security updates. A candidate who treats those as the same thing has usually spent their whole career inside one legacy application, which may still be exactly the hire you want if that is what you own.
Which Question Set Should You Use?
Pick the sets that match your application and who is running the interview. Most small businesses use the owner screen for the first conversation, then two or three technical sets for the second. Ask the same combination of every candidate for the same role.
C# and .NET Fundamentals
Every candidate
The base set: language basics, async, dependency injection, and whether they separate legacy .NET Framework work from modern .NET. Start here.
ASP.NET Core
The application itself
Request flow, MVC versus Razor Pages versus Blazor versus an API, middleware, sign-in and permissions, configuration and secrets, and testing.
Data and Performance
Where slowness lives
Data modeling, Entity Framework Core migrations, the N+1 query problem, raw SQL, schema changes without downtime, backups, and injection.
Security and Deployment
The operational half
Hosting on IIS or a cloud app service, how a change reaches production, certificates, monitoring, logging, and what happens when they are away.
Owner Screen
No .NET knowledge needed
Every question scored on explanation, ownership, and honesty instead of code, so a non-technical owner can run the first round alone.
Scoring Rubric + Red Flags
Rate and decide
A .NET-specific scorecard across six areas, a ten-item red-flag checklist, and a paid work-sample planner. Use it with any set above.
A rough rule: maintaining an existing internal application means fundamentals plus data. Building something new for customers means ASP.NET Core plus security and deployment. Hiring your only technical person means all four, plus the two-week absence question. Use the owner screen first in every case, and the rubric in every case.
6 Free .NET Question Sets to Download
Download all six as a single Word document, or copy individual sets. Each follows the same shape: when to use it, the questions with notes on what a good answer sounds like, what to listen for, and space for notes. The rubric adds scoring areas, a red-flag checklist, and a work-sample planner.
Download All 6 .NET Developer Question Sets
C# fundamentals, ASP.NET Core, data and performance, security and deployment, an owner screen, and a scoring rubric with red flags. All in one DOCX.
Set 1: C# and .NET Fundamentals Questions
The base set for any candidate: versions, async, dependency injection, exceptions, and packages, each with a note on what a good answer sounds like so a non-developer can score it.
C# and .NET Fundamentals Questions
C# AND .NET FUNDAMENTALS INTERVIEW QUESTIONS
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the base set for any .NET web developer hire. Ask 6 to 8 of these. Each
question has a note on what a good answer sounds like, so you can score the
answer even if you do not write C# yourself. What you are testing is whether the
candidate understands the platform they work on, not whether they can recite it.
QUESTIONS
1. Which .NET versions have you worked in, and what does your current code
target?
(Good answer: separates the older Windows-only .NET Framework from modern,
cross-platform .NET, and knows whether their target version still receives
security updates. Vagueness here usually means legacy-only experience.)
2. Explain the difference between .NET Framework and modern .NET to me as if I
have never written code.
(Good answer: plain language, no jargon shield. If you understand it
afterward, that is a real signal about how they will work with you.)
3. What is the difference between a value type and a reference type in C#?
(Good answer: correct definition plus a real bug it once caused them.)
4. What do async and await actually do, and why do they matter on a web server?
(Good answer: they free the thread while the app waits on a database or an
API, so the same server handles more users. Bonus for naming a case where
they got it wrong and blocked a thread.)
5. What is dependency injection, and how do you use it day to day?
6. How do you handle exceptions in production code, and what do you log?
7. Where do you use LINQ, and where do you deliberately avoid it?
(Good answer: has an opinion with a reason, usually about queries that look
elegant but hit the database badly.)
8. How do you decide between adding a NuGet package and writing the code
yourself?
(Good answer: weighs maintenance, license, and how alive the package is.)
WHAT TO LISTEN FOR
•Separates legacy .NET Framework work from modern .NET work honestly
•Explains technical ideas in plain English without condescension
•Answers with real production stories, not textbook definitions
•Has opinions and can give the reason behind each one
NOTES
__
__
Set 2: ASP.NET Core Web Application Questions
For anyone who will build or maintain the application itself: request flow, framework choice, middleware, sign-in and permissions, configuration and secrets, caching, and testing.
ASP.NET Core Web Application Questions
ASP.NET CORE WEB APPLICATION INTERVIEW QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for anyone who will build or maintain your web application itself:
the pages customers see, the API your mobile app or storefront calls, or the
internal tool your staff lives in. This is the heart of the job for most .NET
web developer roles at a small business.
QUESTIONS
1. Walk me through what happens between a customer clicking a link and the page
appearing.
(Good answer: routing, the middleware pipeline, a controller or endpoint,
a service layer, the database, then the response. Look for a clear mental
model of their own application, not a memorized diagram.)
2. When do you choose MVC, Razor Pages, Blazor, or a Web API with a separate
JavaScript front end?
(Good answer: picks based on the problem and the team, and can say what each
costs. A candidate who only ever picks one approach is a smaller hire.)
3. What is middleware, and what have you written custom middleware for?
4. How do you design an API that other systems call, and how do you version it
without breaking those systems?
5. How do you handle sign-in, roles, and permissions in an ASP.NET Core app?
(Good answer: uses the built-in identity and authorization model rather than
hand-rolled password handling. Rolling their own auth is a warning sign.)
6. How do you manage configuration and secrets across local, staging, and
production?
(Good answer: nothing sensitive in source control, secrets held in a vault
or environment variables. "In the config file in the repo" is a red flag.)
7. What do you cache, and what have you cached that you later regretted?
8. What do you write tests for first, and what do you deliberately not test?
WHAT TO LISTEN FOR
•A clear request-to-response mental model of a real application they built
•Chooses an approach for stated reasons, not habit
•Treats secrets and authentication as solved problems, not personal projects
•Tests the things that would hurt the business if they broke
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Data, Entity Framework Core, and Performance Questions
Most slow-site complaints are database problems. This set covers modeling, migrations, the N plus one query trap, schema changes without downtime, backups, and injection.
Data, Entity Framework Core, and Performance Questions
DATA, ENTITY FRAMEWORK CORE, AND PERFORMANCE QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Almost every .NET web application is a database with a website attached, and
almost every "the site is slow" complaint is a database problem. Use this set
whenever the role touches your data, which is nearly always. These questions
also surface whether the candidate protects your records or just reads them.
QUESTIONS
1. How do you model the data for a new feature before you write any code?
2. Walk me through how you use Entity Framework Core migrations on a live
application.
(Good answer: migrations in source control, reviewed, applied in a
repeatable way, tested against a copy first.)
3. What is the N+1 query problem, and how do you find it in an existing app?
(Good answer: names it, then describes actually profiling the queries rather
than guessing, and fixing it with eager loading or a projection.)
4. When do you drop out of the ORM and write raw SQL or a stored procedure?
5. Tell me about the last slow page you fixed. How did you find the cause?
(Good answer: measured before changing anything. "I rewrote it and it felt
faster" is not an answer.)
6. How do you make a schema change without taking the site down?
7. What is your backup process, and when did you last restore from a backup to
confirm it works?
(Good answer: has actually tested a restore. Most people have not.)
8. How do you prevent SQL injection, and how would you check whether our
existing app is exposed?
WHAT TO LISTEN FOR
•Measures before optimizing, every time
•Treats schema changes as a controlled, reviewable process
•Has tested a restore rather than assuming the backups work
•Understands injection and can explain the parameterized fix plainly
NOTES
__
Set 4: Security, Hosting, and Deployment Questions
The operational half of the job, and the half that produces emergencies: hosting, how a change reaches production, certificates, monitoring, logging, and coverage when they are away.
Security, Hosting, and Deployment Questions
SECURITY, HOSTING, AND DEPLOYMENT INTERVIEW QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
At a small business the .NET developer is usually also the person who deploys,
monitors, and gets called when the site is down. These questions test the
operational half of the job, which is the half that generates emergencies. Ask
them of any candidate who will be your only technical person.
QUESTIONS
1. Where have you hosted .NET applications: IIS on Windows Server, a cloud app
service, containers, or something else? What did you like and dislike?
2. Walk me through how a change gets from your laptop to production.
(Good answer: source control, a review step, an automated build, a staging
environment, then a repeatable deploy. Copying files by hand over a remote
desktop session is a serious red flag for a business-critical app.)
3. How do you handle HTTPS certificates and their renewal?
4. Which common web vulnerabilities do you actively design against, and how?
(Good answer: names injection, cross-site scripting, and cross-site request
forgery, and describes the specific framework protections they rely on.)
5. How would you find out our site is down before a customer calls us?
6. What goes into your logs, and what do you deliberately keep out of them?
(Good answer: never passwords, card data, or personal records in plain text.)
7. If you are on vacation for two weeks and the site breaks, what happens?
(Good answer: documentation, a second person with access, a runbook. This is
the single most useful question for a one-developer business.)
8. Tell me about the last production incident you handled, start to finish.
WHAT TO LISTEN FOR
•A repeatable, reviewed deployment path rather than manual file copying
•Monitoring and alerting that does not depend on customer complaints
•Security handled by design, not by hope
•Plans for their own absence instead of becoming a single point of failure
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Owner Screening Set (No .NET Knowledge Needed)
Every question scored on explanation, ownership, and honesty rather than code, so a non-technical owner can run the first round alone and decide who deserves a technical one.
Owner Screening Set (No .NET Knowledge Needed)
OWNER SCREENING SET: NO .NET KNOWLEDGE NEEDED
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when you are the owner or manager running the interview and you do
not write code. Every question here is scored on explanation, ownership, and
honesty rather than on technical correctness, so you can evaluate the answers
yourself. Run this set first and use it to decide who is worth a technical
round.
QUESTIONS
1. Show me something you built that is live right now. Walk me through the parts
you personally wrote.
(Score: could they point at real work and separate their contribution from
the team's? A working product in front of you is evidence a resume cannot
fake.)
2. Explain a recent technical decision to me as if I know nothing about code.
(Score: did you understand it afterward? Jargon used as a shield is the
opposite of a good answer, and it predicts how they will handle every future
conversation with you.)
3. Tell me about a bug that reached customers. How did you find it, and what
changed afterward?
(Score: ownership. Strong candidates describe their own mistake and the
process change that followed. Weak ones have never made one.)
4. What is the worst codebase you inherited, and what did you do about it?
(Score: pragmatism. "I rewrote everything" is usually the wrong instinct at a
small business.)
5. Tell me about a time you told someone their requested feature was a bad idea.
(Score: will they push back on you, and can they do it without being
difficult?)
6. Everything is urgent and you have one week. How do you decide what to build?
7. What would you need from us in your first 30 days to be productive?
(Score: asks for access, context, and priorities. A candidate who needs
nothing has not thought about it.)
8. Which part of this job would you most want to hand off to someone else?
(Score: honesty about their own gaps.)
WHAT TO LISTEN FOR
•Live, verifiable work they can walk you through in real time
•Explanations you actually understand at the end
•Ownership of a real mistake, with a specific change that followed
•Clear priorities and honest gaps rather than universal confidence
NOTES
__
Set 6: Scoring Rubric and Red Flags
A .NET-specific scorecard across six areas, a ten-item red-flag checklist, and a paid work-sample planner, so the decision rests on written evidence instead of the interview that felt best.
.NET Developer Scoring Rubric and Red Flags
.NET WEB DEVELOPER SCORING RUBRIC AND RED-FLAG CHECKLIST
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 immediately after the interview, while the answers
are fresh. Anchor every score to something the candidate actually said. If more
than one person interviews, each scores independently first, then compare. Use
the same rubric for every candidate for the same role.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
C# and .NET fundamentals: language, platform, async, legacy versus modern
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
ASP.NET Core application design: request flow, APIs, auth, configuration
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Data and performance: modeling, migrations, query cost, measured fixes
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Security and deployment discipline: repeatable deploys, secrets, monitoring
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication: explains a technical decision so a non-developer understands it
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Ownership and honesty: owns mistakes, states gaps, plans for their own absence
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
RED FLAGS (WEIGH CAREFULLY)
[ ] Cannot show or walk through any live work
[ ] Deploys by copying files onto the server by hand
[ ] Keeps connection strings, keys, or passwords in source control
[ ] Wrote their own password and login handling from scratch
[ ] Optimizes by feel, with no measurement before or after
[ ] Has never restored from a backup
[ ] Answers only in jargon and cannot simplify on request
[ ] Blames every previous employer, client, and teammate
[ ] Wants to rewrite your working application before understanding it
[ ] No plan for what happens when they are unavailable
PAID WORK SAMPLE PLANNER (OPTIONAL, RECOMMENDED)
Task: __
Scope (aim for 2 to 4 hours): ______
Rate agreed and paid:
What "done" means: ___
Score the sample on: does it work, is it readable, did they ask good questions
before starting, and can they explain their choices afterward.
You are not grading the code, you are grading the evidence. A specific, measured, honest answer looks different from a confident vague one in any field, and four techniques make that difference visible without any C# on your part.
Make them show, not describe
Ask for a live URL and screen share
Have them separate their work from the team's
Watch them navigate their own code
Score the explanation
Ask for the same idea in plain English
If you understand it, that is real evidence
Jargon used as a shield is the opposite
Chase one answer all the way down
Pick a claim and ask three follow-ups
Real experience keeps producing detail
Rehearsed answers run out quickly
Buy an hour of expertise
Pay a trusted developer for one hour
Have them review a code sample
The cheapest insurance on this hire
The most useful of these is the follow-up chain. Pick one claim, then ask what happened next, then ask how they knew, then ask what they would do differently. Someone who lived through it keeps producing detail; someone who read about it runs dry by the third question. The same principle underpins any structured hiring assessment, and it works just as well on a founder's first interview as it does on a panel.
Two safeguards close the remaining gap. Run a short paid work sample that resembles the real job, and buy one hour of a trusted developer's time to review a code sample or run a technical round. Together they cost very little and catch nearly everything a conversation cannot. If you have no such developer to call, hiring communities and technical sourcing channels are usually where small businesses find one.
The Legacy .NET Framework Question
Ask which platform your application actually runs on before you interview anyone, because it changes who you should hire. A great modern .NET developer can be a poor fit for a fifteen-year-old Windows-only application, and a specialist in that application can be slow to produce on a new cross-platform build.
What you are hiring for
Legacy .NET Framework app
New modern .NET app
Comfort reading someone else's old code
Cross-platform and container experience
Windows Server and IIS knowledge
Modern ASP.NET Core patterns
Patience for incremental upgrades
If you own a legacy application, add two questions: what is the worst codebase you inherited and what did you do about it, and how would you approach upgrading this without stopping the business. The instinct to rewrite everything before understanding it is the most expensive answer a small business can hire.
Fair, Legal, and Structured Interviewing
A fair interview and an effective one are the same interview. Asking the same job-related questions of every candidate keeps you consistent, reduces bias, and produces better hires, and technical interviews drift away from that more than most because shared enthusiasm for a framework feels like signal.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Keep away from age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews have their own version of this trap: asking when someone learned to code, which bootcamp or university they attended and in what year, or where they are originally from can all function as proxies for age or national origin. Ask about the work instead. Every question in these sets is written to stay on the job. This is general information, not legal advice.
Use the same core questions for every candidate
A structured interview, where every candidate answers the same questions scored against the same rubric, predicts on-the-job performance better than a free-flowing conversation, and it reduces the chance that a decision rests on rapport rather than evidence. Technical hiring drifts away from this more than any other kind, because a shared enthusiasm for a framework can eat twenty minutes and feel like signal. Write the questions before the first interview, ask them in the same order, and score them the same way. The sets and the scorecard here exist to make that the path of least resistance.
Pay for work samples
A short take-home task is one of the best predictors available for a developer hire, and a scoped, paid task is fairer and gets better candidates than an unpaid one. Keep it to a few hours, make it resemble the real job rather than a puzzle, and agree in advance on what finished means. Then score four things: does it work, is it readable, did they ask good questions before starting, and can they explain their choices afterward. Senior candidates decline long unpaid assignments, so an unpaid eight-hour project mostly filters for people with time rather than skill.
Match the questions to your actual application
A developer maintaining a fifteen-year-old internal ASP.NET application and one building a new customer-facing API are different hires. Weight the sets to your reality: if you are keeping a legacy system alive, lean on the fundamentals and data sets and ask directly about inherited code. If you are building something new, weight the ASP.NET Core and deployment sets. Decide what the role must accomplish in its first 90 days and interview for exactly that, rather than for a generic senior engineer you do not need and cannot keep busy.
Same Questions, Scored on a Rubric
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you clear of the EEOC rules against basing decisions on protected characteristics. Structure is both the fairer and the more effective choice.
Keep every question tied to the work, and skip the technical small talk that functions as a proxy for age or origin: graduation years, when someone first learned to code, where they are originally from. The questions employers cannot ask apply to developer interviews exactly as they do everywhere else. This is general information, not legal advice.
Scoring and the Hiring Decision
Score every candidate on the same six areas immediately after the interview, while the answers are still fresh, and anchor each score to something they actually said. A written score you can defend beats a strong impression you cannot.
Scoring area
What a 5 looks like
C# and .NET fundamentals
Separates legacy from modern; explains async with a real case
ASP.NET Core design
Clear request-to-response model; framework choice with reasons
Data and performance
Measures before optimizing; has tested a restore
Security and deployment
Repeatable deploys, secrets in a vault, real monitoring
Communication
You understood the plain-English explanation
Ownership and honesty
Owns a real mistake; plans for their own absence
If more than one person interviews, each should score before the group talks, so the most senior voice does not anchor everyone else. An interview evaluation form keeps the format consistent across candidates, and a quick reference check on the two claims that mattered most is the last cheap safeguard before an offer.
Pay and Overtime Classification
Benchmark pay before you interview, not after, because the number you can offer shapes the pool you get. Government wage data is the right baseline, then adjust for your market, the scope you need, and whether the role is remote.
Median $92,650 a Year (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), web developers had a median annual wage of $92,650, about $44.54 an hour, with the lowest 10 percent under $48,100 and the highest 10 percent above $162,290 (U.S. Bureau of Labor Statistics). The broader software developers occupation reported a median of $135,980 in the same survey.
A .NET role that owns an entire application usually benchmarks between those two figures. Classification deserves the same care: the Fair Labor Standards Act includes a computer employee exemption that turns on actual duties and pay rather than the job title, so read the duties test honestly before you decide the role is exempt or non-exempt. If you are engaging a freelancer instead, the employee versus contractor test is a separate question with its own rules.
Interviewing a .NET Developer Without an HR Department
A large company puts this candidate through a recruiter, a hiring manager, two engineers, and a coordinated scorecard. A small business puts them through you, between everything else you were already doing that day. Three realities follow from that, and each one changes what you should ask.
You are hiring a .NET developer without being able to read C#
Most owners making this hire cannot evaluate a code sample, which is exactly why the owner screening set scores explanation, ownership, and honesty rather than syntax. You do not need to grade the code. You need to tell a specific, measured, honest answer from a confident vague one, and you can do that in plain English. Run the owner screen first to decide who is worth more of your time, then spend a small amount of money on one hour of a trusted developer's attention for a technical round or a code review. That single hour is the cheapest insurance available on a hire this consequential.
Your .NET developer will probably be your only technical person
At a larger company this role sits inside a team with a lead, code review, an on-call rotation, and someone else who knows how the deploy works. At a small business the same person writes the code, owns the database, handles the deploy, and answers the phone when the site is down at 9pm. That changes what you interview for. Operational judgment, documentation habits, and a plan for their own absence stop being nice extras and become the questions that protect you. The security and deployment set exists for exactly this, and the two-week vacation question is the most revealing one on the page.
The interview is the easy part; the access and the paperwork are where it gets real
Once you choose someone, a developer hire has a few steps most roles do not. Put the offer and the classification in writing, get an intellectual property assignment and a confidentiality agreement signed before the first commit, and create the repository, hosting, domain, and cloud accounts in the business name rather than inheriting accounts owned by an individual. FirstHR fits this people side: send the offer and the agreements for e-signature, run the new hire paperwork through an onboarding workflow, and keep every signed document on the employee profile where you can find it later. FirstHR is an onboarding and HR platform, not a code repository, a hosting provider, or payroll software, so pair it with those. Applicant tracking is coming soon to FirstHR.
None of this requires an HR department. It requires the questions written down before the first call, the same set for every candidate, and a scorecard filled in while the answers are fresh. Applicant tracking is coming soon to FirstHR, and the rest of the hiring templates are already here.
From Interview to Onboarding
The interview is step one. A developer hire then needs a few things most roles do not: an offer letter that states the classification, an intellectual property assignment and a confidentiality agreement signed before the first commit, and every account created in the business name rather than inherited from an individual.
Offer, IP assignment, and NDA
Put the role, pay, and classification in writing, and have the developer sign an intellectual property assignment and a confidentiality agreement before the first commit.
Accounts in the business name
Create the repository, hosting, domain registrar, database, and monitoring accounts under the company, then grant access. Never inherit an account owned by a person.
Agree the reliability rules on day one
Source control, code review, staging, backups, and who gets called during an outage, settled in week one rather than during the first incident.
Store the records
Keep the signed offer, IP assignment, NDA, I-9, W-4, and policy acknowledgments organized and easy to find when you need them.
After that it is the standard start: new hire paperwork, the I-9 and W-4, and a first month structured well enough that a new developer ships something real instead of spending three weeks hunting for access. FirstHR connects the offer, the agreements, the e-signatures, the paperwork, and the access checklist in one place, and keeps the signed documents on the employee profile where you can find them later. FirstHR is an onboarding and HR platform, not a code repository, a hosting provider, or payroll software, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Interview a .NET web developer on fundamentals, ASP.NET Core design, data and performance, security and deployment, and ownership.
Run the owner screening set first if you are not technical: it scores explanation, ownership, and honesty rather than code.
Ask which .NET versions their code targets, since legacy .NET Framework work and modern .NET work are different hires.
The most reliable red flags are operational: manual deploys, secrets in source control, untested backups, no plan for their own absence.
Add a short paid work sample and one paid hour of a trusted developer to close the gap a conversation cannot.
Benchmark against the BLS May 2025 medians of $92,650 for web developers and $135,980 for software developers, then check the exemption duties test.
Frequently Asked Questions
What questions should I ask a .NET web developer in an interview?
Ask across five areas: C# and .NET fundamentals, ASP.NET Core application design, data and performance, security and deployment, and ownership. Strong openers include which .NET versions their current code targets, what happens between a customer clicking a link and the page appearing, what the N plus one query problem is and how they find it, how a change gets from their laptop to production, and what happens to the site if they are unavailable for two weeks. Follow every answer with a request for a specific example and a measured result. If you are not technical, run the owner screening set first, which scores explanation, ownership, and honesty rather than code, then bring in a trusted developer for one paid hour to run a technical round. This page includes six ready-to-use sets and a scorecard.
What is the difference between .NET Framework and .NET Core?
The .NET Framework is the older, Windows-only platform that runs a very large amount of existing business software and no longer receives new features. Modern .NET, which grew out of the .NET Core rewrite, is cross-platform, faster, and where all new development happens; the version numbers now continue in a single line. The practical hiring consequence is that a candidate whose entire career sits in the old Framework may need time to work comfortably in modern ASP.NET Core, and a candidate who has only ever used modern .NET may struggle with a legacy application you already own. Ask which one your application actually runs on, ask the candidate to describe the difference in plain English, and hire for the platform you have rather than the one you wish you had.
How do I interview a .NET developer if I am not technical?
Use the owner screening set, which scores explanation, ownership, and honesty instead of syntax. Ask the candidate to show you something live and walk you through the parts they wrote, to explain a recent technical decision as if you know nothing about code, to describe a bug that reached customers and what changed afterward, and to say what they would need from you in their first 30 days. You can judge all of those yourself. Then add two safeguards: a short paid work sample that resembles the real job, and one paid hour from a trusted developer to review a code sample or run a technical round. Structured questions plus a work sample plus one expert hour is a far better process than most small businesses run, and it costs very little.
What are red flags in a .NET developer interview?
The most reliable red flags are operational rather than technical. Watch for a candidate who deploys by copying files onto the server by hand, keeps connection strings or API keys in source control, wrote their own password and login handling instead of using the framework identity system, optimizes by feel with no measurement before or after, has never restored from a backup, or cannot simplify an answer when you ask them to. Behavioral warning signs matter just as much: blaming every previous employer and client, wanting to rewrite your working application before understanding it, and having no plan for what happens when they are unavailable. At a small business, where this person is often your only technical hire, a single point of failure with no documentation is a bigger risk than a gap in framework knowledge.
Should I give a .NET developer a coding test?
Yes, and pay for it. A short work sample that resembles the real job is one of the better predictors available for a developer hire, and it tells you far more than a whiteboard puzzle. Keep it to roughly two to four hours, scope it precisely, agree in advance on what finished means, and pay a fair rate for the time. Then score four things: does it work, is it readable, did they ask good questions before starting, and can they explain their choices afterward. Unpaid multi-day assignments filter for candidates with free time rather than skill, and strong candidates decline them. If you cannot judge the code yourself, this is the natural place to spend one paid hour of a trusted developer's time.
How much does a .NET web developer cost?
Pay depends on scope, experience, local market, and whether you post the role as remote. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), web developers had a median annual wage of $92,650, about $44.54 an hour, with the lowest 10 percent under $48,100 and the highest 10 percent above $162,290. The broader software developers occupation reported a higher median of $135,980 in the same survey, and a .NET role that owns an entire application usually benchmarks between the two. The spread inside each occupation is more than three to one, so the title alone tells you almost nothing. Decide the remote question before you post, because a remote listing competes against national pay expectations rather than local ones.
Is a .NET web developer exempt from overtime?
Often, but not automatically, and the test is about duties and pay rather than the job title. The Fair Labor Standards Act includes a computer employee exemption for workers whose primary duty is systems analysis, program design, or software development, provided they are paid at least the applicable salary threshold or the specified hourly rate for computer employees. A developer who mainly performs help desk work, hardware repair, or data entry does not qualify, regardless of what the offer letter calls them. State law can be stricter than federal law, and some states set higher thresholds. Read the Department of Labor fact sheet on the computer employee exemption, classify based on the actual duties, and confirm your state rules before the first paycheck. This is general information, not legal advice.
What questions are off limits in a developer interview?
Avoid anything that probes characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews have their own proxies for these, so also stay away from asking what year someone graduated, when they first learned to code, which country they are originally from, or whether they can work a schedule that only matters because of a religious observance. You may ask whether the candidate can perform the essential functions of the job and whether they are authorized to work in the United States. Asking the same job-related questions of every candidate, in the same order, scored on the same rubric, is the simplest way to be both fair and consistent. This is general information, not legal advice.
