EF Core Interview Questions

Analogy categoryAnalogies

How EF Core Interviews Are Usually Structured

EF Core interview questions generally probe three layers: conceptual understanding of the change tracker and DbContext lifecycle, practical query-writing ability including performance-aware LINQ, and judgment about trade-offs like when to use raw SQL, how to handle concurrency, or how to structure migrations for a team. Strong candidates don't just recite API names — they explain why a given approach matters, for example describing why AsNoTracking() matters in terms of the change tracker's snapshot mechanism rather than just saying 'it makes queries faster.' Interviewers commonly probe for this depth by asking a scenario ('this endpoint is slow, what would you check?') rather than a definition-only question.

🏏

Cricket analogy: A good coach doesn't just ask a batter to name their shots; they ask why you'd play a leave instead of a drive against a moving Dukes ball, testing judgment rather than vocabulary — the same depth EF Core interviewers look for in candidates.

Frequently Asked Conceptual Questions

Two of the most common conceptual questions are 'what does the change tracker do' and 'explain the difference between eager, lazy, and explicit loading.' A strong answer to the first explains that the change tracker maintains a snapshot of each tracked entity's original values so that SaveChanges() can diff current values against that snapshot and generate the correct UPDATE statements, and that this snapshotting is exactly what AsNoTracking() skips. A strong answer to the second distinguishes eager loading (Include/ThenInclude, resolved in the initial query), explicit loading (calling Load() on a navigation property after the fact, useful when you conditionally need related data), and lazy loading (navigation properties resolved automatically on first access via proxies, which requires the Microsoft.EntityFrameworkCore.Proxies package and virtual navigation properties, and is often discouraged because it can trigger unexpected N+1 queries).

🏏

Cricket analogy: The change tracker is like a scorer noting the exact state of the scoreboard when an over starts so they can calculate exactly what changed by the time it ends, the same diffing SaveChanges() performs against tracked snapshots.

csharp

// Eager loading: resolved in the initial query
var blog = await context.Blogs
    .Include(b => b.Posts)
    .FirstAsync(b => b.Id == blogId);

// Explicit loading: fetched later, on demand
var blog = await context.Blogs.FirstAsync(b => b.Id == blogId);
if (needsPosts)
{
    await context.Entry(blog).Collection(b => b.Posts).LoadAsync();
}

// Lazy loading: requires proxies + virtual navigation properties
public class Blog
{
    public int Id { get; set; }
    public virtual ICollection<Post> Posts { get; set; } // resolved on first access
}

Frequently Asked Scenario and Trade-off Questions

A common scenario question is 'how would you handle two users editing the same record at the same time,' which is testing whether a candidate understands optimistic concurrency: adding a [Timestamp] rowversion column (or configuring a property with IsConcurrencyToken()), catching DbUpdateConcurrencyException on SaveChanges(), and deciding a merge strategy (client wins, database wins, or a custom merge of the conflicting properties). Another frequent question is 'how would you debug a slow endpoint backed by EF Core,' where a strong answer walks through checking the generated SQL (via logging or a tool like MiniProfiler), looking for N+1 patterns from unintended lazy loading, checking whether AsNoTracking() and appropriate indexes are in place, and confirming the query isn't paginating client-side after pulling the full table into memory.

🏏

Cricket analogy: Optimistic concurrency is like the third umpire reviewing a run-out only when there's a genuine appeal, rather than stopping play after every single delivery — you only intervene, via DbUpdateConcurrencyException, when a real conflict is detected.

When asked to explain optimistic concurrency, mention the concrete mechanism: a rowversion/timestamp column configured with [Timestamp] or .IsConcurrencyToken(), EF Core including it in the WHERE clause of the UPDATE statement, and a DbUpdateConcurrencyException thrown when zero rows are affected because the version changed since it was read.

Avoid answering conceptual questions with only the API name (e.g., 'you use AsNoTracking()'). Interviewers are usually listening for the underlying mechanism — that it skips the change tracker's snapshot creation — since that shows you understand why the API exists, not just that it exists.

Interviewers usually test conceptual depth, practical query skill, and trade-off judgment, not just API recall.
Be ready to explain the change tracker's snapshot-diffing mechanism, not just name AsNoTracking().
Know the concrete difference between eager (Include), explicit (Load), and lazy (proxy-based) loading, and why lazy loading risks N+1 queries.
Optimistic concurrency uses a rowversion/timestamp column and DbUpdateConcurrencyException to detect and resolve conflicting edits.
For 'debug a slow endpoint' questions, walk through checking generated SQL, N+1 patterns, tracking behavior, and pagination strategy.
Ground every answer in the specific EF Core mechanism, not just the name of the feature.