354 .NET Developer Interview Questions & Answers

I use slow and fast pointers to find the middle node in a singly linked list, then I remove that node by rewiring the node before it to skip over it. The fast pointer moves two steps while the slow pointer moves one step, so slow reaches the middle when fast reaches the end. I process the list in linear time and use only constant extra space, so the solution is O(n) time and O(1) space.

The question asks me to remove the middle node from a singly linked list and keep the rest of the list connected in the same order. I use two pointers because one moves one step and the other moves two steps. When the faster pointer reaches the end, the slower pointer is at the middle. Then I find the node just before that middle node and change one link to skip it. This works well because it is simple, uses little memory, and runs in linear time.

1. For an even-length list, should I remove the first middle node or the second middle node?
2. Should I return the updated head after the middle node is removed?

The input is the head of a singly linked list. The output is the same list after removing the middle node. For an even-length list, this approach removes the second middle node, which matches the diagram.

I use two pointers. Slow moves one node at a time. Fast moves two nodes at a time. This lets slow land on the middle when fast reaches the end. I also keep a prev pointer so I can reach the node before slow.

If the list is empty or has one node, I return it right away. Then I start slow = head, fast = head, and later move prev from head until prev.Next == slow.

For 1 -> 2 -> 3 -> 4 -> 5, slow moves to 2 and fast moves to 3, then slow moves to 3 and fast moves to 5. At that point the loop stops. Then prev moves to 2, and I set 2.Next = 4. The result is 1 -> 2 -> 4 -> 5.

The key idea is that slow reaches the middle only after fast has moved through the list at double speed. Once I know the middle node, I only change one link. That removes the middle node without breaking the rest of the list.

The code checks the small-list cases first. Then it moves slow and fast together. After that, it finds the node before slow and rewires prev.Next to slow.Next. Finally, it returns the original head, because the first node does not change.

The key idea is to use two pointers to locate the middle node, then use one more pointer to find the node before it. Slow moves one step and fast moves two steps. When fast reaches the end, slow is at the middle. The invariant is simple: slow marks the middle candidate, fast controls when to stop, and prev ends on the node just before slow. Then I change one link, prev.Next = slow.Next, so the list stays connected.

The list is walked in linear time. The slow and fast pointers move through the list together, and the prev pointer may make one more pass to find the node before the middle. Even with that extra pass, the total work is still O(n). The code stores only a few pointers, so the extra memory is O(1).

A common mistake is moving the fast pointer by one step instead of two. That breaks the middle-node logic. Another mistake is deleting the node by value and not by node reference. That can remove the wrong item when values repeat. Candidates also forget the empty-list and one-node checks. A last common bug is rewiring links without first finding the node before the middle, which can break the rest of the list.

Say the invariant out loud: slow finds the middle, fast tells you when to stop, and prev is the node before slow.

I would add the two linked lists digit by digit from the head, because the head stores the ones place. I keep a carry value and a dummy head for the result list. On each step, I read the current digit from each list, use 0 when a list is already finished, add them, and store sum % 10 in a new node. I process each node at most once. The time is O(max(m, n)) and the extra space is O(max(m, n)).

This question asks me to add two numbers that are written one digit at a time in linked lists. The first node is the ones place, so I can read both lists from the front. At each step, I add the two current digits and any carry from the previous step. I write the new digit into the answer and move forward. I stop when both lists are finished and there is no carry left. That fits this problem because each step only depends on the current digits and the carry.

1. Are the digits always stored in reverse order?
2. Can one of the lists be empty?

The input is two linked lists. Each node stores one digit. The output is one linked list with the sum in the same reverse order.

I use two moving pointers, one carry value, and a dummy head node. This is enough because each step only needs the current digits and the previous carry.

I set p to l1, q to l2, carry to 0, and tail to the dummy node. The dummy node makes it easy to build the result list.

For 2 -> 4 -> 3 and 5 -> 6 -> 4, the first step gives 2 + 5 + 0 = 7. The next step gives 4 + 6 + 0 = 10, so I write 0 and keep carry 1. The last step gives 3 + 4 + 1 = 8. The result is 7 -> 0 -> 8.

After each loop, the result list already holds the correct lower digits, and carry holds the unfinished part of the next digit. When the loop ends, all digits have been handled, so the list is correct.

The code reads the current digit from each list, treats a missing node as 0, adds the digits and carry, creates one new node, then moves both pointers forward. At the end it returns dummy.next as the real head.

The time is O(max(m, n)). The extra space is O(max(m, n)) for the new result list. Important edge cases are one empty list, different lengths, and a final carry such as 5 + 5 = 10.

The key idea is to add the numbers one digit at a time from the head, because the head already stores the ones place. I keep a carry, two pointers, and a dummy head for the result list. At each step I read the current digit from each list, using 0 when a list is already done. Then I compute sum = x + y + carry, store sum % 10 in a new node, and keep sum / 10 for the next step. The invariant is simple: the result list always contains the correct lower-order digits built so far, and carry holds the only unfinished part from the previous addition.

The time is O(max(m, n)), where m and n are the lengths of the two lists. We move through the lists one node at a time and stop when both lists are finished and carry is 0. The extra space is O(max(m, n)) for the new result list, not counting the input lists. We do not use a map, stack, or table.

• Forgetting to include carry in the loop condition, so the final digit is lost. • Reading p.val or q.val without checking for null first. • Returning dummy instead of dummy.next. • Moving the pointers before using the current digits. • Losing the rest of the list after appending a new node.

Say the invariant out loud: after each step, the result list is correct for the digits already processed, and carry holds the only unfinished part.

I use a dummy node and reverse the linked list one full group at a time. For each chunk, I first check that k nodes exist. If they do, I reverse those nodes in place, reconnect the previous chunk’s tail to the new head, and move forward. If fewer than k nodes remain, I stop and leave them as they are. This runs in O(n) time and O(1) extra space.

The task is to take a chain of connected items and flip the order inside small groups. I only flip a group when it has exactly k items. After that, I connect the last item of the flipped group to the next group. Then I move forward and repeat. If fewer than k items remain, I stop and keep the rest in the same order. This fits a simple in-place method because I can change the links without making a copy, and I only need a few working values.

1. Should the last short group stay unchanged if it has fewer than k nodes?
2. Do you want an in-place solution, or is extra memory allowed?

The input is the head of a singly linked list and an integer k. The output is the same list with each full group of k nodes reversed. The nodes inside one group change order, but the groups themselves stay in the same order.

I use a dummy node, a pointer called prevGroup, a pointer called kth, and two pointers for reversal, curr and prev. The key invariant is simple. Everything before prevGroup is already finished. prevGroup always points to the tail of the last reversed group.

I start with dummy.next = head and prevGroup = dummy. This makes the first reconnect step easy, because the head of the list can change after the first reversal. Then I look for the kth node ahead of prevGroup. If I cannot find it, I stop.

The example in the diagram is 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 with k = 3. The first full group is 1, 2, 3. I reverse it to 3, 2, 1. Then I connect the tail of that group, which is now node 1, to node 4. Next I move prevGroup to node 1. The second full group is 4, 5, 6. I reverse it to 6, 5, 4. Then I connect node 4 to node 7 and move prevGroup to node 4. One node is left, so I stop.

Each time I reverse a group, I only touch the nodes inside that group. The node before the group keeps the list connected, and the node after the group is saved before reversal. That is why no nodes are lost. The invariant stays true after every loop.

The code first handles the easy cases. If the list is empty or k is 1, it returns the head. Then it creates the dummy node and starts the main loop. It finds the kth node, saves the node after the group, reverses the group one link at a time, reconnects the new head and the new tail, and moves prevGroup forward.

The time is O(n) because each node is visited only a constant number of times. The extra space is O(1) because the algorithm only uses a few pointers. The important edge cases are an empty list, k = 1, and a final group with fewer than k nodes.

Use a dummy node, then repeat the same four-pointer routine. First find the kth node ahead of prevGroup. If fewer than k nodes remain, stop. Otherwise reverse the nodes from prevGroup.next through kth in place, reconnect prevGroup.next to the new head, and move prevGroup to the old head of that group. The invariant is that everything before prevGroup is already finished, and the next group always starts at prevGroup.next.

