Of all the C# topics that come up in technical interviews, generics and collections show up the most consistently - across junior, mid, and senior level conversations. Not because they are exotic, but because they are the foundation almost every other piece of C# code sits on top of. This post covers both properly, with the analogies that made them click and real code from the kind of work that actually shows up in production systems.
Part 1: Generics
The Problem Generics Solve
Before generics existed in C#, building a container that could hold any type meant choosing between two bad options: writing a separate class for every single type - endless, near-identical duplication - or using the base object type and casting everything, which threw away compile-time type safety and added a real performance cost for value types through boxing.
Think of a generic class like a shipping container with a label you fill in later. The container itself - its size, its locking mechanism, how it gets loaded onto a ship - is exactly the same regardless of what goes inside. You write the container once. At the moment you actually use it, you decide: this one holds books, this one holds electronics, this one holds furniture. The container does not need to be rebuilt for each cargo type - but once declared to hold books, it refuses to let someone load a refrigerator into it instead.
