354 .NET Developer Interview Questions & Answers

The LINQ methods I use most often are Where for filtering, Select for projection, OrderBy and ThenBy for sorting, GroupBy for grouping, and methods such as Count, Sum, Average, Min, and Max for aggregation. I also commonly use Any to check whether a match exists and FirstOrDefault when I need the first matching element or a default value. One important practical point is that many LINQ operations on IEnumerable<T> use deferred execution, so they usually run when the sequence is enumerated. Methods such as ToList evaluate the sequence and store the results.

LINQ gives C# developers a simple way to work with groups of values. In everyday code, I may need to keep only certain items, choose parts of each item, put items in order, place related items together, or calculate a count or total. Instead of writing a separate loop for each task, I can combine a few clear operations. The important skill is not memorizing every available operation. It is knowing the small set used often, what result each one produces, and when the work actually happens.

1. Should I focus on LINQ to Objects with IEnumerable<T>?
2. Would you like me to explain deferred execution as well?

For filtering, the everyday method is Where. It returns only elements that satisfy a condition. For example, orders.Where(o => o.Total > 100) represents the orders whose total is greater than 100.

For projection, I use Select. Projection means transforming each input element into the value I want to return. For example, I can select customer names instead of complete customer objects.

For sorting, OrderBy sorts by one key. OrderByDescending sorts in the opposite direction. ThenBy and ThenByDescending add another sorting key when elements have equal values for the earlier key.

For grouping, GroupBy places elements with the same key into groups. A common example is grouping orders by customer or products by category.

For aggregation, Count returns the number of elements. Sum, Average, Min, and Max calculate common summary values. Any is useful when I only need to know whether at least one matching element exists. FirstOrDefault returns the first matching element, or the default value for the element type when there is no match.

An important behavior is that many LINQ methods over IEnumerable<T>, including Where and Select, use deferred execution. Calling them normally creates an enumerable that describes the work. The source is read later when that result is enumerated. This matters because changes to the source before enumeration can affect the result, and enumerating the same query again can repeat the work.

Methods such as ToList and ToArray enumerate the source immediately and store the resulting elements. This uses additional memory but gives the caller a materialized result that can be reused without rerunning the earlier query operations.

In production code, I prefer short LINQ chains that clearly express filtering, projection, ordering, grouping, or aggregation. I avoid unnecessary materialization and repeated enumeration, especially when reading the source is expensive.

A common mistake is assuming that every LINQ method executes immediately. Many sequence producing methods over IEnumerable<T> use deferred execution. Another mistake is using Count when the real question is only whether at least one matching element exists. Any expresses that intention directly and can stop after finding a match. Developers also sometimes call ToList too early, which performs enumeration and allocates a new list even when materialization is unnecessary. Repeatedly enumerating the same deferred query can repeat its work. First and Single are also commonly confused. First returns the first matching element and allows more matches to exist. Single requires exactly one matching element and throws if there are zero or multiple matches. FirstOrDefault allows no match and returns the default value in that case.

Organize the answer by purpose instead of trying to name every LINQ method. Explain Where for filtering, Select for projection, OrderBy for sorting, GroupBy for grouping, and methods such as Count or Sum for aggregation. Then mention Any, FirstOrDefault, deferred execution, and materialization to show that you understand how LINQ behaves in real C# code.

Extension methods let me call a static helper method using instance style syntax without modifying the original type. I declare the method in a static class and put this before its first parameter, which is the receiver. The compiler finds the method at compile time and passes the receiver as that first argument. An applicable real instance method takes priority, so extension methods do not override instance members.

Extension methods let us place a useful operation beside a type even when we cannot or should not change that type. They make calling code easier to read because a helper operation can appear directly after the value it works with. For example, a text value can be followed by a custom operation that checks whether it contains useful content. This does not actually add a new member to the original type. It gives the caller a cleaner way to invoke a separate helper function. This is useful when building readable libraries and shared application code.

1. Should I explain how C# chooses between an instance method and an extension method?
2. Would you like a small example showing the required static method shape?

