A colleague's LINQ code behaves strangely: a filtered list seems to change after it was built, a database query throws ObjectDisposedException, logging shows the same query running three times, and an exception appears far from the line that caused it. Explain deferred execution and how you would debug and fix each symptom.

How I would answer this in an interview

All four symptoms come from deferred execution: a LINQ query is a recipe, not a result. It runs when it's enumerated, every time it's enumerated, against whatever state exists at that moment. I'd explain the concept and then debug each symptom.

1. Deferred execution in one paragraph

Where, Select, OrderBy etc. return an IEnumerable<T>/IQueryable<T> that describes the computation. Nothing happens until something enumerates it: foreach, ToList, Count, First, Any, serialisation, data binding, the debugger's "Results View". Each enumeration re-runs the whole pipeline from the source.

2. Symptom 1: "The filtered list changes after it was built"

var active = customers.Where(c => c.IsActive);   // not a list - a query
customers.Add(new Customer { IsActive = true });
Console.WriteLine(active.Count());              // includes the new customer

The variable holds a query over customers; enumerating later sees later changes. Same with captured variables:

var minTotal = 100m;
var big = orders.Where(o => o.Total > minTotal);
minTotal = 1000m;                                // query now uses 1000

Fix: materialise when you need a snapshot — var active = customers.Where(c => c.IsActive).ToList(); — and avoid mutating captured variables after building queries.

3. Symptom 2: ObjectDisposedException from a database query

public IEnumerable<Order> GetOrders(Guid customerId)
{
    using var db = _factory.CreateDbContext();
    return db.Orders.Where(o => o.CustomerId == customerId);   // returned unexecuted
}   // db disposed here

foreach (var o in GetOrders(id)) ...   // executes now -> ObjectDisposedException

The query executes after the DbContext was disposed. Same pattern with yield return inside a using, or returning IQueryable from a scoped repository and enumerating after the request scope ended.

Fix: materialise inside the scope: return await db.Orders.Where(...).ToListAsync(ct); and return IReadOnlyList<Order> (or DTOs).

4. Symptom 3: "The same query runs three times"

var pending = db.Orders.Where(o => o.Status == OrderStatus.Pending);
if (pending.Any())                       // query 1: SELECT CASE WHEN EXISTS...
{
    _logger.LogInformation("{Count} pending", pending.Count());   // query 2: SELECT COUNT(*)
    foreach (var o in pending) Process(o);                         // query 3: SELECT ...
}

Each terminal operation re-executes the query. With LINQ to Objects, it re-runs filters and projections (and any side effects); with EF Core, it hits the database each time — and results may differ between executions.

Fix: materialise once: var pending = await db.Orders.Where(...).ToListAsync(ct); if (pending.Count > 0) .... Use analyser CA1851 (possible multiple enumeration) and EF Core logging to detect it.

5. Symptom 4: "The exception appears far from the line that caused it"

var parsed = lines.Select(l => int.Parse(l.Split(',')[2]));   // line 10: no error yet
...
var total = parsed.Sum();                                      // line 80: FormatException here

The lambda runs during enumeration, so the stack trace points at Sum() (with the lambda frame inside) rather than where the query was defined. Similarly, iterator methods with argument validation inside the yield body throw only when enumerated.

Fix: materialise at the boundary where the data is produced (ToList() right after parsing), validate eagerly (separate argument checks from iterator bodies using local functions — as the BCL does), and handle bad data explicitly (TryParse).

6. How I debug these

• Look at the declared type of the variable: IEnumerable/IQueryable means "query", List/array means "data".
• Put a breakpoint or log inside the lambda to see when and how often it runs.
• Be careful with the debugger's Results View — expanding it enumerates the query (and executes database queries).
• Enable EF Core SQL logging to count executions.
• Turn on CA1851 and review method signatures that return IEnumerable<T> from scoped resources.

7. A production example

A report service returned IEnumerable<InvoiceDto> built from an EF query inside a using block. It worked in unit tests (in-memory list) but threw ObjectDisposedException in production. After fixing that by moving ToList() inside, logs showed the report's main query executing three times (Any, Count, foreach) — tripling database load at month-end. Materialising once fixed both and cut report time by ~60%.