C# for Coding Interviews: The Collections That Win and the Traps That Don't

If you write C# at work, using C# in interviews is the obvious call. Switching to Python loses the fluency that actually matters and gains you nothing except the vague comfort of shorter syntax. The standard library covers every pattern you'll face, and .NET 6 finally shipped a real PriorityQueue. What C# does have are a handful of sharp edges that stay invisible until the clock is running and someone is watching your screen. This guide is the cheat sheet for those.

Should You Use C# for Coding Interviews?

Most platforms (LeetCode, HackerRank, CoderPad) support C# with .NET 6 or later. PriorityQueue<TElement, TPriority> is available. Check the runtime version before your first session. If the platform is stuck on .NET 5, you'll need to roll your own heap or lean on SortedSet as a workaround.

C# is the right call if you work in it daily. The fluency advantage outweighs any syntactic overhead. The weak spots vs Python: no arbitrary-precision integers by default, less ergonomic tuple unpacking, and LINQ has invisible performance traps if you reach for it without thinking. For a broader comparison, see Best Language for Coding Interviews.

The Collection Cheat Sheet

Need	Use	Backing	Key ops
Resizable array	List<T>	Dynamic array	Add O(1) amortized, index O(1)
Key-value lookup	Dictionary<TKey,TValue>	Hash table	Get/Set/ContainsKey O(1) avg
Membership test	HashSet<T>	Hash table	Add/Contains/Remove O(1) avg
LIFO	Stack<T>	Dynamic array	Push/Pop/Peek O(1)
FIFO	Queue<T>	Circular buffer	Enqueue/Dequeue/Peek O(1)
Min/max by priority	PriorityQueue<TElement,TPriority>	Binary heap	Enqueue/Dequeue O(log n)
Sorted by key	SortedDictionary<TKey,TValue>	Red-black BST	All ops O(log n)
Sorted unique values	SortedSet<T>	Red-black BST	Add/Contains/Remove O(log n)
Doubly linked list	LinkedList<T>	Linked nodes	AddFirst/Last, Remove node O(1)

The Core Tools

List<T>

List<T> is a dynamic array. It doubles capacity when full: amortized O(1) append, O(1) index access, O(n) insert or remove in the middle. If you know the final size up front, pass it to the constructor to skip the repeated reallocations:

var result = new List<int>(n);

List.Sort() is in-place and not stable. It uses introsort under the hood. If you need stable sort, use LINQ's OrderBy, which allocates a new collection but preserves the order of equal elements. The stability difference is covered in Merge Sort vs Quick Sort.

// Stable, allocates
var sorted = list.OrderBy(x => x.Key).ToList();

// Unstable, in-place, faster
list.Sort((a, b) => a.Key.CompareTo(b.Key));

Picking the wrong sorting approach in a live interview. Every time.

Dictionary<TKey, TValue>

Use TryGetValue instead of ContainsKey followed by indexing. Two hash lookups when one would do is the most common C# interview inefficiency, and your interviewer will notice.

// Two hash lookups (wasteful)
if (map.ContainsKey(key)) count = map[key];

// One hash lookup
if (map.TryGetValue(key, out int count)) { ... }

For frequency counting, the cleanest pattern is:

map[key] = map.GetValueOrDefault(key, 0) + 1;

GetValueOrDefault returns 0 for int when the key is missing, so you skip the null check entirely.

HashSet<T>

Use HashSet<T> for O(1) membership tests: visited tracking in BFS/DFS, two-sum complement checks, duplicate detection. The full analysis of why hash lookup is O(1) and when it isn't is in Hash Map Time Complexity.

var visited = new HashSet<int>();
if (!visited.Add(node)) continue; // Add returns false if already present

The Add return value saves a separate Contains call. Small thing, but it reads cleanly under pressure.

Stack<T> and Queue<T>

Stack<T> is array-backed. Queue<T> is a circular buffer. Both O(1) for core ops. Don't reach for LinkedList<T> as a queue substitute in DSA problems. It works, but the pointer chasing is slower in practice and the API is verbose enough to slow you down when you're already stressed.

var queue = new Queue<int>();
queue.Enqueue(start);
while (queue.Count > 0) {
    int node = queue.Dequeue();
    // process
}

PriorityQueue<TElement, TPriority>

Added in .NET 6, this is a min-heap by default. Smallest priority value dequeues first.

var pq = new PriorityQueue<string, int>();
pq.Enqueue("task", 3);
pq.Enqueue("urgent", 1);
pq.Dequeue(); // returns "urgent"

For a max-heap, pass a reverse comparer:

var maxHeap = new PriorityQueue<int, int>(
    Comparer<int>.Create((a, b) => b.CompareTo(a))
);

The element and priority are separate parameters. For Dijkstra distances or frequency counts where the element is its own key, just pass the same value for both:

pq.Enqueue(dist, dist);

SortedDictionary and SortedSet

