C# Interview Questions I Actually Ask Junior Developers (With Good Answers)

I've sat on a fair number of interview panels for junior .NET roles, and I can tell you the internet's "Top 100 C# Interview Questions" lists are mostly noise — trivia nobody senior actually asks, because trivia doesn't predict whether you can do the job. What we're really probing is: do you understand what your code does, can you reason aloud, and are you honest about what you don't know?

Here are questions I genuinely ask, what each one is really testing, and what strong junior answers sound like. (Not memorized scripts — interviewers smell those. Understand the ideas.)

1. "What's the difference between a class and a struct? When would you actually use a struct?"

What it tests: whether you understand memory semantics beyond syntax.

A strong answer: A class is a reference type — variables hold a reference, assignment shares the same object. A struct is a value type — assignment copies the whole thing. So mutating a class instance through one variable is visible through another; with a struct it isn't. Structs suit small, immutable values (a point, a money amount); classes suit entities and anything bigger or shared.

The follow-up I'll ask: "So what happens if I put a struct in a List and modify the element I got back?" If you can reason that you modified a copy, you actually understand it. Saying "structs are faster" without the copying caveat tells me you've read a listicle.

2. "Walk me through what happens when this code runs" (the null/reference reasoning question)

csharp
var a = new List<int> { 1, 2, 3 };
var b = a;
b.Add(4);
Console.WriteLine(a.Count);  // ?

string s = null;
Console.WriteLine(s.Length); // ?

What it tests: can you execute code in your head — the core debugging skill.

Strong answer: a.Count is 4, because a and b reference the same list. The second block throws a NullReferenceException — and bonus points if you mention nullable reference types (string?) exist to catch exactly this at compile time. I care far more about your confident step-by-step reasoning than speed.

3. "What does async/await actually do? Why not just call the method normally?"

What it tests: modern C# literacy — every codebase you'll join is full of async.

Strong answer at junior level: await lets the thread do other work while an I/O operation (database call, HTTP request) is in flight, instead of blocking. In a web app that means the server handles other requests in the meantime. async marks the method so the compiler can rewrite it to resume after the await.

You do not need state-machine internals at junior level. You do need to not say "it makes the code run faster" (it doesn't speed the operation, it frees the waiting thread) — and knowing that .Result can deadlock and is a smell earns real credit.

4. "Here's a method — how would you test it? What cases matter?"

csharp
public decimal ApplyDiscount(decimal price, int customerYears)
{
    if (price < 0) throw new ArgumentException("...");
    if (customerYears >= 5) return price * 0.90m;
    if (customerYears >= 2) return price * 0.95m;
    return price;
}

What it tests: testing instinct and boundary thinking — the strongest signal in the whole interview, in my experience.

Strong answer: name the boundaries: years = 0, 1, 2 (edge!), 4, 5 (edge!), 6; price = 0, negative (expect the exception), a normal value. Mention you'd use one test per behavior with clear names, or a parameterized test. Candidates who ask "what should happen at exactly 2 years — is 5% right?" get a mental gold star: questioning the spec is a professional habit.

5. "What's the difference between IEnumerable, List, and IQueryable as return types?"

What it tests: LINQ-era fundamentals and API-design awareness.

Strong answer: List is a concrete, materialized collection. IEnumerable is a sequence you can iterate — possibly lazily, so it might execute work each time you enumerate. IQueryable represents a query that hasn't run yet, typically translated to SQL by EF Core — so filtering on it happens in the database, while filtering an IEnumerable happens in memory. Knowing that difference — where the work executes — is exactly the kind of understanding that separates "wrote some LINQ" from "understands their ORM."

6. "Tell me about something you built. What was the hardest part?"

What it tests: everything, honestly. This is the most predictive question we ask.

Strong candidates talk about their own decisions — "I chose X, it broke when Y, so I changed to Z" — with specifics only someone who did the work would know. Weak candidates describe the tutorial they followed. Prepare for this: pick your best project, and be ready to discuss its data model, its ugliest bug, and what you'd redo. If you can't discuss your portfolio in depth, the portfolio counts against you.

7. "You get a bug report: the order total is wrong, sometimes. What do you do?"

What it tests: debugging methodology and temperament.

Strong answer shape: reproduce it first (get the failing example — "sometimes" means find what varies); isolate (which layer — display, calculation, data?); read the actual code and check assumptions with a debugger or logging; fix; add a test that would have caught it; check whether the same bug pattern exists elsewhere. Nobody expects the right guess — we're watching for a system instead of flailing, and for the words "write a test" appearing unprompted.

What we're really deciding

After the loop, the panel discussion is never "did they know all the trivia." It's: Did they reason clearly? Were they honest when stuck? ("I don't know, but here's how I'd find out" is a great junior answer — bluffing is an instant red flag.) Could we stand to pair with them daily? Will they grow? Prepare accordingly: fundamentals until you can explain them to a friend, your own projects until you can defend every decision, and the honest "I'd look it up like this" for everything else.

That's genuinely the whole game. Good luck — and remember the interviewer wants you to succeed; hiring you solves their problem too.

Where to go next