An extension method is a static C# method that can be called using instance style syntax. In the traditional syntax, the method is declared inside a static class. Its first parameter identifies the receiver type and uses the this modifier.

For example, public static bool HasText(this string? value) can be called as name.HasText(). The value stored in name is supplied as the first argument to the static method. The string type itself is not modified and no new instance member is added to it.

The compiler resolves extension method calls at compile time. It first considers normal instance members. If an applicable instance method is available for the call, that instance method is used instead. Extension methods therefore do not override existing instance methods and do not become virtual members of the receiver type.

The extension method must also be in scope, normally through its containing namespace. It follows normal accessibility rules, so it cannot access private members merely because it is written with extension syntax.

Extension methods are useful for API ergonomics because related operations can read naturally at the call site. LINQ is a common example because operations such as Where and Select are exposed as extension methods for compatible sequence types.

A null receiver can still be passed to an extension method because the method is static. The method body must decide whether null is valid and handle it safely. Extension syntax itself does not require a special allocation. Runtime cost, allocations, and memory use depend on what the method body actually does.

A common mistake is saying that an extension method actually adds a member to the original type. It does not. Another mistake is forgetting that the traditional extension method must be static, its containing class must be static, and its first parameter must use the this modifier. Candidates may also assume extension methods override instance methods, but an applicable instance method takes priority. Another mistake is believing extension methods can access private members of the receiver. They follow normal accessibility rules. It is also easy to forget that the extension method must be in scope. Finally, extension syntax can make expensive or surprising work look simple, so production APIs should avoid hiding such behavior behind innocent looking method names.

Start with the required shape: a static method in a static class with this on the first parameter. Then explain that the receiver is passed to that static method and the original type is not changed. Mention compile time resolution, instance method priority, and one practical use such as LINQ. That gives a concise answer while still showing the important language rules.

Tuples in C# let me group a fixed number of values into one value without creating a separate custom type. I can name the elements, such as Name and Age, or leave them unnamed and access them as Item1 and Item2. Modern C# tuple syntax uses ValueTuple types, which are value types, and element names are not part of the tuple type identity. I use tuples for small temporary results, especially when returning several related values. For an important domain concept, public contract, or data that needs behavior or validation, I prefer a custom type.

A tuple is a simple way to keep a few related pieces of information together. For example, a method may need to return a person's name and age at the same time. Instead of creating a new type only for those two values, C# can place them together in one value. The parts can have useful names, or they can use default numbered names. Tuples work best when the group is small and its meaning is clear. For important data that is reused widely or represents a real business concept, a dedicated type usually communicates the purpose better.

1. Are you asking about modern C# value tuples or the older Tuple classes?
2. Should I also explain when a custom record, class, or struct is a better choice?

Modern C# tuple syntax normally represents a System.ValueTuple value. For example, (string Name, int Age) describes a tuple containing two elements. Its important type shape comes from the number, order, and types of those elements. The names improve readability, but they are not part of the tuple type identity. The underlying ValueTuple exposes fields such as Item1 and Item2.

An unnamed tuple such as (string, int) has the same element types and positions. Code can access its values through Item1 and Item2. A named tuple allows clearer source code such as result.Name and result.Age. C# also supports deconstruction, which lets the elements be assigned into separate variables.

ValueTuple is a value type. Assigning one tuple variable to another copies the tuple fields. If an element is a reference type, the reference is copied, not the object it points to. Two copied tuples can therefore still refer to the same mutable object.

Tuple equality compares corresponding element values using the equality behavior available for those element types. Element names do not affect equality. For example, tuples with the same compatible element types can be compared even if their source level element names differ.

Creating a local ValueTuple does not by itself require a separate heap object because ValueTuple is a value type. Its actual storage depends on where the value is used. Boxing it as object or through an interface can create a heap allocation. Copying a very large tuple also copies all of its fields, so large tuples can have a greater copying cost.

Tuples are useful for small local results, private helper methods, temporary transformations, and methods that naturally return several related values. A custom class, struct, or record is usually better when the data represents a real domain concept, is reused widely, requires validation or behavior, needs clear member documentation, or forms a stable public contract.

