C# Coding Interview Patterns

XOR to isolate the value that appears once, the BitOperations class most C# code never uses, and the shift that silently does nothing because the count wrapped.

One template, five problems. Choose, explore, un-choose — and it is the un-choose that people leave out, because the code looks finished without it.

The whole family turns on one choice — sort by the start, or sort by the end. Merging wants one, the scheduling greedy wants the other, and the code looks almost the same either way.

Almost every tree problem is one question — does this quantity travel down the tree or back up it? Path sums, the diameter that never touches the root, ancestors, and the BST check that everyone writes wrong the first time.

Three recursive orders that differ by one line, the iterative version nobody can reconstruct under pressure, and why level-order needs one local variable rather than cleverness.

C# does not ship the node type these problems assume, and LinkedList is not it. Five patterns — the middle in one pass, Floyd’s cycle detection with the proof, in-place reversal, and the dummy head that deletes your special cases.

The part you only care about after a correct solution has already timed out. Reading input without allocating, the overflow C# will not warn you about, and why Console.WriteLine in a loop costs 400,000 writes.

Not the theory — the five shapes that keep coming back, and the single loop direction that silently turns one of them into a completely different problem.

Weights break BFS. Dijkstra fixes it, C#’s PriorityQueue has no DecreaseKey so you push duplicates instead, and when every edge is 0 or 1 the heap turns out to be pure overhead.

The representation most C# solutions use is also why they time out. Then breadth-first search, depth-first search without the call stack, and the sort that detects a cycle for free.