C# HashSet Equality: Four Backend Decision Exercises

Four decisions, not four definitions

Download this original two-page workbook and spend 15 minutes explaining your choices before reading the model answers on page two.

The scenarios cover case-insensitive tags, deterministic display order, repeated events and identity policy. Each asks you to select a data structure or comparison rule and explain what information it preserves.

What a strong answer includes

• Define what counts as an equivalent value before choosing a comparer.
• Separate membership from ordering: a HashSet does not provide an ordering contract.
• Keep event history separately when duplicates carry meaning.
• Treat identifier normalization as a domain decision, not a universal rule for email addresses.

For case-insensitive technical tags, a HashSet<string> constructed with StringComparer.OrdinalIgnoreCase accepts the first value and returns false from Add for an equivalent case variant. This does not modify the stored spelling. For a stable display, explicitly sort a separate projection.

Review your reasoning

A correct API name is only the beginning. Explain the required equality semantics, whether multiplicity matters, and which output order the caller expects. The answer sheet provides model reasoning for each decision.

Reference: Microsoft HashSet<T> documentation. These are original interview practice exercises, not employer interview questions.

Sample scenario

Your tag list receives API, api, and database. The product requires case-insensitive uniqueness and alphabetical display. Can one HashSet<string> satisfy both requirements automatically?

Worked answer: Construct the set with StringComparer.OrdinalIgnoreCase to define membership. It contains two logical tags, but that does not establish display order or normalize the retained spelling. Build a sorted display projection with an explicit comparer. If the product requires lowercase spelling, normalize for that separate rule instead of assuming the comparer rewrites values.

The same design would be wrong for an event history where repeated occurrences carry meaning. Keep the history and use a separate set only for the deduplication identity required by the contract. The attached workbook extends these choices into four exercises with an answer sheet.