SortedDictionary<TKey, TValue> is a red-black BST. All operations are O(log n). Use it when you need sorted keys with lookup by key: sliding window maximum with deletion, any problem needing floor/ceiling semantics.

C# lacks Java's floorKey by name, but SortedSet.GetViewBetween covers most interview use cases:

// Greatest key <= target
int floor = sortedSet.GetViewBetween(int.MinValue, target).Max;

// Smallest key >= target
int ceiling = sortedSet.GetViewBetween(target, int.MaxValue).Min;

SortedList<TKey, TValue> looks like SortedDictionary but is backed by two arrays. Faster to iterate, O(n) to insert or remove. Fine for read-heavy workloads after a one-time build, nowhere else.

Five Traps That Will Cost You the Interview

None of these throw exceptions. They produce wrong answers, silently blow your time complexity, or introduce a bug that only surfaces on the one test case you didn't check. That's what makes them dangerous.

1. Comparator Subtraction and Integer Overflow

Never subtract to compare. a - b silently overflows when a is large and b is int.MinValue, producing a garbage sort order with no exception, no warning, and no hint that anything is wrong.

// WRONG: silent overflow
list.Sort((a, b) => a - b);

// Correct
list.Sort((a, b) => a.CompareTo(b));

C# arithmetic is unchecked by default. The wrong comparator will look fine on most test cases and detonate on exactly one. Use a.CompareTo(b) for primitives and Comparer<T>.Default.Compare(a, b) for generics. If you're anywhere near int.MaxValue, switch to long.

2. List.Sort() Is Unstable

If your comparator has a secondary criterion baked in, instability doesn't matter. If equal elements must preserve their relative original order, use OrderBy. The gotcha is forgetting which mode you're in when you're going fast.

3. LINQ Multiple Enumeration

Every time you iterate an unevaluated LINQ query, it re-executes from scratch.

var evens = nums.Where(x => x % 2 == 0); // nothing happens yet
int count = evens.Count();               // executes the filter
int first = evens.First();              // executes the filter AGAIN

Materialize with .ToList() once if you need to iterate more than once. Accidentally double-scanning a large input is exactly the kind of bug that's invisible when tense and obvious in the debrief.

4. String Concatenation in a Loop

C# strings are immutable. += in a loop builds a new string each time, costing O(1 + 2 + ... + n) = O(n²). Building results character by character shows up constantly in sliding window and backtracking problems. The fix is always StringBuilder.

// O(n²)
string result = "";
foreach (char c in chars) result += c;

// O(n)
var sb = new StringBuilder();
foreach (char c in chars) sb.Append(c);
string result = sb.ToString();

String concatenation: consistently more confusing than it has any right to be.

5. Using LINQ Where a Typed Collection Is Faster

LINQ is expressive and genuinely useful for frequency maps and filtering:

// Frequency map
var freq = nums.GroupBy(x => x)
               .ToDictionary(g => g.Key, g => g.Count());

// Top k by frequency
var topK = freq.OrderByDescending(kvp => kvp.Value)
               .Take(k)
               .Select(kvp => kvp.Key)
               .ToList();

What LINQ doesn't give you is sorted structure navigation. SortedSet.GetViewBetween, ordered iteration over SortedDictionary, floor/ceiling queries: those require the typed collections directly. Reaching for LINQ when you need BST semantics is how you end up with an O(n log n) solution where O(log n) was available.

Quick Reference

// BFS skeleton
var queue = new Queue<int>();
var visited = new HashSet<int>();
queue.Enqueue(start);
visited.Add(start);
while (queue.Count > 0) {
    int node = queue.Dequeue();
    foreach (int neighbor in graph[node])
        if (visited.Add(neighbor)) queue.Enqueue(neighbor);
}

// Frequency count
var freq = new Dictionary<int, int>();
foreach (int x in nums)
    freq[x] = freq.GetValueOrDefault(x, 0) + 1;

// Min-heap (Dijkstra / top-k)
var pq = new PriorityQueue<int, int>();
pq.Enqueue(dist, dist);
int nearest = pq.Dequeue(); // returns TElement

// Tuple swap (no temp variable needed)
(nums[left], nums[right]) = (nums[right], nums[left]);

Practice the Performance, Not Just the Syntax

The gap between C# on LeetCode and C# in a live interview is that you have to narrate your choices out loud. Why SortedDictionary over Dictionary? Why materialize the LINQ query before calling .Count() twice? That verbal layer is a separate skill from writing correct code, and it doesn't show up in your accepted solutions count.

If you haven't practiced explaining data structure tradeoffs under pressure, SpaceComplexity runs voice-based DSA mock interviews where you get scored on exactly that. The five traps here are the ones that catch candidates who write C# every day. Review them, then open a medium problem and explain each choice before you type it.

Further Reading

• C# Collections documentation (Microsoft Learn)
• PriorityQueue<TElement,TPriority> API reference (Microsoft Learn)
• SortedSet<T> API reference (Microsoft Learn)
• Improve string concatenation performance in C# (Microsoft)
• C# Data Structures (GeeksforGeeks)