The list is processed in chunks. Each node is touched only a constant number of times, so the time is O(n). The algorithm uses only a few pointer variables and one dummy node, so the extra space is O(1).

A common mistake is to start reversing before checking that a full group of k nodes exists. Another mistake is to lose the next segment while changing pointers. Candidates also often reconnect the wrong node after reversal, or forget to move prevGroup to the tail of the finished group. A final mistake is to keep processing the last short group instead of stopping.

Say the invariant out loud: everything before prevGroup is already fixed, and prevGroup is always the tail of the last reversed chunk.

Entity Framework Core is Microsoft's object-relational mapper for .NET. It lets C# code query and update relational databases using classes and LINQ. EF Core translates supported operations into database commands, tracks entities through DbContext, and persists changes with SaveChanges, while developers still need to understand database behavior and performance.

Entity Framework Core helps a .NET program read and change stored information without requiring the developer to manually write every instruction sent to the storage system. The developer works mainly with normal C# classes representing things such as customers, orders, or products. The framework handles much of the communication needed to find, add, change, and remove those records. It saves repetitive work and keeps application code easier to organize. However, it does not make storage concerns disappear. Developers still need to understand what work happens underneath and avoid choices that cause unnecessary requests, excessive data transfer, or poor performance.

1. Would you like me to focus on the basic EF Core concept, or also explain DbContext, change tracking, and SaveChanges?
2. Would you like an example of how EF Core behaves when reading and updating entities in a real application?

Entity Framework Core, usually called EF Core, is Microsoft's modern object-relational mapper, or ORM, for .NET. An ORM maps application objects to relational database structures and helps translate operations between the object model used by C# and the relational model used by the database.

In a typical application, C# classes such as Customer or Order are called entities. EF Core maps those entities and their properties to database tables, columns, keys, and relationships. A DbContext represents a short-lived unit of work and provides access to mapped entities, commonly through DbSet<TEntity> properties.

When the application builds a LINQ query against EF Core, EF Core attempts to translate the supported query expression into the query language understood by the configured database provider. With a relational provider, this is normally SQL. The database server executes that SQL and returns rows. EF Core then materializes those rows into C# objects. The database, not EF Core, performs the actual relational query execution.

By default, queries that return entity instances are tracking queries. Change tracking means the DbContext remembers the state of those entities. If the application modifies a tracked entity and later calls SaveChanges or SaveChangesAsync, EF Core detects the pending changes and generates the necessary INSERT, UPDATE, or DELETE commands. For read-only work, AsNoTracking can reduce tracking memory and processing overhead when the returned entities will not be modified and persisted through that context.

SaveChanges is an important persistence boundary. Changing a C# object does not immediately update the database. EF Core sends pending changes when SaveChanges or SaveChangesAsync is called. For relational database providers, when multiple changes are sent by one SaveChanges call, EF Core normally uses a transaction when the provider supports transactions so those changes can succeed or fail together. Applications can also manage explicit transactions when several operations must share a larger transaction boundary.

Related data can be loaded in different ways. Eager loading requests related data as part of an intentionally shaped query, commonly with Include. Explicit loading asks EF Core to load a relationship later through an explicit API call. Lazy loading can automatically issue a query when an unloaded navigation property is accessed, but it requires additional configuration and can easily cause unexpected database round trips.

A major pitfall is treating EF Core as if it completely hides the database. It does not. LINQ expressions are translated into provider-specific database queries, and different expressions can produce very different SQL and performance. Developers should understand generated queries, indexes, result sizes, relationship loading, transaction boundaries, constraints, and the number of database round trips.

Another common issue is the N+1 query problem. It occurs when one query loads a collection and then additional queries are executed separately for related data for each item. For example, loading 100 orders and then causing one additional query for each order's related data can result in 101 database queries. Appropriate projection, eager loading, or another intentionally shaped query can often avoid this pattern.

