What is IQueryable<T>, and how is it different from IEnumerable<T>? Explain Expression, ElementType and Provider, how Queryable methods build expression trees, why the static type of a variable decides where a query runs, AsEnumerable and AsQueryable, and whether a repository should expose IQueryable.

How I would answer this in an interview

IQueryable<T> represents a query that a provider (EF Core, OData, Cosmos SDK) will translate and execute elsewhere — usually as SQL. IEnumerable<T> represents a sequence processed in memory by .NET code. The crucial difference is that IQueryable operators take expression trees (data describing code) while IEnumerable operators take delegates (compiled code). I'd cover the three members of IQueryable, how Queryable methods build expression trees, why the variable's static type decides where code runs, AsEnumerable/AsQueryable, and whether repositories should expose IQueryable.

1. The IQueryable<T> interface

public interface IQueryable : IEnumerable
{
    Type ElementType { get; }        // T
    Expression Expression { get; }   // the expression tree describing the query so far
    IQueryProvider Provider { get; } // knows how to build and execute queries
}
public interface IQueryable<out T> : IEnumerable<T>, IQueryable { }

• Expression: the query as a tree, e.g. Call(Queryable.Where, [Constant(DbSet<Order>), Quote(Lambda(o => o.Total > 100))]).
• Provider: CreateQuery<T>(Expression) builds a new queryable with a bigger tree; Execute<T>(Expression) runs it (for scalars like Count); enumeration also goes through the provider.
• ElementType: the element type.

2. How Queryable methods build expression trees

public static IQueryable<T> Where<T>(this IQueryable<T> source, Expression<Func<T, bool>> predicate)
    => source.Provider.CreateQuery<T>(
        Expression.Call(null, WhereMethodInfo.MakeGenericMethod(typeof(T)), source.Expression, Expression.Quote(predicate)));

• The lambda o => o.Total > 100 is compiled by the C# compiler into an expression tree (because the parameter type is Expression<Func<...>>), not IL.
• Where doesn't filter anything — it wraps the existing expression in a Call node and asks the provider for a new IQueryable.
• On enumeration, EF Core translates the full tree to SQL.

Compare Enumerable.Where(this IEnumerable<T>, Func<T,bool>) — a compiled delegate executed per item in memory.

3. The static type decides where the query runs

Overload resolution picks Queryable.Where or Enumerable.Where from the compile-time type of the variable:

IQueryable<Order> q = db.Orders;
var a = q.Where(o => o.Total > 100);          // Queryable.Where -> SQL WHERE

IEnumerable<Order> e = db.Orders;              // same object, different static type!
var b = e.Where(o => o.Total > 100);          // Enumerable.Where -> SELECT * then filter in memory

Assigning a DbSet to an IEnumerable<T> variable, passing it to a method that accepts IEnumerable<T>, or calling a helper that takes Func<T,bool> silently moves the rest of the query into memory — one of the most expensive EF Core mistakes.

4. AsEnumerable() and AsQueryable()

• AsEnumerable(): changes the static type to IEnumerable<T> deliberately, so later operators run in memory. Use it after the database-side work, for logic SQL can't express:

var result = db.Orders.Where(o => o.Status == Paid)
    .Select(o => new { o.Id, o.Total, o.CreatedAt })       // SQL
    .AsEnumerable()
    .Select(x => new OrderVm(x.Id, Format(x.Total), Humanise(x.CreatedAt)));   // memory

(In EF Core, client evaluation in the final Select is allowed anyway; AsEnumerable makes the boundary explicit.)

• AsQueryable(): wraps an IEnumerable<T> in an EnumerableQuery<T> so code expecting IQueryable<T> works over in-memory data (e.g. in tests). It doesn't make in-memory data go to a database, and behaviour can differ from a real provider (e.g. null handling, case sensitivity, unsupported methods succeed in memory but fail in EF).

5. Should a repository expose IQueryable?

Arguments for: flexible composition (paging, filtering, projection) without writing many methods; callers can project to exactly the DTO they need.

Arguments against (my default):

• It's a leaky abstraction: callers must know EF Core translation rules; untranslatable expressions fail at run time.
• Unpredictable queries: anyone can add includes, N+1 patterns or expensive operations; performance can't be reviewed in one place.
• Lifetime issues: the query executes later, possibly after the DbContext is disposed.
• Testing: in-memory AsQueryable() tests pass for queries that fail against SQL Server.
• It defeats the purpose of a repository (hiding persistence).

My approach: repositories return materialised results from intention-revealing methods (GetUnshippedOrdersAsync(before, ct)); read-side queries use dedicated query handlers that use DbContext/IQueryable internally and return DTOs. Some teams use the Specification pattern to encapsulate reusable query logic as expression trees. Exposing IQueryable can be acceptable inside a single layer (e.g. a query service) or for OData endpoints.

6. A production example

A generic helper IEnumerable<T> Page<T>(IEnumerable<T> source, int page, int size) was used on EF queries. Because the parameter was IEnumerable<T>, Skip/Take ran in memory after loading all rows — a list page loaded 2 million rows. Changing the helper to IQueryable<T> Page<T>(IQueryable<T> source, ...) restored SQL OFFSET/FETCH, and the endpoint dropped from 30 s to 80 ms.