You run one query to fetch a list, then loop over the rows and issue another query per row, so 200 posts become 201 round trips. Fix it by loading the related rows in a single pass: a join, one IN query keyed by parent id, or a batching loader that collects ids within a request tick. The tell is latency scaling linearly with result count while every individual query looks fast.
Why interviewers ask this
This is the single most common performance bug in ORM backed applications, so the interviewer is checking that you would recognize it in the wild rather than only define it. They want to hear how you would detect it, because the queries look healthy individually and only the count is wrong. Mentioning the tooling you would use to spot it separates people who have debugged it from people who have read about it.
How to structure your answer
- Define the pattern with a concrete count.
- Describe how you would detect it in a running app.
- Give at least two fixes and when each applies.
- Note the tradeoff of eager loading everything.
Example answer
It usually appears the moment someone renders a list. You fetch orders, then in the template you touch order.customer.name, and the ORM quietly issues a query per row. Individually those are half a millisecond, so nothing looks broken until the list grows and the endpoint takes four seconds. I detect it by looking at the query count per request rather than query duration; most APM tools show that directly, and locally I turn on query logging and count. The fix depends on the shape. For a simple belongs to relation, an eager load or a join is fine. For a one to many where a join would multiply rows, I prefer a second query with an IN clause and stitching in memory. In a GraphQL API it has to be a dataloader, because resolvers have no idea they are being called in a batch. The thing I avoid is eager loading everything by default, since that trades one problem for pulling half the database into memory.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you catch this in CI before it ships?
- When is a join worse than two separate queries?
- How does batching work across a GraphQL resolver tree?
Related full stack developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions