Comparison questionHard~9 min

Interview question

How do generic constraints and variance make a C# API safer, and how would you explain covariance versus contravariance?

Generic constraints, covariance, and contravariance

Uses constraints to express required operations and explains safe assignment direction for generic producers and consumers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Constraints state what a type argument must support, such as class, struct, notnull, a base type, an interface, or a public parameterless constructor. They let generic code call those guaranteed members without reflection or runtime guessing. Covariance with out allows a producer such as IEnumerable<string> to be used as IEnumerable<object>. Contravariance with in allows a consumer such as IComparer<object> to be used where an IComparer<string> is needed. A generic type is invariant unless its declaration safely permits one of those directions.

Full answer below

Practice focus

Generic constraints, compile-time capabilities, covariance, contravariance, invariance, reference-type restrictions, and API design.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Generics become valuable when their type relationships communicate what an API can safely do. Constraints and variance solve different problems: available operations versus assignment compatibility.
Constraints state what a type argument must support, such as class, struct, notnull, a base type, an interface, or a public parameterless constructor. They let generic code call those guaranteed members without reflection or runtime guessing. Covariance with out allows a producer such as IEnumerable<string> to be used as IEnumerable<object>. Contravariance with in allows a consumer such as IComparer<object> to be used where an IComparer<string> is needed. A generic type is invariant unless its declaration safely permits one of those directions.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The producer-consumer rule makes the direction easier to reason about. An IEnumerable<Dog> only gives values out, so reading each one as Animal is safe. An IAction<Animal>-style consumer can accept any animal, so it can also handle a dog, but an action that only accepts dogs cannot safely handle every animal. List<T> stays invariant because it both returns and accepts T; treating a List<Dog> as List<Animal> would allow someone to insert a cat. Variance applies to interfaces and delegates with reference-type arguments, not arbitrary classes or value-type substitutions.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use constraints to encode the smallest real contract instead of accepting object and failing later. Modern constraints such as unmanaged, notnull, and base/interface combinations can unlock safer low-level or domain-specific APIs, but excessive constraint hierarchies can make an abstraction harder to use than concrete code. Static abstract interface members can express operator-like requirements for generic math without dynamic dispatch or reflection. For variance, I inspect every input and output position, including nested delegate use, before marking a parameter in or out. Good generic design gives useful compiler errors and keeps runtime casts out of normal control flow.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using covariance to justify adding a different subtype to a mutable collection.
Confusing the in parameter modifier with generic contravariance.
Adding a new() constraint only to construct dependencies inside domain logic.
Using object and repeated casts when a small interface constraint expresses the contract.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot explain variance with a safe read or write operation.
Claims List of a derived type is assignable to List of its base type.
Treats constraints as runtime validation rather than compile-time guarantees.
Builds a generic abstraction with no reuse or type-safety benefit.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why is List<T> invariant?
Why does variance generally apply only to reference-type arguments?
When are static abstract interface members useful?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Comparison questionHard~9 min

Interview question

How do generic constraints and variance make a C# API safer, and how would you explain covariance versus contravariance?

Generic constraints, covariance, and contravariance

Uses constraints to express required operations and explains safe assignment direction for generic producers and consumers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Generic constraints, compile-time capabilities, covariance, contravariance, invariance, reference-type restrictions, and API design.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Generics become valuable when their type relationships communicate what an API can safely do. Constraints and variance solve different problems: available operations versus assignment compatibility.
Constraints state what a type argument must support, such as class, struct, notnull, a base type, an interface, or a public parameterless constructor. They let generic code call those guaranteed members without reflection or runtime guessing. Covariance with out allows a producer such as IEnumerable<string> to be used as IEnumerable<object>. Contravariance with in allows a consumer such as IComparer<object> to be used where an IComparer<string> is needed. A generic type is invariant unless its declaration safely permits one of those directions.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The producer-consumer rule makes the direction easier to reason about. An IEnumerable<Dog> only gives values out, so reading each one as Animal is safe. An IAction<Animal>-style consumer can accept any animal, so it can also handle a dog, but an action that only accepts dogs cannot safely handle every animal. List<T> stays invariant because it both returns and accepts T; treating a List<Dog> as List<Animal> would allow someone to insert a cat. Variance applies to interfaces and delegates with reference-type arguments, not arbitrary classes or value-type substitutions.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use constraints to encode the smallest real contract instead of accepting object and failing later. Modern constraints such as unmanaged, notnull, and base/interface combinations can unlock safer low-level or domain-specific APIs, but excessive constraint hierarchies can make an abstraction harder to use than concrete code. Static abstract interface members can express operator-like requirements for generic math without dynamic dispatch or reflection. For variance, I inspect every input and output position, including nested delegate use, before marking a parameter in or out. Good generic design gives useful compiler errors and keeps runtime casts out of normal control flow.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using covariance to justify adding a different subtype to a mutable collection.
Confusing the in parameter modifier with generic contravariance.
Adding a new() constraint only to construct dependencies inside domain logic.
Using object and repeated casts when a small interface constraint expresses the contract.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot explain variance with a safe read or write operation.
Claims List of a derived type is assignable to List of its base type.
Treats constraints as runtime validation rather than compile-time guarantees.
Builds a generic abstraction with no reuse or type-safety benefit.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why is List<T> invariant?
Why does variance generally apply only to reference-type arguments?
When are static abstract interface members useful?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

How do generic constraints and variance make a C# API safer, and how would you explain covariance versus contravariance?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

How do generic constraints and variance make a C# API safer, and how would you explain covariance versus contravariance?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice