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.

Generic Classes in Practice

A generic class declares one or more type parameters, conventionally named T, that get filled in at the point of use rather than when the class is written. A simple Box class written once as Box<T> works identically well for Box<Post>, Box<int>, or Box<string> - the compiler enforces that whatever type was specified at creation is the only type that class instance will ever accept, with zero runtime casting required anywhere.

Generic Methods

The same idea applies at the method level without requiring an entire generic class. A method that returns the first item in any list, or null if the list is empty, can be written once as a generic method and called with a list of posts, a list of integers, or a list of strings equally correctly, with the compiler inferring the type parameter automatically from what gets passed in.

This is, in fact, exactly what every LINQ method already does. Where and Select are generic methods under the hood - the reason they work identically well on a list of blog posts and a list of integers is the same generic mechanism covered here, not separate special-cased implementations for every possible type.

Generic Constraints

Sometimes a generic container should not accept literally any type - it should only accept types with certain specific capabilities. Constraints express that restriction directly in the type parameter declaration.

A constraint of where T : class restricts T to reference types only.
A constraint of where T : IComparable<T> guarantees that comparison operations are actually available inside the generic code, which matters
enormously for something like a generic GetMax method that needs to compare items to find the largest one.
A constraint of where T : new() guarantees a public parameterless constructor exists, which is required before generic code can legally write new T() to create an instance.
Multiple constraints can combine - a repository base class might reasonably require where T : class, IEntity, new() all at once.

A small but realistic generic repository pattern over Entity Framework Core illustrates this well: a single Repository class, constrained to where T : class, provides GetByIdAsync and GetAllAsync methods that work correctly for Post, Tag, or Comment entities without writing three nearly identical repository classes.

Covariance and Contravariance

This is the part interviewers most often use to probe deeper understanding, and it is genuinely simpler than it sounds once translated out of the in/out keyword syntax into plain language.

Covariance, marked with the out keyword in an interface declaration, allows a more derived type to be used where a less derived type was originally specified. IEnumerable is declared as covariant, which is why a List<string> can be assigned to an IEnumerable<object> variable without any cast - if something only ever produces values of type T by reading them out, it is probably safe to treat every string as the
object it also happens to be.

Contravariance, marked with the in keyword, runs the opposite direction - it allows a less derived type to be used where a more derived type was specified. Action is contravariant, which is why an Action<object> can be assigned to an Action<string> variable - something that knows how to process any object can certainly handle the more specific case of a string, since a string satisfies every requirement an object-handling method might have.

Part 2: Collections

If generics are the shipping container with a fillable label, collections are the different container designs built on top of that same underlying pattern - a numbered shelf, a labeled drawer system where each drawer has exactly one name, a single-entry tube, a stack of plates where only the top one is reachable. Same generic foundation, shaped differently for different access patterns.

List<T>

The default, ordered, resizable collection - genuinely the correct first choice in the large majority of real-world cases. List preserves insertion order, supports fast indexed access, and handles frequent additions and removals well. Use it whenever order matters and there is no specific reason to reach for something more specialized.

Dictionary<TKey, TValue>

The collection built specifically for fast lookup by a unique key. Where List.Contains() or a manual loop scans through every item until it finds a match - an O(n) operation that gets slower as the collection grows - Dictionary lookup by key is close to O(1) regardless of how many entries exist. The moment "look this thing up by some identifier" becomes a frequent operation in a piece of code, that is the signal to reach for a Dictionary rather than continuing to scan a List.

TryGetValue provides a safe lookup pattern that avoids exceptions when a key might not exist, which is almost always preferable to a direct indexer access wrapped in a try/catch.

HashSet<T>

A collection whose entire purpose is guaranteeing uniqueness and supporting fast set operations. Adding a duplicate value to a HashSet simply does nothing rather than creating a second copy and checking whether a value exists runs in close to O(1) time rather than the O(n) scan a List would require. Beyond simple uniqueness, HashSet supports genuine set operations - union, intersection, and except - that are easy to forget exist but are often exactly the right tool when comparing two collections of tags, categories, or identifiers.

Queue<T> and Stack<T>