A common mistake is assuming that named tuple elements create a new custom type. They do not, and the element names are not part of tuple type identity. Another mistake is thinking that copying a tuple performs a deep copy. ValueTuple is copied by value, but reference type elements still point to the same referenced objects after the copy. Developers may also assume that a value tuple can never allocate. Boxing a ValueTuple as object or through an interface can create a heap allocation. Another mistake is overusing tuples in public APIs or domain models where a named type would communicate meaning and future changes more clearly. Developers should also avoid confusing modern ValueTuple based tuple syntax with the older System.Tuple reference types.

Start by saying that a tuple groups a fixed set of values without requiring a new custom type. Then distinguish named elements from Item1 style unnamed elements. Explain that modern tuples use ValueTuple, that element names are not part of tuple type identity, and that copying a tuple copies its fields. Finish with the design rule: use tuples for small temporary results and use a custom type for meaningful, reusable, or public domain data.

Pattern matching in C# lets me test a value and branch based on its type, a constant value, or another supported pattern. A type pattern such as value is string text checks that the value is a non null string and gives me text without a separate cast. A constant pattern can test values such as null or 0. I use pattern matching when it makes the decision and the value I need clear in the same expression.

Pattern matching in C# is a way to inspect a value and decide what should happen next. It can check what kind of value was received, whether it is a specific constant such as zero, or whether it is null. When a match succeeds, C# can also give the matching value a useful name for that branch. This reduces separate checks and conversions and can make decision code easier to read. It is useful when one input can represent several cases and each case needs different handling.

1. Should I focus on type patterns and constant patterns?
2. Would you like an example using a switch expression?

In C#, a pattern is a test that is applied to an input value. Pattern matching is commonly used with is, switch statements, and switch expressions.

A type pattern checks whether a non null value is compatible with a specified type. For example, value is string text succeeds when the runtime value can be treated as a string. When it succeeds, text is available as a string inside the valid scope, so a separate cast is not needed. A null value does not match a normal type pattern.

A constant pattern tests whether the input matches a permitted constant value. Examples include value is null and number is 0. The null constant pattern is especially useful because its null test does not call an overloaded equality operator.

Switch expressions can combine several patterns. C# considers the arms in source order and uses the first arm whose pattern matches and whose optional guard succeeds. This makes order important when patterns can overlap.

Pattern matching itself does not mean that a new object is created. For a reference type pattern, the pattern variable refers to the same existing object. If a boxed value type is matched from an object, the match can unbox the value and copy that value into the pattern variable. Any boxing happened when the value was converted to object, not because the type pattern later tested it.

In production code, simple patterns usually have costs similar to the type tests, null checks, and comparisons they express. The main reason to use them is clearer branching. Very complex or deeply nested patterns can reduce readability and should be simplified when ordinary conditions communicate the rule better.

A common mistake is thinking that a type pattern needs a separate cast after it succeeds. The pattern variable already has the matched type. Another mistake is expecting value is string text to match null. A normal type pattern does not match null. Developers may also assume that every expression can be used as a constant pattern, but a constant pattern requires a permitted constant expression. Another mistake is ignoring switch arm order when patterns overlap. Finally, pattern matching can become harder to read when too many conditions are combined into one complex pattern.

Start by saying that pattern matching combines a test with branching and can also give you the matched value. Then show value is string text as a type pattern and value is null as a constant pattern. Mention that null does not match a normal type pattern, that no separate cast is needed after a successful type pattern, and that switch arm order matters when patterns can overlap.

Thread synchronization controls access to shared mutable data when several threads can use it at the same time. In C#, lock allows only one thread at a time to execute the protected code for the same lock instance. Other threads that try to use that same lock must wait. For a .NET 8 and C# 12 example, I would normally use a private readonly object and keep the protected section as small as possible.

When a program has several pieces of work running at the same time, two of them may try to change the same information together. Their actions can overlap, and the final value can become wrong. This question asks how C# prevents that problem. The lock statement marks a small section that only one competing piece of work can use at a time when they all use the same guard. Others wait until it is free. This matters when shared information can be changed from more than one place at once.

