Debugging scenarioMedium~10 minQuery Design & Read Models / 8 of 15

Interview question

An ASP.NET Core endpoint gets slower as the page size grows because EF Core runs many small queries. How would you diagnose and fix it?

Diagnose an EF Core N plus one query in an API endpoint

Diagnoses hidden per-row EF Core queries and replaces them with a bounded query shape without creating an oversized join.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would reproduce the endpoint with a representative page size and inspect EF Core command logs or dependency traces for that single request. One parent query followed by the same child query once per parent confirms N plus one. I would then shape the response deliberately: project the required DTO in one query, aggregate in SQL, or load related rows in one additional set-based query. The goal is a bounded query count, not simply adding Include everywhere.

Full answer below

Practice focus

N plus one detection, lazy loading, query count, projections, Includes, split queries, and endpoint guardrails.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
N plus one is a query-shape failure: one request loads a set of rows, then navigation access or loop logic issues another query for each row. Query count grows with result size even when each individual command looks fast.
I would reproduce the endpoint with a representative page size and inspect EF Core command logs or dependency traces for that single request. One parent query followed by the same child query once per parent confirms N plus one. I would then shape the response deliberately: project the required DTO in one query, aggregate in SQL, or load related rows in one additional set-based query. The goal is a bounded query count, not simply adding Include everywhere.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would find what triggers the extra commands. Common causes are lazy-loaded navigation access inside a loop, mapping code that touches unloaded relationships, or serialization walking an entity graph after the endpoint appears finished. For scalar summaries I prefer a translated projection; for a real aggregate I compare Include, split queries, and explicit set-based loading. I inspect generated SQL and row counts because one giant join can remove N plus one while creating cartesian multiplication, duplicate data transfer, and worse memory use.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I correlate database commands to the request trace and compare query count, page size, rows read, payload size, and total database time. That distinguishes N plus one from one genuinely slow query. After the fix, an integration test can execute a representative request through a command interceptor and assert a small upper bound on commands without coupling to exact SQL text. I also bound page size and avoid returning persistence entities directly, which reduces the chance that serialization triggers hidden loading. If split queries are chosen, I account for their extra round trips and consistency window. The durable fix aligns the API response, EF query shape, and database indexes rather than optimizing query count in isolation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing N plus one by enabling Include everywhere.
Ignoring lazy loading triggered during serialization.
Returning huge entity graphs when a DTO projection is enough.
Leaving page size unbounded after the query is fixed.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain why query count grows with page size.
Has no way to inspect EF Core command logs.
Knows only Include and not projection or batching.
Does not consider row multiplication from joins.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would lazy loading make this worse?
When is split query useful?
How would you prevent this regression?

Continue the section

Next in Query Design & Read Models: Read Models

Step 9 of 15

Use read models for complex API screens

Opening drill

Debugging scenarioMedium~10 minQuery Design & Read Models / 8 of 15

Interview question

An ASP.NET Core endpoint gets slower as the page size grows because EF Core runs many small queries. How would you diagnose and fix it?

Diagnose an EF Core N plus one query in an API endpoint

Diagnoses hidden per-row EF Core queries and replaces them with a bounded query shape without creating an oversized join.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

N plus one detection, lazy loading, query count, projections, Includes, split queries, and endpoint guardrails.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
N plus one is a query-shape failure: one request loads a set of rows, then navigation access or loop logic issues another query for each row. Query count grows with result size even when each individual command looks fast.
I would reproduce the endpoint with a representative page size and inspect EF Core command logs or dependency traces for that single request. One parent query followed by the same child query once per parent confirms N plus one. I would then shape the response deliberately: project the required DTO in one query, aggregate in SQL, or load related rows in one additional set-based query. The goal is a bounded query count, not simply adding Include everywhere.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would find what triggers the extra commands. Common causes are lazy-loaded navigation access inside a loop, mapping code that touches unloaded relationships, or serialization walking an entity graph after the endpoint appears finished. For scalar summaries I prefer a translated projection; for a real aggregate I compare Include, split queries, and explicit set-based loading. I inspect generated SQL and row counts because one giant join can remove N plus one while creating cartesian multiplication, duplicate data transfer, and worse memory use.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I correlate database commands to the request trace and compare query count, page size, rows read, payload size, and total database time. That distinguishes N plus one from one genuinely slow query. After the fix, an integration test can execute a representative request through a command interceptor and assert a small upper bound on commands without coupling to exact SQL text. I also bound page size and avoid returning persistence entities directly, which reduces the chance that serialization triggers hidden loading. If split queries are chosen, I account for their extra round trips and consistency window. The durable fix aligns the API response, EF query shape, and database indexes rather than optimizing query count in isolation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing N plus one by enabling Include everywhere.
Ignoring lazy loading triggered during serialization.
Returning huge entity graphs when a DTO projection is enough.
Leaving page size unbounded after the query is fixed.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain why query count grows with page size.
Has no way to inspect EF Core command logs.
Knows only Include and not projection or batching.
Does not consider row multiplication from joins.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would lazy loading make this worse?
When is split query useful?
How would you prevent this regression?

Continue the section

Next in Query Design & Read Models: Read Models

Step 9 of 15

Use read models for complex API screens

An ASP.NET Core endpoint gets slower as the page size grows because EF Core runs many small queries. How would you diagnose and fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

An ASP.NET Core endpoint gets slower as the page size grows because EF Core runs many small queries. How would you diagnose and fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section