The practical tradeoff is productivity versus direct control. EF Core provides strong integration with C#, LINQ, change tracking, relationships, migrations, and other .NET application features, which reduces repetitive data-access code. However, developers must still inspect important queries and understand database behavior. For highly specialized SQL, unusual bulk operations, provider-specific features, or performance-critical paths, direct SQL or another data-access approach can sometimes provide more precise control.

1. Define entity classes that represent the application's data model.
2. Configure a DbContext and the appropriate database provider.
3. Map entities, keys, properties, and relationships using conventions, attributes, or the Fluent API.
4. Query through EF Core, usually with LINQ, while remembering that supported expressions are translated for database execution.
5. Shape queries so only required data and relationships are retrieved.
6. Use tracking when entities will be changed through that context and consider AsNoTracking for read-only entity queries.
7. Add, modify, or remove entities through the DbContext.
8. Call SaveChanges or SaveChangesAsync to persist pending changes.
9. Inspect generated SQL, query plans, indexes, and database performance when an operation is important or slow.

A common mistake is saying that EF Core is a database. It is a .NET data-access framework and ORM that communicates with a database through a provider. Another mistake is assuming that LINQ queries execute entirely in C#; supported database query expressions are normally translated by the provider and executed by the database. Candidates may also say that modifying an entity immediately changes the database, forgetting that SaveChanges or SaveChangesAsync is normally required. Other mistakes include keeping DbContext instances alive for too long, tracking read-only entities unnecessarily, ignoring generated SQL and indexes, confusing eager, explicit, and lazy loading, assuming Include is always the fastest choice, and allowing N+1 queries to create excessive database round trips.

Start with one sentence: EF Core is Microsoft's ORM for .NET. Then explain the normal flow: C# entities and LINQ, DbContext, database-query translation, change tracking, and SaveChanges. Finish with the key warning that EF Core simplifies data access but does not remove the need to understand SQL, database design, indexes, transactions, and query performance.

AddDbContext normally creates a scoped DbContext instance for each scope. AddDbContextPool also provides a scoped context, but completed instances can be reset and reused from a pool. Pooling reduces creation overhead, but application-owned mutable state must not leak between uses.

This question asks about two ways an application can prepare an object that works with stored information. In the first way, a new object is normally prepared for each unit of work and then discarded. In the second way, finished objects can be cleaned and kept so another unit of work can reuse them later. Reuse can save some setup work. The main risk is leftover information: anything belonging to one request, customer, or user must not remain when the same object is later given to someone else.

1. Does the DbContext contain any request-specific state, such as a tenant identifier or user-specific value?
2. Should I also explain how DbContext pooling differs from database connection pooling?

AddDbContext<TContext>() registers the DbContext with dependency injection using a scoped lifetime by default. In a typical request-based application, one context instance is created for that scope and disposed when the scope ends. A later scope normally receives a newly constructed DbContext instance.

AddDbContextPool<TContext>() also makes the DbContext available as a scoped service, but the underlying DbContext object can be reused. When the scope finishes and the context is disposed, EF Core resets the framework-managed state that supports pooling and returns the instance to the pool. A later scope may receive that same underlying object instance.

The main benefit is lower application-side overhead. DbContext objects are generally lightweight, but pooling can reduce repeated allocations and some initialization work in high-throughput applications. It does not make SQL statements execute faster by itself, and it should be considered an optimization whose value should be confirmed with measurement.

The main risk is mutable state. EF Core resets the state that its pooling infrastructure knows how to reset, including change-tracking state and other resettable EF Core services. EF Core cannot automatically understand arbitrary mutable fields or properties that application code adds to a custom DbContext. If the context stores a tenant identifier, current-user value, request flag, or similar state, that value must be safely initialized for every use and must not remain for the next consumer.

This also affects configuration. A pooled DbContext instance is configured when that instance is first created. OnConfiguring is not a per-request hook for a pooled instance. Configuration that must vary by request, such as tenant-specific information, should therefore be supplied through a safe per-scope design rather than assuming that a reused context is newly constructed for every request.

Pooling does not make DbContext thread-safe. A DbContext still must not be used concurrently by multiple operations. Pooling means that an instance can be reused sequentially after one consumer has finished with it; it does not mean that the same context should be shared simultaneously between requests or threads.