1. Is the shared data accessed by multiple threads inside the same process?
2. Should I show the example using a private lock object and a shared counter?

A race condition can happen when two threads read and change the same mutable value at nearly the same time. For example, counter++ is not guaranteed to act as one indivisible shared memory operation. Two threads can read the same old value and an update can be lost.

In the .NET 8 with C# 12 example below, lock uses the same ordinary object named gate for every protected access. For an ordinary reference type lock target, the compiler uses Monitor enter and exit behavior. Only one thread can own that monitor at a time. A competing thread waits until it can enter. The compiler also arranges exception safe cleanup so the monitor is released when control leaves the lock body, including when an exception is thrown.

The same lock instance must guard all accesses that depend on this protection. Locking different objects does not coordinate those operations. Entering and leaving the same lock also provides the memory synchronization needed so changes made by one thread before it releases the lock are visible to a thread that later acquires that lock.

Modern C# also has special language support when the lock expression is statically known to be System.Threading.Lock. In that case the compiler uses its scope based locking API instead of Monitor. This is a newer behavior than the C# 12 example below, so the two forms should not be described as the same compiler expansion.

Use lock for short synchronous critical sections that protect shared mutable state inside one process. Keep the section small because competing threads may wait. Avoid slow network, file, or database work while holding the lock. C# does not allow await inside the body of a lock statement. Also remember that lock does not coordinate separate processes or service replicas.

A common mistake is locking different objects for operations that are supposed to protect the same state. Those locks do not coordinate with each other. Another mistake is locking a publicly accessible object, this, a Type object, or an interned string because unrelated code may also lock it and create unexpected blocking. Developers may also hold a lock while doing slow work, which increases contention and reduces throughput. Another mistake is assuming lock coordinates separate processes or service replicas. It only coordinates code that uses the same lock instance in shared process memory. It is also incorrect to assume counter++ is automatically safe when several threads update the same counter.

Start with the race condition problem. Then explain that lock gives one thread at a time access to a critical section when every participant uses the same lock instance. Mention a private readonly gate for the C# 12 example, explain that competing threads wait, and finish by saying the protected section should stay small.

ExecutionContext carries ambient execution state across asynchronous boundaries, even when work resumes on a different thread. It lets values such as AsyncLocal state and culture follow the logical operation instead of being tied to one thread. In practice, this makes request specific or operation specific context available after await and during queued work. It has a cost because context may be captured and restored, so I would avoid putting large or frequently changing objects into flowed ambient state. I would also distinguish it from SynchronizationContext, which is about where work runs, not what ambient state it sees.

The question is asking how .NET remembers information that belongs to an operation while that operation is running. An operation can pause, continue later, and even continue somewhere else. The important idea is that the information should still be available when the work continues. This is useful for things such as language settings and values that describe the current operation. The interviewer may clarify whether they want the behavior of async and await, AsyncLocal, context suppression, or the difference between execution state and scheduling.

1. Are you asking about async and await behavior or manual context APIs?
2. Should I focus on AsyncLocal and performance costs?
3. Should I compare ExecutionContext with SynchronizationContext?

ExecutionContext is the mechanism .NET uses to carry ambient state with the logical flow of an operation. The important point is that the logical operation is not the same thing as a physical thread. A method can start on one thread, reach an await, and continue on another thread. ExecutionContext lets relevant ambient state be restored for that continuation.

A common example is AsyncLocal<T>. If code stores a value in an AsyncLocal<T>, that value flows with the logical execution context through normal asynchronous operations. This is why operation specific information can remain available after an await without using ordinary thread local storage. Culture information can also flow with execution context.

Task based and ThreadPool APIs normally capture the current ExecutionContext when work is queued. The captured context is then used when the work runs. This is why ambient state can follow the logical operation even when the physical thread changes.

The runtime captures and restores execution context as part of supported asynchronous and queued work mechanisms. That work has overhead. The exact cost depends on the state being flowed and whether it needs to be captured or changed. Large mutable objects are a poor choice for ambient state because they can keep data reachable and make behavior harder to reason about.

