LINQ interview questions covering expression trees, IQueryable providers, EF Core translation, SQL inspection, performance, dynamic queries and advanced database querying.
Open a question for the full answer, code and interview guidance.
An expression tree represents code as a tree of expression objects rather than immediately compiled executable instructions. In LINQ, expression trees are especially important with IQueryable<T> because a query provider can inspect the tree and translate supported operations into another language such as SQL.
Func<T,bool> is an executable delegate. It contains compiled behavior that .NET can invoke directly. Expression<Func<T,bool>> represents the same logical operation as an inspectable expression tree.
IQueryable must provide the query provider with a structured description of the requested operations. Expression trees provide that structure.
IQueryProvider is the interface responsible for creating and executing IQueryable queries. An IQueryable exposes both an Expression describing the query and a Provider that knows how to interpret it.
EF Core builds an IQueryable expression tree as LINQ operators are composed. When the query executes, EF Core analyzes supported expressions, translates them into a database command, sends that command to the database, and materializes the returned data.
For parts of a query that must execute on the database, EF Core generally throws an exception when it cannot translate the expression rather than silently evaluating arbitrary filtering on the client.
EF Core provides ToQueryString for inspecting the SQL representation of an IQueryable without executing the query. Application logging can also capture generated database commands.
Selecting only the required fields reduces the amount of data read from the database, transferred over the network, materialized into objects, and held in memory.
N+1 occurs when one query loads a set of parent records and additional queries are then executed separately for related data for each parent. This can happen with certain lazy-loading or per-item query patterns.
Include requests eager loading of related entity data when returning entity graphs. ThenInclude can continue through deeper relationships.
Select is often preferable when the application needs a specific read model rather than a tracked entity graph. Projection can retrieve exactly the fields required and can calculate or reshape data directly in the query.
AsNoTracking tells EF Core not to track returned entities in the change tracker. For read-only queries, this can reduce tracking overhead and memory usage.
LINQ itself does not create database indexes, but the SQL generated from LINQ benefits from appropriate indexes on columns used for selective filtering, joining, and ordering.
A custom .NET method may not have a known translation in the query provider. If the provider cannot convert the method call into SQL or another supported operation, query translation can fail.
Reusable database predicates can be stored as Expression<Func<T,bool>> values. Because the expression remains inspectable, it can be supplied to IQueryable operators and translated when supported.
Dynamic predicate composition builds a final filter from conditions known only at runtime. A common approach is to start with IQueryable<T> and append Where clauses conditionally.
Server-side evaluation means the query provider translates operations so they run at the data source, such as a database. Client-side evaluation means data has reached the application and subsequent operations execute as .NET code.
When only existence matters, Any communicates the intent directly and can stop after determining that a matching element exists. Count must determine a count.
Every ToList materializes the current query and creates an in-memory list. Unnecessary materialization can allocate memory, break provider-side query composition, and cause later operations to run in the application rather than at the database.
Repeated enumeration, repeated sorting, repeated materialization, and repeated execution of expensive predicates can add unnecessary work. With IQueryable, repeated enumeration can also result in repeated database queries.
A compiled query allows EF Core to reuse a precompiled query representation for repeatedly executed query shapes. This can reduce some query-processing overhead in performance-sensitive scenarios.
Offset pagination with Skip and Take is simple, but very large offsets can become increasingly expensive because the database may still need to process skipped rows.
Keyset pagination retrieves the next page by filtering on the last value from the previous page using the same deterministic ordering. It avoids large Skip offsets.
Measure rather than guessing. Inspect generated SQL, database command duration, execution plans, row counts, application traces, and memory behavior. Look for excessive materialization, N+1 queries, repeated execution, unbounded result sets, unnecessary Include calls, and client-side processing.
Keep filters and projections on IQueryable until the intended execution boundary, select only required data, paginate large result sets, and use AsNoTracking for appropriate read-only entity queries. Avoid accidental multiple execution and premature materialization.