What are generic interfaces in C#? Explain why IEquatable<T>, IComparable<T> and IEnumerable<T> exist alongside their non-generic versions, how a type implements several closed versions of one interface, and how to design your own generic interface such as IRepository<T>.

How I would answer this in an interview

A generic interface is an interface with type parameters: IEquatable<T>, IComparable<T>, IEnumerable<T>, IRepository<T>. It gives a type-safe contract that works across types without casts or boxing. I'd explain why the generic versions exist alongside the old non-generic ones, how one type can implement several closed versions, and how I design my own — including the trap of over-generic repositories.

1. Why generic and non-generic versions both exist

The non-generic interfaces (IEquatable doesn't exist non-generic, but IComparable, IEnumerable, IList, ICollection do) date from .NET 1.0, before generics. They use object:

public interface IComparable { int CompareTo(object? obj); }          // casts, boxing for structs
public interface IComparable<in T> { int CompareTo(T? other); }       // typed, no boxing

The generic versions were added in .NET 2.0 for type safety and performance:

• No boxing: IComparable<int>.CompareTo(int) takes the value directly; IComparable.CompareTo(object) boxes the argument.
• No casts / runtime type checks inside implementations.
• Better APIs: IEnumerable<T> gives typed foreach and LINQ.

The non-generic versions remain for backward compatibility (old APIs like ArrayList.Sort, data binding, reflection-based frameworks), and generic interfaces often inherit the non-generic one (IEnumerable<T> : IEnumerable) so typed collections still work with legacy consumers.

IEquatable<T> exists because object.Equals(object) boxes value types and needs a type check; EqualityComparer<T>.Default detects IEquatable<T> and calls the typed method — which is why structs used as dictionary keys should implement it.

2. Implementing several closed versions

A type can implement the same generic interface for different type arguments:

public sealed class Temperature : IEquatable<Temperature>, IComparable<Temperature>, IComparable<double>
{
    public double Celsius { get; }
    public bool Equals(Temperature? other) => other is not null && Celsius.Equals(other.Celsius);
    public int CompareTo(Temperature? other) => Celsius.CompareTo(other?.Celsius ?? double.NegativeInfinity);
    public int CompareTo(double other) => Celsius.CompareTo(other);
}

public sealed class OrderEventHandler : IHandler<OrderPlaced>, IHandler<OrderShipped>
{
    public Task HandleAsync(OrderPlaced e, CancellationToken ct) => ...;
    public Task HandleAsync(OrderShipped e, CancellationToken ct) => ...;
}

Each closed interface (IHandler<OrderPlaced>, IHandler<OrderShipped>) is a distinct interface; overloads with different parameter types implement each. If two closed versions have members with the same signature (e.g. a method returning T with no parameters), use explicit interface implementation to disambiguate. A type can't implement two versions that could unify for some type argument (e.g. IFoo<T> and IFoo<int> on a generic class C<T>) — a compile error.

3. Designing your own: IRepository<T> done carefully

public interface IRepository<TAggregate, TId>
    where TAggregate : AggregateRoot<TId>
    where TId : notnull
{
    Task<TAggregate?> FindAsync(TId id, CancellationToken ct);
    void Add(TAggregate aggregate);
    void Remove(TAggregate aggregate);
}

public interface IOrderRepository : IRepository<Order, OrderId>
{
    Task<IReadOnlyList<Order>> GetUnshippedAsync(DateOnly before, CancellationToken ct);   // specific queries
}

Guidelines:

• Keep the generic interface small — operations truly common to all implementers.
• Use constraints to express what T must be (aggregate roots, IDs).
• Add specific interfaces for type-specific queries rather than generic Find(Expression<Func<T,bool>>) or IQueryable<T> GetAll().
• Consider variance: an IReader<out T> that only returns T can be covariant; an IHandler<in T> that only consumes T can be contravariant.

The common mistake is a giant generic repository (GetAll, Find(predicate), Update, Delete, Query()) wrapping EF Core: it leaks EF details, encourages loading too much, and adds a shallow abstraction over something that's already a repository/unit of work.

4. A production example

A team had IRepository<T> with IQueryable<T> Query() used everywhere. Services built ad-hoc LINQ queries that failed at run time when EF couldn't translate them, and N+1 queries crept in. We replaced it with aggregate-specific repositories exposing intention-revealing async methods, kept a tiny generic base for FindAsync/Add, and moved reporting queries to dedicated query handlers with projections. Run-time translation errors disappeared and query performance became reviewable.