ExecutionContext.SuppressFlow can prevent execution context from flowing into work that is queued while suppression is active. This is an advanced optimization and correctness tool. It should be used carefully because the queued code will not automatically see the caller's flowed ambient state.

ExecutionContext is different from SynchronizationContext. ExecutionContext answers what ambient state the operation should see. SynchronizationContext is concerned with where a continuation is posted. ConfigureAwait(false) affects SynchronizationContext capture for Task based await. It does not by itself stop ExecutionContext from flowing.

In production, I would normally rely on the default behavior and use AsyncLocal<T> only for small, well understood ambient values. If I suspect a problem, I would inspect the state across asynchronous boundaries and test context suppression separately so I can confirm exactly which state is expected to flow.

A common mistake is saying that ExecutionContext is the same as SynchronizationContext. They have different jobs. ExecutionContext carries ambient execution state. SynchronizationContext represents where work is posted. Another mistake is saying that async and await always keep the same thread. They do not. Execution can resume on another thread while the relevant execution context flows. It is also incorrect to think ConfigureAwait(false) disables ExecutionContext flow. ConfigureAwait(false) controls captured SynchronizationContext behavior for Task based await. Another mistake is treating AsyncLocal as free thread local storage. Flowing context can have overhead, and large or mutable values can make memory retention and behavior harder to understand. Finally, suppressing flow casually can cause downstream code to lose state that it expects to be present. A suppression scope should not be held across an await because its restoration is tied to the flow control operation.

Start with the practical rule: ExecutionContext carries ambient state with the logical operation, not with a specific thread. Then use AsyncLocal<T> as the concrete example. Explain that normal asynchronous flow preserves the value across await, while SuppressFlow prevents propagation into newly queued work. Finish by separating ExecutionContext from SynchronizationContext and mentioning the capture and restoration cost.

Dependency injection in ASP.NET Core means a class receives the services it needs instead of creating those services itself. I normally register services with the built in container and request required dependencies through constructor parameters. When the framework creates the class, the container resolves those dependencies and builds the object graph. This reduces coupling, makes implementations easier to replace and test, and lets the container manage transient, scoped, and singleton lifetimes.

The practical idea is simple. A part of an application often needs help from other parts to do its work. Instead of creating those helpers itself, it receives them from the application. For example, an order handler may need something that stores orders and something that sends messages. The application can provide both when it creates the handler. This keeps the handler focused on its own job. It also makes testing easier because test versions of those helpers can be supplied without changing the handler itself.

1. Would you like me to explain the service lifetimes as well?
2. Should I also explain lifetime validation and scoped services?

Dependency injection in ASP.NET Core is the framework pattern where required services are supplied to a class through the built in service container instead of being created directly inside that class. Services are normally registered during application startup by specifying a service type, an implementation, and a lifetime.

Constructor injection is common because the constructor clearly shows what an object requires before it can do its work. When ASP.NET Core asks the container to create an object, the container finds a public constructor it can satisfy using registered services and other supported values. It then resolves those dependencies recursively and creates the object graph. If no suitable constructor can be satisfied, resolution fails. If constructor selection is ambiguous, resolution also fails rather than choosing an arbitrary constructor.

The three common lifetimes are transient, scoped, and singleton. A transient registration normally produces a new instance each time that service is resolved. A scoped registration reuses one instance within a scope. In a typical ASP.NET Core web request, the framework creates a request scope, so a scoped service is reused within that request. A singleton registration reuses one instance from the root service provider after that singleton is first created.

DI solves tight coupling because a class can depend on a service contract rather than constructing a particular implementation. This makes implementations easier to replace, makes tests easier to isolate, and centralizes lifetime management.

A major production rule is lifetime compatibility. A singleton should not directly capture a scoped service because the scoped instance could then live much longer than its intended scope. If a singleton truly needs scoped work, it can create a scope for that unit of work and resolve the scoped dependency inside that scope. Constructors should also avoid expensive work because service creation can occur on application request paths.