DbContext pooling is also different from database connection pooling. DbContext pooling reuses EF Core DbContext objects. Database connection pooling is normally implemented by the database provider and reuses physical database connections behind logical open and close operations. The two mechanisms are independent and can be used together.

Application code must also restore lower-level database state that EF Core does not own. For example, if code manually opens a database connection or changes provider-specific connection state, it must restore that state before the context is returned to the pool. Otherwise, the next consumer could receive unexpected state.

The practical decision is: use AddDbContext when the normal scoped lifetime is sufficient and simplicity is more important than removing a small amount of construction overhead. Consider AddDbContextPool when measurements show that repeated DbContext allocation or initialization matters and the context can be safely reused without carrying request-specific mutable state across scopes.

1. Start with AddDbContext unless there is a measured reason to optimize DbContext creation.
2. If profiling shows meaningful creation or initialization overhead, evaluate AddDbContextPool.
3. Treat every borrowed pooled context as scoped to the current unit of work even though its underlying object may later be reused.
4. Keep request-specific mutable state out of the DbContext when possible.
5. If custom per-request state is necessary, initialize it for every use and guarantee that stale values cannot reach the next consumer.
6. Restore any manually changed database-driver or connection state before disposal.
7. Never use one DbContext concurrently across threads or requests.
8. Measure again after enabling pooling to verify that it provides a worthwhile benefit.

Pooling does not change the time complexity of database queries and does not make the database server process a query faster. Its benefit is mainly reducing application-side object creation and initialization. This can lower CPU work, allocations, and garbage-collection pressure when contexts are created very frequently. Pooling also keeps reusable context instances in memory, so there is a small retained-memory cost for the pool. The maintenance cost is higher because developers must carefully manage custom mutable state. If network or database execution time dominates the request, the performance improvement from DbContext pooling may be small.

Common mistakes are saying that AddDbContextPool shares one DbContext concurrently across requests, assuming pooling makes DbContext thread-safe, confusing DbContext pooling with database connection pooling, or claiming that all custom application state is automatically reset. Another mistake is using OnConfiguring as though it runs for every request on a reused pooled instance. It is also dangerous to store a tenant or user identifier on a pooled context without safely reinitializing that value for every use. Finally, pooling does not automatically make slow SQL queries faster; it primarily reduces DbContext allocation and initialization overhead.

Lead with the lifecycle difference: AddDbContext normally gives each scope a newly constructed context, while AddDbContextPool can reuse context instances after EF Core resets its own state. Then emphasize the key safety rule: custom request-specific mutable state must not leak between uses. Finish by distinguishing DbContext pooling from database connection pooling.

I use code-first for new applications when my team owns the model and migrations. I use database-first when the database already exists or is owned by another team. The right choice depends on schema control, change flow, and how the team manages updates.

The question asks which way I would start when building a new program that needs to save information. It wants to know whether I would begin with the program design or with an already existing place where the records live. It also asks how I think about control, change, and who is responsible for updates over time. In real work, the best choice depends on whether the records are new or already in use, and on which team owns them.

1. Does the database already exist, or are we designing it from scratch?
2. Who owns database changes in this team?
3. How often does the schema change in production?

I usually choose code-first for new applications when the development team owns the data model. It keeps the C# classes and the database changes aligned through EF Core migrations, so the model changes in code can be reviewed and applied in a controlled way.

I choose database-first when the database already exists, when I must work with a shared enterprise database, or when a DBA team owns the schema. In that case, the database is the source of truth, and EF Core is used to map to it.

The main tradeoff is control versus convenience. Code-first gives the team more control over the design and change workflow. Database-first is better when the schema is already fixed or managed outside the app team. In both cases, I want a clear ownership model and a safe way to manage changes.

If I were making the choice in a real project, I would start with the existing situation, the team’s ownership, and the expected rate of schema change. For a greenfield app, code-first is usually my default. For a legacy system or a shared database, database-first is usually the safer choice.

