C# Interview Questions: Practice with Real Questions

A CancellationToken is a lightweight value type that exposes read-only members like IsCancellationRequested and Register. Cancellation is triggered exclusively through its CancellationTokenSource (via Cancel, CancelAfter, or linking), never through the token itself.

An async method that completes without returning a value should return Task (or ValueTask). Callers can await it to know when the work is done. async void is discouraged outside event handlers because it cannot be awaited and makes exception propagation difficult. Thread and int are not valid async return types.

await suspends the enclosing async method at that point and returns control to the caller, allowing the thread to do other work. When the awaited Task completes, the method resumes. It does not block the calling thread, does not create a new thread, and does not auto-cancel on exception.

The await keyword can only be used inside a method marked async. Without the async modifier on the method declaration, the compiler will raise an error (CS4033) when it encounters await. yield, lock, and parallel are unrelated to enabling await.

The List<int> is constructed from a copy of the array's elements, so adding 4 to the list does not change the original array. After Add, list.Count is 4 (three copied elements plus the added one), while numbers.Length remains 3 because arrays have a fixed length and the array itself was never modified. The concatenated string printed is therefore "4 3".

A Task constructed with new Task(...) begins in the Created status. Calling Start() schedules it with the default scheduler, transitioning it to WaitingToRun. When the thread pool picks it up and the delegate begins executing, the status becomes Running. Upon successful completion the status becomes RanToCompletion. These transitions are documented and sequential — the task passes through each state exactly once in this order.

Line 10 (_count++;) is not an atomic operation — it reads _count, adds 1, and writes it back. When multiple tasks execute concurrently, their read-modify-write sequences interleave and lost updates occur, so the final value is often less than 1000. The fix is Interlocked.Increment(ref _count);, which performs the increment as a single atomic hardware-level operation.

Main prints "A" first. It then calls MyMethodAsync(), which prints "C" synchronously. The await Task.CompletedTask does not suspend because the task is already complete — the continuation runs inline, so "D" is printed next and MyMethodAsync returns an already-completed Task. Control returns to Main, whose await also completes synchronously, and "B" is printed last. The full output is: A, C, D, B.

The root bug is on line 6: Dictionary<string, int> provides no thread-safety guarantees. When multiple threads call AddOrUpdate concurrently, the dictionary's internal buckets can be corrupted or it can throw an InvalidOperationException ('Operations that change non-concurrent collections must have exclusive access'). Replacing it with ConcurrentDictionary<string, int> resolves the issue because that type is designed for concurrent reads and writes. Replacing ContainsKey with TryGetValue is wrong because switching to TryGetValue alone does not make the collection thread-safe. The indexer assignment is wrong because atomicity of the indexer assignment is not the core issue — the collection type itself is unsafe for concurrent use. Replacing Add with TryAdd is wrong because the code already guards Add with a ContainsKey check; duplicates are not the primary problem under concurrent access.

CancellationToken.ThrowIfCancellationRequested() checks IsCancellationRequested and, if true, throws an OperationCanceledException. The full type name is System.OperationCanceledException. Note that TaskCanceledException (in System.Threading.Tasks) derives from OperationCanceledException, but ThrowIfCancellationRequested itself throws the base OperationCanceledException, not TaskCanceledException.

CancellationTokenSource.Cancel() initiates cancellation: it sets the source's internal flag so that every CancellationToken it produced reports IsCancellationRequested == true, invokes any registered callbacks, and completes any linked token sources.

CancellationTokenSource.CreateLinkedTokenSource(params CancellationToken[] tokens) creates a source whose token is cancelled when any of the supplied tokens is cancelled. You pass tokenA and tokenB as arguments and then use the .Token property of the returned source.

Marking the lock object readonly guarantees the field reference is fixed for the object's lifetime. If the reference could be reassigned, different threads might lock on different objects and bypass mutual exclusion. The private modifier prevents external callers from locking on the same instance and causing contention or deadlock.

System.Threading.Interlocked exposes static methods that perform hardware-level atomic read-modify-write operations. Using Interlocked.Increment(ref counter) is more efficient than wrapping counter++ in a lock because it avoids a full monitor acquisition and works directly on the memory location.

ConcurrentDictionary<TKey, TValue> uses fine-grained locking (striped locks) internally so that reads are lock-free and writes only lock the relevant bucket. It is the recommended replacement for Dictionary<TKey, TValue> when multiple threads may read and write the collection simultaneously without the caller managing synchronization.

The List<int>(IEnumerable<int>) constructor copies each element from the source array into a new internal backing array, so the list is independent of arr. When arr[0] is set to 99 the list is unaffected. The first WriteLine prints the modified array (99,2,3), and the second prints the list with the appended 4 (1,2,3,4).

Using the indexer to assign dict["apple"] = 3 inserts the key with value 3. The second assignment dict["apple"] = 5 overwrites the existing value because the indexer updates an existing key rather than throwing. dict.Add("banana", 2) adds a second entry, so dict.Count is 2. TryGetValue("cherry", out int val) returns false because "cherry" is not a key in the dictionary, so the else branch prints "not found".

An async void method returns void, so the caller cannot await it or inspect a returned Task (the caller of an async void method has no way to await its completion because the method returns void, not Task is true, an async void method produces a Task object internally that the caller can inspect to track progress is false). async void is the recommended pattern for event handlers precisely because event delegate signatures require a void return type (async void is the recommended signature for event handlers in C# because event delegate signatures return void is true). Exceptions thrown inside an async void method are posted to the ambient SynchronizationContext (or rethrown on the thread pool if none exists), crashing the process if unhandled — they are NOT caught by a try/catch at the call site because the method has already returned void before the exception surfaces (an exception thrown inside an async void method can be caught by a try/catch block that surrounds the call site is false).

ConfigureAwait(false) tells the awaiter to skip capturing the current SynchronizationContext/TaskScheduler, so the continuation is not marshaled back to the original context (the statement that it instructs the awaiter not to capture and post the continuation back to the current SynchronizationContext or TaskScheduler is true). Without the captured context, the continuation runs on whatever thread the task completes on — typically a thread pool thread (the statement that after await task.ConfigureAwait(false), the continuation may execute on a thread pool thread even if a SynchronizationContext was present before the await is true). When a caller on a single-threaded SynchronizationContext (e.g., the WPF UI thread) blocks with .Result, the continuation would need that same thread to run, causing a deadlock; ConfigureAwait(false) breaks this cycle by allowing the continuation to run elsewhere (the statement that it can help prevent deadlocks that arise when a caller blocks on the result while a single-threaded SynchronizationContext is active is true). ConfigureAwait(false) only affects where the continuation runs, not what the task returns — the logical result is unchanged (the claim that it alters the return value or the logical outcome of the awaited Task is false).

The compiler rewrites each async method into a state machine (a struct or class) that tracks the suspension/resumption point after every await (the statement that the compiler transforms the async method into a state machine that records the current position so execution can resume at the correct point after each await is true). When the awaited task's IsCompleted is already true, the awaiter calls GetResult immediately without scheduling a continuation, so execution proceeds synchronously (the statement that when an awaited Task is already completed at the time await is evaluated, the continuation runs synchronously and no continuation is scheduled on the thread pool is true). Task.Delay(0) returns an already-completed task (Task.CompletedTask), so awaiting it completes synchronously and does NOT yield — Task.Yield() is the construct that always yields (the statement that await Task.Delay(0) always yields control back to the caller before continuing is false). Local variables that must survive across an await (like response, which is used on line 4 after the await on lines 2–3) are lifted from the stack into fields on the state machine object, since the original stack frame is gone when the continuation resumes (the statement that local variables that are read or written after an await boundary (such as response above) are hoisted into fields of the generated state machine is true).

This is staff-level internal knowledge: the reverse-order, synchronous, exception-collecting dispatch model of registered callbacks is the reason cancellation can introduce reentrancy and deadlocks if a callback blocks or acquires locks held by the canceling thread. Understanding the throwOnFirstException overload distinguishes surface API familiarity from deep runtime semantics.

The code the compiler emits for every await begins by checking awaiter.IsCompleted. When the task is already finished, control falls straight through to awaiter.GetResult() on the current thread — no OnCompleted/UnsafeOnCompleted callback is registered, and no SynchronizationContext or TaskScheduler is captured or posted to. Context capture only occurs on the suspension path, which is never entered when IsCompleted is true. This is why awaiting an already-completed task inside a UI thread keeps you on the UI thread even without ConfigureAwait(false).

Understanding TryReset requires knowing the internal lifecycle of a CancellationTokenSource — that it is reusable, that prior registrations are cleaned up, and that the internal CancelAfter timer is a separate concern that must be explicitly re-armed. This is well beyond surface-level cancellation API usage and sits at the intersection of performance engineering and async internals.

AsyncVoidMethodBuilder.SetException is called whenever an exception propagates out of the state machine (whether before, during, or after an await). That method checks whether a SynchronizationContext was captured at invocation time; if one exists, it calls Post() to marshal the exception back onto that context, otherwise it calls Environment.FailFast/ThreadPool.QueueUserWorkItem-based rethrow via ThrowAsync. Because async void returns to the caller before the body finishes, the caller's try-catch frame has already unwound by the time the exception surfaces, making it uncatchable by the caller. This is the core reason async void is discouraged outside event-handler contexts.

This is a common pitfall at scale: developers assume CreateLinkedTokenSource is a lightweight composition, but it allocates callback registrations on every source token. Forgetting to dispose the linked source when combining a request-scoped token with a process-wide timeout token means the request-scoped CTS is kept alive (and its internal structures retained) long after the request completes. The reverse direction (linked → original) is never wired, so calling Cancel on the linked source is a local-only operation.