Architecture scenarioMedium~10 min.NET Collections & LINQ Essentials / 4 of 15

Interview question

How do you choose between IEnumerable, IReadOnlyCollection, IReadOnlyList, set, and dictionary contracts in a public C# API?

Choose the narrowest useful collection contract

Chooses between sequence, counted, indexed, set, and dictionary contracts based on required operations and complexity.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I choose the interface from the operations the method actually requires. IEnumerable<T> represents a sequence and may be lazy or one-shot; it does not promise cheap counting, indexing, or repeatable enumeration. IReadOnlyCollection<T> adds a count, and IReadOnlyList<T> adds indexed access without promising that another owner cannot change the backing collection. IReadOnlySet<T> expresses uniqueness and membership, while IReadOnlyDictionary<TKey,TValue> expresses keyed lookup. I use mutable ISet<T> or IDictionary<TKey,TValue> only when mutation is intentionally part of the method's contract.

Full answer below

Practice focus

Collection contracts, operation guarantees, repeatability, ordering, indexing, uniqueness, keyed lookup, mutation ownership, complexity, and materialization.

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
The type in a method signature tells callers which operations are reliable. Accepting or returning a broader abstraction than the behavior supports creates hidden enumeration and complexity assumptions.
I choose the interface from the operations the method actually requires. IEnumerable<T> represents a sequence and may be lazy or one-shot; it does not promise cheap counting, indexing, or repeatable enumeration. IReadOnlyCollection<T> adds a count, and IReadOnlyList<T> adds indexed access without promising that another owner cannot change the backing collection. IReadOnlySet<T> expresses uniqueness and membership, while IReadOnlyDictionary<TKey,TValue> expresses keyed lookup. I use mutable ISet<T> or IDictionary<TKey,TValue> only when mutation is intentionally part of the method's contract.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
If an algorithm loops once, IEnumerable<T> may be enough. If it uses Count and indexes repeatedly, accepting IReadOnlyList<T> is clearer than repeatedly calling LINQ methods on an unknown sequence. For duplicate detection, converting once to HashSet<T> can turn repeated linear membership checks into expected constant-time lookups at the cost of memory and lost duplicate information. A dictionary is appropriate when each key maps to a value, but duplicate-key behavior and comparer choice must be explicit.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Read-only interfaces prevent mutation through that reference; they do not prove the underlying collection cannot change elsewhere. I therefore separate API permissions from snapshot or immutability guarantees. Concrete complexity also matters: an interface does not make every implementation's operations equally cheap, and custom sequences may perform I/O. In production I avoid materializing merely to satisfy a convenient signature, but I materialize once when repeatability or complexity is part of the method's contract. I document ordering, duplicate handling, comparer semantics, and ownership when those affect correctness, and I use representative data to test accidental quadratic behavior.

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

Accepting IEnumerable and then assuming Count and index access are cheap.
Returning a read-only interface while continuing to mutate the same backing list unexpectedly.
Using a list for repeated membership checks on large inputs without measuring complexity.
Choosing a dictionary without defining duplicate keys or key comparison rules.

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

Details

The signature hides a requirement for repeatable enumeration or stable order.
Claims IReadOnlyList makes the underlying object immutable.
Discusses big-O complexity without considering allocation or realistic input size.
Cannot state whether duplicates and ordering are meaningful to the operation.

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.

When is IReadOnlyCollection more honest than IEnumerable?
What guarantee does HashSet provide that List does not?
How would you represent a one-shot sequence explicitly?

Continue the section

Next in .NET Collections & LINQ Essentials: Read-only versus immutable

Step 5 of 15

Read-only views versus immutable collections

Opening drill

Architecture scenarioMedium~10 min.NET Collections & LINQ Essentials / 4 of 15

Interview question

How do you choose between IEnumerable, IReadOnlyCollection, IReadOnlyList, set, and dictionary contracts in a public C# API?

Choose the narrowest useful collection contract

Chooses between sequence, counted, indexed, set, and dictionary contracts based on required operations and complexity.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Collection contracts, operation guarantees, repeatability, ordering, indexing, uniqueness, keyed lookup, mutation ownership, complexity, and materialization.

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
The type in a method signature tells callers which operations are reliable. Accepting or returning a broader abstraction than the behavior supports creates hidden enumeration and complexity assumptions.
I choose the interface from the operations the method actually requires. IEnumerable<T> represents a sequence and may be lazy or one-shot; it does not promise cheap counting, indexing, or repeatable enumeration. IReadOnlyCollection<T> adds a count, and IReadOnlyList<T> adds indexed access without promising that another owner cannot change the backing collection. IReadOnlySet<T> expresses uniqueness and membership, while IReadOnlyDictionary<TKey,TValue> expresses keyed lookup. I use mutable ISet<T> or IDictionary<TKey,TValue> only when mutation is intentionally part of the method's contract.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
If an algorithm loops once, IEnumerable<T> may be enough. If it uses Count and indexes repeatedly, accepting IReadOnlyList<T> is clearer than repeatedly calling LINQ methods on an unknown sequence. For duplicate detection, converting once to HashSet<T> can turn repeated linear membership checks into expected constant-time lookups at the cost of memory and lost duplicate information. A dictionary is appropriate when each key maps to a value, but duplicate-key behavior and comparer choice must be explicit.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Read-only interfaces prevent mutation through that reference; they do not prove the underlying collection cannot change elsewhere. I therefore separate API permissions from snapshot or immutability guarantees. Concrete complexity also matters: an interface does not make every implementation's operations equally cheap, and custom sequences may perform I/O. In production I avoid materializing merely to satisfy a convenient signature, but I materialize once when repeatability or complexity is part of the method's contract. I document ordering, duplicate handling, comparer semantics, and ownership when those affect correctness, and I use representative data to test accidental quadratic behavior.

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

Accepting IEnumerable and then assuming Count and index access are cheap.
Returning a read-only interface while continuing to mutate the same backing list unexpectedly.
Using a list for repeated membership checks on large inputs without measuring complexity.
Choosing a dictionary without defining duplicate keys or key comparison rules.

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

Details

The signature hides a requirement for repeatable enumeration or stable order.
Claims IReadOnlyList makes the underlying object immutable.
Discusses big-O complexity without considering allocation or realistic input size.
Cannot state whether duplicates and ordering are meaningful to the operation.

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.

When is IReadOnlyCollection more honest than IEnumerable?
What guarantee does HashSet provide that List does not?
How would you represent a one-shot sequence explicitly?

Continue the section

Next in .NET Collections & LINQ Essentials: Read-only versus immutable

Step 5 of 15

Read-only views versus immutable collections

How do you choose between IEnumerable, IReadOnlyCollection, IReadOnlyList, set, and dictionary contracts in a public C# API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How do you choose between IEnumerable, IReadOnlyCollection, IReadOnlyList, set, and dictionary contracts in a public C# API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section