How to assess · For hiring teams
How to Assess C# / .NET Skills When Hiring
The test formats that actually work for C# / .NET, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess C# / .NET with a task, not a conversation: fix a slow, hanging api, build a small api with a constraint, ai-scored assessment (e.g. cohesyve) or code review of a pull request. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Writes async code end to end: no `.Result` or `.Wait()`, `ConfigureAwait` understood, cancellation tokens passed through
- Reads the SQL Entity Framework generates and knows when to project, include, or drop to raw SQL
- Understands DI lifetimes — singleton, scoped, transient — and the captive-dependency mistake
- Uses records, pattern matching and nullable reference types to make code safer, not just newer
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
C# and .NET power a large share of enterprise backends, and the hiring problem is that the ecosystem is big enough for a candidate to be strong in one corner and weak in the ones your product uses. Someone who has built ASP.NET Core APIs for years may never have reasoned about async deadlocks, Entity Framework query performance or dependency injection lifetimes — the three things that cause most .NET production trouble. This page covers how to assess C# and .NET as it is used in modern backend work: async correctness, data access, DI and configuration, testing, and the judgement to keep an enterprise codebase maintainable.
Why C# / .NET is worth testing
.NET failures are rarely dramatic. They are a slow endpoint that turns out to be an N+1 query, a service that hangs under load because of a blocking call on async code, a singleton that holds a scoped dependency and leaks. Each one is a mistake a strong developer stops making early and a weak one keeps making. Testing surfaces the difference in an hour, before the codebase accumulates it.
What strong C# / .NET looks like
- Writes async code end to end: no `.Result` or `.Wait()`, `ConfigureAwait` understood, cancellation tokens passed through
- Reads the SQL Entity Framework generates and knows when to project, include, or drop to raw SQL
- Understands DI lifetimes — singleton, scoped, transient — and the captive-dependency mistake
- Uses records, pattern matching and nullable reference types to make code safer, not just newer
- Structures solutions so that domain logic does not depend on the web framework
- Writes unit tests against interfaces and integration tests against a real database
- Configures logging, health checks and options binding as part of the service, not afterwards
Ways to assess C# / .NET
Fix a slow, hanging API
Provide a small ASP.NET Core project with an N+1 query, a blocking `.Result` in an async path, and a scoped service injected into a singleton. Ask the candidate to find and fix all three and explain the impact of each.
Pros
Cons
Best for Mid and senior backend roles.
Build a small API with a constraint
Ask for an endpoint with validation, persistence and a background job, using the stack you use. Two to three hours capped.
Pros
Cons
Best for Roles building services from scratch.
AI-scored assessment (e.g. Cohesyve)
Generate a .NET task from the job description — a debugging scenario, a data-access review, a DI design question — with a rubric. Each candidate receives a different variant; reasoning is scored with the code.
Pros
Cons
Best for Screening a large pool.
Code review of a pull request
Give a diff with sync-over-async, a missing cancellation token, a leaky abstraction and an untested branch. Ask for review comments.
Pros
Cons
Best for Senior and lead developers.
Cohesyve
Run a C# / .NET assessment on your next opening
Cohesyve generates a unique C# / .NET task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Async correctness
Whether async code is actually asynchronous and safe.
Data access
Whether they know what the ORM is doing.
Dependency injection and structure
Whether the application is composed correctly.
Testing and operations
Whether the service is verifiable and observable.
Sample C# / .NET questions
What happens when you call `.Result` on a task inside an ASP.NET Core request?
EntryLook for Thread-pool starvation and deadlock risk in some contexts; the answer is to await all the way up.
What is the difference between scoped and transient lifetimes, and where would each go wrong?
EntryLook for Per-request versus per-resolve; a DbContext should be scoped; a scoped service in a singleton is captured.
This endpoint loads orders and then each order's customer in a loop. What does the database see, and how do you fix it?
MidLook for N+1; use `Include` or a projection; considers whether all the data is needed.
How would you structure a solution so the domain does not depend on ASP.NET?
MidLook for Separate projects, interfaces owned by the domain, adapters at the edge; pragmatism about how far to go for the size of the app.
A background service occasionally stops processing with no error. How do you find out why?
SeniorLook for Unobserved exceptions, swallowed cancellation, a blocked thread; adds logging and health reporting to the service.
Red flags
- Uses `.Result` or `.Wait()` in request paths
- Cannot describe what SQL a LINQ query produces
- Registers everything as singleton or everything as transient without reasons
- Puts business logic in controllers
- Has not written an integration test against a real database
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Async correctness | 25% | Fully asynchronous, cancellable, no blocking. |
| Data access | 25% | Queries are efficient and understood. |
| Structure and DI | 20% | Lifetimes are correct; domain is independent of the framework. |
| Testing | 20% | Unit and integration tests exist and are meaningful. |
| Operations | 10% | Logging, health and configuration are designed in. |
Mistakes hiring teams make
- Testing language trivia (delegates, boxing) instead of the defects that reach production
- Not including a data-access review — it is where most slowness comes from
- Accepting a working API that has no tests
- Confusing familiarity with the latest C# syntax with engineering judgement
- Skipping DI lifetimes because "the framework handles it"
Roles that need C# / .NET
Common questions
Should I test .NET Framework or .NET Core?
Whatever the role runs. Modern .NET is the default; if you are maintaining a Framework codebase, say so and test the migration awareness too.
What is the most common .NET production defect?
Inefficient data access — usually an N+1 — followed by sync-over-async. Both are easy to plant in a small project and easy to score.
How long should a C# assessment take?
Forty-five to sixty minutes for a debugging exercise; two to three hours capped for a small API. Longer take-homes lose strong candidates.
Do I need to test Entity Framework specifically?
If the role uses it, yes. Knowing what the ORM generates is the difference between a fast service and a slow one, and it is not visible on a résumé.
Cohesyve · Skill assessments for hiring
Test C# / .NET before the first interview
Generate a role-specific C# / .NET assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog