DEV Community: Last Bencher

React interview practice: explain a stale search result before fixing it

Last Bencher — Tue, 15 Sep 2026 14:35:57 +0000

A user searches for “react”, then quickly changes the search to “react hooks”. The second request finishes first. A moment later, results for the older search replace the current results.

The network did not necessarily fail. The UI accepted a response that no longer belonged to the current request.

This is a useful interview exercise because it tests reasoning about time, state and cleanup—not just whether you remember a Hook name.

Draw the sequence first

Time	Event
1	Request A starts for “react”
2	Request B starts for “react hooks”
3	B finishes; the UI shows B
4	A finishes; an unguarded callback overwrites B

The requirement is not “use the last response to arrive.” It is “only the request belonging to the current search may update this result state.”

Clarify the intended loading experience as well. Should old results remain visible with a loading indicator, or disappear immediately? That is separate from preventing an obsolete response from winning.

Describe ownership, then implementation

Each search operation needs a way to determine whether it is still current when its asynchronous work finishes. In an Effect-based implementation, cleanup can mark an old operation inactive. React's Effect documentation describes aborting a fetch or ignoring its obsolete result during cleanup.

The following small JavaScript model demonstrates result ownership. It is not a complete React component or a production fetching library:

function createLatestResultGate() {
  let generation = 0;

  return {
    begin() {
      const mine = ++generation;
      return () => mine === generation;
    },
    invalidate() {
      generation += 1;
    },
  };
}

const gate = createLatestResultGate();
const isCurrentA = gate.begin();
const isCurrentB = gate.begin();

console.assert(isCurrentB(), "B owns the current result");
console.assert(!isCurrentA(), "A must not update the result");

gate.invalidate();
console.assert(!isCurrentB(), "Cleanup invalidates B too");

This models the ordering rule without needing unpredictable network delays. A real integration must keep the gate scoped to the appropriate component/request lifecycle; recreating it for every callback would defeat the comparison. An Effect-local inactive flag is often simpler for one Effect.

Guard more than successful data

An obsolete request can also clear a loading indicator or display an error after a newer request succeeds. Apply the ownership rule to every asynchronous state transition associated with the request, including error handling and finalization.

For example, if A fails after B succeeds, the user should not suddenly see A's error presented as the status of B. That case belongs in the test plan alongside out-of-order successes.

Debouncing answers a different question

Delaying a request until typing pauses may reduce how many operations start. It does not establish which already-started request owns the current state.

In an interview, separate the two requirements explicitly: controlling request frequency and preventing stale updates. Choosing one does not demonstrate that the other is solved.

Test sequences, not just the happy path

Use controllable promises or a request mock so the test decides completion order:

A starts, B starts, B succeeds, then A succeeds: B must remain visible.
A starts, B starts, B succeeds, then A fails: A's error must not replace B's status.
A starts, then the component unmounts: the old operation must not update its state.
The latest request fails: the current error must still be shown.

Also explain what happens to loading state in each sequence. Merely hiding every error would make one test pass while breaking the actual feature.

Avoid rebuilding your entire data layer in the interview

If the application already uses a framework loader or client-side query cache, explain how its request identity, cancellation and cache behavior apply. React discusses the limitations of manual fetching in Effects in its useEffect reference. A small example proves understanding; it does not justify replacing the application's existing data layer.

Disclosure: I am Raviindra Wadile, creator of wasAsked. I use interview questions as prompts for explaining behavior and testing assumptions. The site offers public question browsing and a browser-local practice shortlist; this article is an educational exercise, not a report of a production incident.

How to answer “How would you optimize a slow .NET API?”

Last Bencher — Tue, 15 Sep 2026 14:34:49 +0000

“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.

Turn an interview question list into a practice session

Last Bencher — Tue, 15 Sep 2026 14:12:03 +0000

An interview question list becomes more useful when it tells you what to do next. Reading a familiar question can feel like preparation even when you cannot explain an answer without looking it up.

Try this workflow with a small set of questions for the role and technology you are targeting.

1. Capture what is actually known

For each question, record the company, technology, reported year and interview context when supplied. Leave missing information unknown. A question reported from one team does not describe every interview at that company, and a publication date is not necessarily an interview date.

Keep the original question separate from your interpretation. For example, “How would you improve this query?” needs more context before there can be one useful recommendation. The database engine, schema, query, data distribution and performance goal all matter.

2. Explain before opening an answer

Pick one question and explain your approach aloud or in a short note. A useful structure is:

What do I need to clarify?
What assumptions am I making?
What approach would I try first, and why?
What tradeoff or failure case should I mention?
How would I check whether the approach works?

You do not need a polished speech. You need enough detail to reveal where your understanding stops.

3. Check evidence rather than familiarity

Compare the explanation with primary documentation, a small reproducible example, or a reviewed source. A popular answer can still omit assumptions. A plausible explanation can still apply to the wrong framework version.

For a technical question, write down what evidence would change your answer. If performance is involved, describe what you would measure before claiming an improvement. If behavior depends on a version or configuration, name it instead of treating it as universal.

4. Record one actionable gap

Avoid a vague note such as “learn SQL.” Prefer “I could explain the symptom, but could not describe how I would inspect the execution plan.” Your next session now has a concrete starting point.

Use a simple self-assessment:

To practise: I have not attempted an explanation.
Revisit: I found a specific gap or relied on prompts.
Confident for now: I can explain my assumptions and reasoning, and have checked the important details.

This is your assessment, not a certification of correctness.

Copyable worksheet

Field	Your notes
Question and source URL
Company/role/year, only if known
Clarifying questions
Assumptions
Proposed approach and reason
Tradeoffs or failure cases
Example, test or primary reference
One gap to revisit
Next action

Start with three questions rather than a large checklist. The purpose is to produce three honest explanations and a few useful next actions—not to claim that you completed an entire technology.

A tool for keeping the shortlist

Disclosure: I am Raviindra Wadile, the creator of wasAsked. I built it to organize reported interview questions by company and technology and provide a browser-local saved/practice flow. You can browse without signing in. Community answers are available where contributors have supplied them; coverage is still developing.

The same workflow works in a notebook. The useful part is attempting an explanation, checking its assumptions and keeping a clear record of what to revisit.

Features and Updates in .NET 7

Last Bencher — Mon, 29 Jan 2024 12:50:36 +0000

.NET 7 packed with amazing features that make coding way more fun. Let's check out the best stuff.

Change on the Fly with Hot Reload:
Forget waiting around! .NET 7 lets you make changes to your code while your app is running. No need to stop and start again. It's like magic – your updates happen instantly.
Faster and Smoother with Performance Boosts:
Picture this: your apps running super-fast. That's what .NET 7 does – it makes everything speedy and efficient. Less waiting, more doing!
Cool Upgrades in C# 11:
Meet the new and improved C# 11. It's got some neat features, making your code cleaner and easier to understand. Say hello to record types and smarter pattern matching.
Easy Peasy APIs with Minimal APIs:
Building apps is now a breeze with Minimal APIs. They're like a simplified version, making it way easier to create and use APIs. Less hassle, more productivity!
Blazor Love – Dependency Injection Made Simple:
If you're a fan of Blazor, you'll love this. .NET 7 brings native support for injecting things into your Blazor apps. It's like organizing your tools – everything in its place for smoother development.

In a nutshell, .NET 7 isn't just an update – it's a game-changer. Hot Reload, performance boosts, C# 11 goodies, Minimal APIs, and Blazor enhancements make coding a joy. Embrace the awesomeness of .NET 7 and take your development skills to the next level!