Common mistakes include treating dependency injection as only a testing technique, creating dependencies manually inside classes that should receive them, assuming every service resolution creates a new instance, storing request specific mutable state in a singleton, directly injecting a scoped service into a singleton, performing expensive work in constructors, and using the service provider throughout application code as a service locator instead of declaring normal dependencies. Another mistake is assuming the container can create a type when its required constructor dependencies are unavailable or when constructor selection is ambiguous.

Start by saying that a class receives its dependencies instead of creating them. Then explain service registration, constructor injection, container resolution, and the three lifetimes. Finish with the main benefit, which is lower coupling, and mention the important production rule that a singleton must not directly capture a scoped service.

The Generic Host is the common .NET foundation that starts, runs, and stops an application while managing configuration, logging, dependency injection, and hosted services. A web app and a worker service use the same hosting model because both need those services. The main difference is their workload. A web app adds ASP.NET Core request processing and an HTTP server, while a worker service mainly runs background hosted services.

The practical idea is simple. Different kinds of programs still need the same basic support around their main work. They need settings, logs that show what is happening, shared objects, startup steps, and a clean way to stop. One program may answer requests from users, while another may keep running and process jobs in the background. .NET gives both programs one common foundation for these shared responsibilities. This avoids creating separate ways to manage the same basic needs and lets each program add only the work that makes it different.

1. Are you asking about the modern ASP.NET Core hosting model?
2. Should I also compare how hosted background services run in each application type?

The Generic Host is the .NET hosting foundation responsible for application startup, lifetime management, and common infrastructure. It brings together configuration, logging, dependency injection, application shutdown, and registered IHostedService implementations. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dotnet/core/extensions/generic-host?utm_source=chatgpt.com))

A modern worker service commonly creates a HostApplicationBuilder with Host.CreateApplicationBuilder, registers application dependencies and one or more hosted services, builds the host, and runs it. When the host starts, it calls StartAsync on registered IHostedService implementations. A BackgroundService is an IHostedService whose ExecuteAsync method represents its background operation. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dotnet/core/extensions/generic-host?utm_source=chatgpt.com))

A modern ASP.NET Core web application uses the same Generic Host foundation through its web hosting model. WebApplicationBuilder adds the ASP.NET Core services needed for web work. The application then adds routing, middleware, endpoints, and an HTTP server. The server is therefore not the Generic Host itself. It is part of the web workload that runs under the host. Microsoft also treats WebApplicationBuilder and the Generic Host based model as the modern direction for ASP.NET Core. ([learn.microsoft.com](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/generic-host?view=aspnetcore-10.0&utm_source=chatgpt.com))

This shared model matters because both application shapes can use the same configuration, logging, dependency injection, lifetime management, and hosted service infrastructure. A web application can also register BackgroundService implementations when it has background work that belongs in the same process.

The main limitation is that sharing a host does not make the workloads identical. A web app is normally driven by HTTP requests. A worker is normally driven by queues, timers, polling, or other background work. Hosted services should observe cancellation and finish promptly during shutdown. A BackgroundService that does not finish after cancellation can prevent graceful shutdown from completing within the allowed shutdown period. ([learn.microsoft.com](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-10.0&utm_source=chatgpt.com))

A common mistake is saying that the Generic Host is the web server. It is not. The host manages application infrastructure and lifetime, while a web application adds its HTTP server and request pipeline. Another mistake is thinking that hosted services belong only to worker projects. A web application can also register IHostedService or BackgroundService implementations. Candidates also sometimes assume that a worker and a web app behave the same because they share a host. Their hosting foundation is shared, but their main workloads are different. Another production mistake is ignoring cancellation in a hosted service, which can prevent graceful shutdown from completing promptly.

Start by saying that the Generic Host owns the common application infrastructure and lifetime. Then name configuration, logging, dependency injection, and hosted services. Finish by contrasting the workloads. A web app adds HTTP request processing, while a worker service mainly runs background work.

C# passes arguments by value by default. ref and out let the callee change the caller variable, while in gives a read only view for large values. The main point is that each form changes who can modify the data and when that change is visible.