Two collections where the access pattern itself is the entire point.
Queue is first-in-first-out, conceptually identical to a line at a coffee shop - the first item added is the first item retrieved.
Stack is last-in-first-out, conceptually identical to a stack of plates - the most recently added item is the first one retrieved. These are not purely academic constructs invented for textbooks - every running program's call stack is, quite literally, a stack of execution frames, and many real messaging systems implement queue-like processing semantics for exactly the reasons a Queue would suggest.

IEnumerable<T> vs IList<T> vs List<T>

This is close to a guaranteed interview question in some form, and the honest answer is a hierarchy of guarantees rather than a single right answer.

IEnumerable is the most general - it guarantees only that the collection can be iterated once with foreach, with no promise of indexed access or even an efficient Count. LINQ queries are returned as IEnumerable specifically because of deferred execution, where the underlying work has not actually run yet at the point the type is returned.

IList adds indexed access, a real Count property, and Insert/RemoveAt methods, while still remaining an interface rather than a concrete implementation - useful when a method needs indexing but should stay abstract about exactly which concrete collection type a caller provides.

List is the concrete implementation most code actually instantiates and works with directly.

The practical, interview-relevant rule that ties this together: accept the most general type a method actually needs as a parameter - frequently IEnumerable, since many methods only need to iterate once - and return the most specific type that gives callers genuinely useful guarantees, frequently List or an array, rather than hiding a concrete result behind an unnecessarily abstract interface.

Why the Old Non-Generic Collections Should Never Appear in New Code

ArrayList and Hashtable predate generics in the .NET framework and store everything as the base object type. Every read requires an explicit cast, which both adds overhead and removes compile-time type checking - a type
mismatch that should be caught immediately by the compiler instead surfaces later as a runtime InvalidCastException. Value types stored in these collections also get boxed, wrapped in an object allocated on the heap, which carries a genuine, measurable performance cost compared to a generic List storing integers directly without any boxing at all. There is no scenario in modern C# where reaching for ArrayList or Hashtable over their generic equivalents is the right engineering decision.

Why Dictionary Lookup Is Actually O(1)

A Dictionary is backed by a hash table internally. Each key gets run through a hash function that produces a number, and that number determines which internal bucket the entry is stored in. Looking up a key means hashing it and jumping directly to the relevant bucket, rather than scanning through every stored entry in sequence - which is precisely why lookup time stays close to constant regardless of how many items the Dictionary holds.

This convenience comes with one real responsibility: a custom class used as a Dictionary key must correctly override both GetHashCode and Equals, consistently with each other. Get this wrong, and lookups fail in confusing, silent ways - entries land in unexpected buckets, or two objects that should be treated as equal are instead treated as entirely different keys.

Key Lessons

• Default to List unless there is a specific, identifiable reason to reach for something else - it remains correct for the large majority of real-world cases.

• Reach for Dictionary the moment looking something up by an identifier becomes a frequent operation - the jump from O(n) to O(1) is a real, measurable difference at any meaningful scale. Use HashSet for uniqueness guarantees and set operations rather than manually checking Contains on a List inside a loop.

• Accept IEnumerable in method parameters specifically when a method only needs to iterate once - it keeps an API's surface flexible for whatever callers want to pass in.

• Return concrete types like List when callers genuinely need the stronger guarantees a concrete type provides, rather than hiding behind an abstraction that gives them less to work with.

• Never reach for the legacy non-generic collections in new code - there is no remaining scenario in modern C# where they represent the better engineering choice.

• If a custom class is ever used as a Dictionary key, both GetHashCode and Equals must be overridden correctly and consistently, or lookups will fail in ways that are genuinely difficult to debug after the fact.

Summary

Generics make it possible to write a single class or method that works correctly and safely across many different types, without duplicating code and without giving up compile-time type checking along the way. Collections are the most common, most practical application of that underlying idea - List, Dictionary, HashSet, Queue, and Stack are all generic containers shaped deliberately for different access patterns. Knowing which one genuinely fits a given problem, and being able to
explain why, is one of the most consistently tested pieces of C# knowledge in technical interviews, precisely because it is also one of the most consistently used pieces of knowledge in real production code.

---

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=csharp-generics-collections-explained

More from TechStack Blog, by category:
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
Azure: https://www.techstackblog.com/category.html?cat=azure

Follow for weekly posts on C#, Azure, and cloud engineering.