1. Check whether the database already exists.
2. Check who owns schema changes.
3. If the team owns a new schema, use code-first and EF Core migrations.
4. If the schema already exists or is shared, use database-first.
5. Keep the database as the source of truth when another team controls it.
6. Review how often the schema changes before choosing the workflow.

Code-first adds migration work, but it is simple for new apps and keeps code and database changes together. Database-first avoids rebuilding an existing schema, but it can cost more effort when the database changes often. The real cost is mostly in team coordination, change management, and long-term maintenance, not in CPU or memory.

A common mistake is treating code-first as always better. Another mistake is using database-first for a database that the team really owns, which makes schema changes harder to manage. People also forget that migrations need discipline, and they sometimes ignore the fact that a shared database should usually be treated as the source of truth.

Give a clear default, then explain the exception. Say code-first for new team-owned systems, database-first for existing or shared databases, and mention schema control and migration ownership.

Add marks an entity as Added, Attach normally tracks it as Unchanged, Update marks it as Modified, and Remove marks it as Deleted. These methods mainly change EF Core tracking state; SaveChanges or SaveChangesAsync persists that state. The important production issue is making sure the selected state matches whether the entity and related entities are actually new, existing, changed, or being deleted.

These methods answer a simple business question: are we introducing a new object, tracking an existing object without changing it yet, changing an existing object, or removing an existing object? The main risk is choosing the wrong action and causing an unexpected insert, update, or delete.

1. Are the entities always loaded from the same DbContext, or do we receive disconnected DTOs from an API?
2. Should Update change all submitted values, or only properties that actually changed?
3. Can the operation include related entity graphs?

Add: EF Core normally sets the entity state to Added. When SaveChanges runs, EF Core normally generates an INSERT. This is the normal choice for a new row.

Attach: EF Core normally tracks the entity as Unchanged. Attaching alone does not mean that EF Core has verified that the row exists in the database. If the entity remains unchanged, SaveChanges normally generates no UPDATE or INSERT for it. Attach is useful when the application already knows the entity represents existing data and needs it tracked without immediately treating all of its values as modified.

Update: EF Core marks the entity as Modified. When SaveChanges runs, EF Core normally generates an UPDATE for that entity. The convenient part is that a disconnected entity can be updated without first loading the row, but the tradeoff is that Update is broad: it is a poor default for partial updates when only a small number of properties should change. With disconnected graphs, related entities can also receive states based on their keys and graph traversal, so unintended inserts or updates are possible.

Remove: EF Core marks an existing tracked entity as Deleted. When SaveChanges runs, EF Core normally generates a DELETE. If an entity is still Added and has never represented a saved database row, removing it does not create a database DELETE; EF Core can detach the Added entity because there is no persisted row to delete.

The most important interview point is that these methods primarily change tracked entity state; they do not normally execute the database command immediately. SaveChanges or SaveChangesAsync performs the persistence operation. For relational providers, EF Core normally uses a transaction for a SaveChanges operation so the set of changes is handled atomically when the provider supports transactions.

For disconnected API requests, the right choice depends on what the application knows. If the entity is definitely new, use Add. If it definitely represents existing data and should initially be tracked without being changed, Attach can be appropriate. If the operation intentionally treats an existing entity as broadly modified, Update can be appropriate. For a partial update, loading the existing entity and changing only the intended properties is often safer because EF Core then has clearer state information and the application does not rely on broad disconnected update semantics. Remove is appropriate after authorization and application rules establish that the target should be deleted.

A production mistake is assuming Attach or Update proves that a database row exists. They do not. The eventual database command can still affect zero rows, and concurrency handling may be required when the application needs to detect conflicting changes. Another risk is passing an entire disconnected object graph to Update or Remove and unintentionally changing related entities. Generated keys also matter because EF Core uses key information when determining states for entities in a graph.

Performance is usually not about the cost of the method call itself. The important costs are the size of the tracked graph, the number of database commands generated by SaveChanges, database work, locking, and network round trips. Marking unnecessary properties or related entities as modified can increase database work and make maintenance harder without improving correctness.