This question asks how a method in C# receives data and what changes the method can make visible to the caller. The main idea is simple: sometimes the method gets its own copy, and sometimes it works with the caller's variable directly. That choice affects whether the method can change the value, whether a result must be assigned, and whether copying can be avoided for large values. The interviewer wants to see that you know the four common forms and when each one is useful.

1. Do you want a practical example with TryParse or swapping values?
2. Should I focus more on safety or performance?

By default, C# passes arguments by value. That means the method gets its own copy. For a value type, the value itself is copied. For a reference type, the reference is copied, not the object. So the method can change the object through the copied reference, but it cannot change which object the caller variable points to.

Use ref when the method must read and write the caller variable. The caller must assign the variable first, and the method can replace its value. Use out when the method must produce an extra value, such as TryParse. The caller does not need to assign the variable first, but the method must assign it before return. Use in when you want to avoid copying a large value type and also prevent the method from changing the argument.

The main tradeoff is control versus simplicity. Value parameters are easiest and safest. ref and out make changes visible outside the method, but they make the call harder to reason about. in is useful for large readonly structs, but it adds restrictions and is not needed for small values.

A common mistake is thinking ref and out are the same as passing a object by reference in every case. Another mistake is forgetting that out must be assigned before the method returns. People also often forget that value parameters copy the reference for classes, not the whole object. Another error is using in for small values where the extra restriction is not worth it.

Start with the default rule first, then compare ref, out, and in in that order. End with one simple example such as TryParse or swapping two values so the difference is easy to remember.

The main difference is what each operator gives me. is checks whether a value is compatible with a type and produces a Boolean result, or can use pattern matching to test and bind a typed value. as attempts a compatible reference conversion or nullable value conversion and produces the converted value, or null when the conversion is not possible. I use is when I need a type test or pattern match. I use as when I need the value and null is an acceptable failure result. An explicit cast is different because an incompatible cast throws InvalidCastException.

This question is asking how C# checks whether one value can be treated as another type. It also asks what each operator gives back when the type matches and what happens when it does not. The important point is that the two operators have different jobs. is answers a type check. as tries to give you the value in the requested type. Knowing that difference helps you choose the safer and clearer option in real code.

1. Should the example focus on reference types or also include nullable value types?
2. Do you want the answer to include modern is pattern matching?

is is used for a type test. For example, value is string returns true when the runtime value is compatible with string, and false otherwise. Modern C# also lets me combine the check with pattern matching, such as if (value is string text), which both tests the type and gives me the typed variable.

as is used when I want the converted value instead of a Boolean result. For example, string? text = value as string; gives me a string reference when the value is compatible with string. When the reference conversion is not possible, the result is null instead of an exception. That means I need to handle the null result before using it.

as can also be used with nullable value types, such as int?, but not with a nonnullable value type such as int. This is an important limitation.

An explicit cast, such as (string)value, has different behavior. If the runtime value is not compatible with string, the cast throws InvalidCastException. So I do not treat as as simply another spelling of a cast. The choice depends on intent. Use is when the decision is based on the type. Use as when obtaining the typed value with a null result is useful. In modern C#, is pattern matching is often the clearest choice when I need both the type test and the typed value.

A common mistake is saying that is converts the value. It does not. It tests runtime type compatibility and returns a Boolean result or performs pattern matching. Another mistake is saying that as throws when the types do not match. For supported conversions, as returns null instead. Candidates also forget that as cannot target a nonnullable value type such as int, although it can target a nullable value type such as int?. Another mistake is writing if (value is string) { var text = (string)value; } when an is pattern can test and bind the value in one step. Finally, candidates can incorrectly assume that as is always preferable to an explicit cast. When incompatible data represents a programming error and exception behavior is intentional, an explicit cast may be appropriate.

Start with the result each operator produces. Say that is performs a type test or pattern match, while as attempts a supported conversion and returns the typed value or null. Then mention the key limitation that as cannot target a nonnullable value type and contrast both with an explicit cast, which throws InvalidCastException for an incompatible runtime type.