“Add caching” is a possible intervention, but it is not yet a diagnosis. In an interview, a stronger answer explains what you would measure, how you would narrow the problem, and what would prove the change helped.
Here is a practice scenario: a paginated document search endpoint feels slow. You have not been given a trace, a database plan, or production measurements. Everything below is a proposed investigation, not a claim about a real incident.
Start with the symptom and the boundary
Ask whether “slow” means the browser takes a long time to show results, the server takes a long time to respond, or a background operation finishes late. Those are different boundaries.
Clarify the affected route, filters, result size, concurrency and timing. Is every request slow, or only the first request after inactivity? Does one customer experience it more often? Is the error rate increasing too?
State an explicit success criterion with the interviewer. For example, agree on a latency target under a specified workload while preserving response correctness. Do not invent an existing baseline.
Build an evidence table before proposing a fix
| Observation to collect | Question it helps answer |
|---|---|
| End-to-end request duration and dependency timings | Where is the time going? |
| Database command count per request | Are we making repeated trips? |
| Generated SQL and execution plan | What work is the database actually doing? |
| Rows returned and response size | Are we moving data the screen does not need? |
| Allocation and CPU profile when relevant | Is application work the bottleneck? |
| Error and timeout rates under load | Is a “faster” result hiding failures? |
Use request correlation to connect those observations. Avoid copying tokens, personal records or sensitive query values into logs just to make an investigation easier.
If the database dominates, inspect the query shape
For EF Core, inspect the generated query rather than assuming the LINQ expression is cheap. Limit results, select the fields the response needs, and investigate repeated related-data queries. Index suitability depends on the actual predicates and ordering. Microsoft explains these considerations in its efficient querying guidance.
Keep authorization filters in place throughout the investigation. Removing a tenant or ownership predicate can change both correctness and performance, so the result would not be a valid optimization of the original request.
Pagination also needs a product decision: does the user need arbitrary page numbers or only the next set of results? That requirement should shape the implementation, rather than choosing a pattern because it sounds faster.
Make caching a conditional proposal
Before recommending a cache, answer four questions:
- Who is allowed to reuse this response?
- Which inputs determine its contents?
- How stale may it become?
- What happens after a write or a cache failure?
For a private document search, sharing an entry across users could expose information. For a public catalogue, reuse may be simpler. The same word—“cache”—does not resolve those differences.
Also distinguish a fast cache hit from a healthy uncached path. Your evaluation should include both.
Close with a verification plan
Change one suspected cause, repeat the same representative workload, and compare latency distributions, errors, resource use and response correctness. Keep the original request shape and access restrictions. Check both small and large result sets.
A useful closing answer is:
I would first locate the slow part using request and dependency measurements. If database work dominates, I would inspect the actual query and plan, then test a focused change. I would consider caching only after defining access boundaries and freshness. I would compare the same workload before and after and check that correctness and error rates have not regressed.
Practise the follow-up, too
Ask a partner to change one condition: “Only the first request is slow,” “The database takes little time,” or “The response contains private data.” Explain how that changes your investigation.
Disclosure: I am Raviindra Wadile, creator of wasAsked, where developers can browse reported interview questions and keep a browser-local practice shortlist. This article is a practice framework, not a measured performance case study.
Top comments (0)