1. Decide whether the entity represents a new database row or existing data.
2. Use Add for a new entity.
3. Use Attach when an existing entity should be tracked as unchanged unless specific changes are made later.
4. Use Update when the operation intentionally treats an existing entity as broadly modified.
5. Use Remove when an existing entity should be deleted.
6. For disconnected graphs, inspect keys and related entities because state can propagate through the graph and may produce unintended inserts, updates, or deletes.
7. For partial updates, prefer loading the existing entity and changing only the intended properties when that gives safer semantics.
8. Call SaveChanges or SaveChangesAsync after the tracked states represent the intended database changes, and handle concurrency or database exceptions as required.

A common mistake is thinking Add, Attach, Update, or Remove immediately execute SQL. They primarily change EF Core tracking state, and SaveChanges or SaveChangesAsync performs persistence. Another mistake is using Update for every API request, which can apply broad modified-state semantics when only a few properties should change. Using Attach for a new entity can prevent the intended insert. Assuming Attach or Update proves database existence is also incorrect. Finally, ignoring related entities in disconnected graphs can lead to unexpected inserts, updates, or deletes.

Start with the four states: Added, Unchanged, Modified, and Deleted. Then explain that SaveChanges translates those states into database operations. Finish by mentioning disconnected graphs and the main tradeoff: Update is convenient for broad disconnected updates, while explicit changes are often safer for partial updates.

EF Core tracks entities by storing original values in a snapshot. On SaveChanges(), it compares current values with that snapshot, detects changes, updates entity state, and sends SQL only for modified properties unless another tracking strategy is being used.

This question asks how the software remembers what a data object looked like when it was first loaded, notices when you edit one or more fields, and then decides what needs to be sent back to the database when you save. It is asking whether the tool checks every field again, keeps its own copy, or uses another method. It also wants you to explain why only some fields may be included in the final update, and how the tool knows whether the item is new, changed, or removed.

1. Do you want the explanation to stay focused on snapshot tracking, or should I also mention notifications and lazy proxies?
2. Should I include how concurrency tokens and detached entities affect the generated UPDATE statement?

Start with the practical decision: EF Core uses the change tracker to remember what an entity looked like when it started tracking it. That original set of values is the baseline. When you change a property in memory, EF Core can compare the current value with the original value and detect the difference.

This is called snapshot change tracking. A snapshot is a saved copy of the original values. A state transition means the entity moves between states such as Unchanged, Modified, Added, and Deleted. SaveChanges() checks the entity state first, then compares tracked properties where needed.

For a normal tracked entity, EF Core compares current values with original values. If a property changed, EF marks only that property as modified. Then it builds an UPDATE statement that includes only the changed columns, not every column.

EF Core also uses original values for optimistic concurrency checks when a concurrency token exists, such as a rowversion column. That helps it detect when another writer changed the same row first.

Tradeoff: snapshot tracking is simple and reliable, but it uses extra memory and comparison work for tracked entities. For large object graphs or high-write workloads, explicit state changes, no-tracking reads, or notification-based tracking can be better when the model supports them.

Track the entity in a DbContext and store the original property snapshot.,Change one or more property values in memory.,Call SaveChanges(), which triggers change detection.,Compare current values with the snapshot and mark changed properties as Modified.,Use the entity state to decide whether to INSERT, UPDATE, or DELETE.,Generate SQL that updates only the changed columns, plus concurrency checks when needed.

The cost is mostly in memory and comparison work. EF Core keeps original values for tracked entities, so it uses extra memory. SaveChanges() must compare properties, so it takes more CPU as the number of tracked entities grows. The database cost is lower because EF sends smaller UPDATE statements when only some properties changed.

A common mistake is thinking EF Core scans the database again to find changes. It usually compares against the tracked snapshot in memory. Another mistake is assuming every property is always sent in the UPDATE. EF Core often sends only the modified columns. A third mistake is forgetting that state and change tracking can be bypassed with detached entities or custom tracking strategies.

Say snapshot, state, and SaveChanges in that order. That shows you understand both the tracking model and how EF Core turns object changes into SQL.

First returns the first match and throws if none exists. Single requires exactly one match, so it throws if there are zero or many. Find is an EF Core primary-key lookup that can return a tracked entity without hitting the database again.

This question asks how three helper methods behave when no item is found, one item is found, or more than one item is found. It also asks when to use the method that checks saved information first and only looks in the store if needed. The point is to choose the method that matches the rule behind the search: any matching item is enough, exactly one item is required, or the item is identified by one special number that belongs to it in the system today.

1. Is the row supposed to be unique?
2. Should missing data be treated as an error?
3. Are we using EF Core or raw SQL?

First means “give me the first matching row.” If no row matches, it throws. If many rows match, it still returns the first one. Use it when order matters and any match is fine.

Single means “there must be exactly one matching row.” If no row matches, it throws. If more than one row matches, it also throws. Use it when the data should be unique.

Find is for primary-key lookup in EF Core. It checks the current DbContext first, so it can return an already tracked entity from memory. If it is not tracked, it queries the database by key. If no row is found, it returns null. It is not for arbitrary columns.

1. Use First when any matching row is acceptable and the first one is good enough.
2. Use Single when the data must be unique and more than one row is an error.
3. Use Find in EF Core when you already know the primary key.
4. Expect First and Single to throw on a missing row, but expect Find to return null when nothing is found.
5. Remember that Find checks tracked entities before it queries the database.

First and Single may need to inspect rows until they can decide what to return or whether to throw. Find can be cheaper because EF Core may return an entity already tracked in memory. In practice, the main cost difference is how much data is read and whether a database round trip is needed.

A common mistake is using First when the code really needs exactly one row. That hides duplicate data. Another mistake is using Single when many rows are valid and only the first one matters. A third mistake is using Find for non-key columns, which it is not meant for. Another frequent error is forgetting that Find can return null instead of throwing when nothing is found.

Say the rule in one line: First = first match, Single = exactly one match, Find = primary-key lookup in EF Core.

Write a group join and then call DefaultIfEmpty() on the grouped result. That produces a left join shape, keeps all left-side rows, and returns null for the right-side entity when no match exists.

The question asks how to keep every item from the first list even when nothing on the second list matches it. It also asks what value to show for the missing part when there is no match. In plain words, the interviewer wants to know whether you understand how to write the code so the first side is never lost, and how to handle empty results safely without causing errors or leaving the answer unclear in the final projected result.

1. Should I show query syntax or method syntax?
2. Should the projection return an anonymous type or a DTO?

In EF Core, a left join is usually written with a group join and DefaultIfEmpty(). The group join finds matching rows, and DefaultIfEmpty() keeps the left-side row even when the right side has no match. That is the important part: without DefaultIfEmpty(), you get only matching rows.

I would explain it this way: use the left table as the main source, group the right table by the matching key, and then flatten the group with DefaultIfEmpty(). In the projection, treat the right-side entity as nullable and use a safe fallback when it is missing.

Example: csharp public sealed record OrderCustomerDto( int OrderId, DateTime OrderDate, string? CustomerName);

public static IQueryable<OrderCustomerDto> BuildQuery(AppDbContext context) { return from order in context.Orders // Group the matching customers for each order key. join customer in context.Customers on order.CustomerId equals customer.Id into customerGroup // DefaultIfEmpty() keeps the order even when no customer exists. from customer in customerGroup.DefaultIfEmpty() select new OrderCustomerDto( order.Id, order.OrderDate, // customer can be null here, so read it safely. customer != null ? customer.Name : null); }

The tradeoff is null handling. The query is simple and translates well, but the projection must be null-safe because the right-side row may not exist. This pattern is the standard EF Core way to write a left join.

1. Start with the left source.
2. Group-join the right source on the matching key.
3. Apply DefaultIfEmpty() to preserve rows with no match.
4. Project the result and handle the right side as nullable.
5. Let EF Core translate the query to SQL.

A common mistake is using a normal join, which drops left-side rows that do not match. Another mistake is forgetting DefaultIfEmpty(). A third mistake is reading right-side fields without a null check, which can fail when there is no matching row.

Say the pattern clearly: group join, then DefaultIfEmpty(). That shows you know both the LINQ shape and the left-join behavior.