DEV Community: Caner Aksu

A Better Way to Answer JavaScript Interview Questions: Example, Boundary, Failure Mode

Caner Aksu — Thu, 22 Oct 2026 12:50:58 +0000

A Better Way to Answer JavaScript Interview Questions: Example, Boundary, Failure Mode

A technically correct answer can still feel weak in an interview.

The usual problem is not missing knowledge. It is that the answer stays abstract. The candidate gives a definition, the interviewer asks “Can you give me an example?”, and the answer starts wandering.

A simple structure makes technical answers easier to follow:

Say what the thing is.
Show one small example.
State the boundary: when does that explanation stop being enough?
Name one realistic failure mode or trade-off.

I call it example, boundary, failure mode.

Example: == versus ===

A thin answer is: “== allows coercion; === compares without coercion.”

Correct, but incomplete. A stronger answer adds an example:

0 == false   // true
0 === false  // false

Then add the boundary:

In application code I default to === because it makes the comparison rules explicit. I would only use coercive equality deliberately, when I can explain the exact coercion I want.

Then the failure mode:

The risk with == is not that it is always wrong. It is that implicit coercion can make a condition pass for a value the reader did not expect.

That answer demonstrates syntax, judgement and communication.

Example: let versus var

Start with the distinction:

let is block-scoped. var is function-scoped and its declaration is hoisted.

Show it:

if (true) {
  let blockValue = 1;
  var functionValue = 2;
}

console.log(functionValue); // 2
console.log(blockValue);    // ReferenceError

State the boundary:

“Hoisted” does not mean the assignment moves to the top. The declaration is processed before execution, while the value stays undefined until the assignment runs.

Name the failure mode:

In older code, var can leak out of a block or be reused in a way that makes control flow harder to reason about. In modern code I normally use const, and let only when reassignment is intentional.

Example: “How do the frontend and backend work together?”

This question is broad, so make the boundary explicit before you answer.

I would separate the contract, transport, state and failure handling. The frontend sends a request against a documented API contract. The backend validates it, applies business rules, talks to storage or third parties, and returns a predictable response. The frontend then represents loading, success and failure states.

Give a concrete flow:

form input
→ client validation
→ POST /api/orders
→ server validation
→ database transaction
→ 201 response
→ UI confirmation

Then add failure modes:

the client and server disagree about field names or nullability;
a retry creates a duplicate operation;
the API succeeds but the UI uses stale state;
validation errors are technically returned but cannot be acted on by the user.

This shows that “working together” is not just whether a request returns 200. It is whether both sides share a contract and handle failure consistently.

Why this structure works

Interviewers are rarely testing definitions alone. They are listening for whether you can:

choose a relevant example;
distinguish a rule from a default;
notice edge cases without turning every answer into a lecture;
connect code to production behaviour;
explain a decision clearly enough for another engineer to challenge it.

You do not need to force all four parts into every answer. For a short factual question, a definition and example may be enough. For architecture, performance or debugging questions, the boundary and failure mode usually matter more.

The goal is not to sound rehearsed. The goal is to make your reasoning inspectable.

A quick practice loop

Pick one question and answer it aloud in ninety seconds:

One-sentence definition.
One small example.
One boundary or exception.
One failure mode.
One sentence connecting it to your own engineering practice.

Record yourself once. If the example takes more than half the answer, simplify it. If you never name a trade-off, add one. If the answer ends without a decision, say what you would normally do and why.

That is a more useful practice target than memorising a page of disconnected definitions.

I wrote a software-engineering interview playbook built around practical answer structures. You can judge the format using the free ten-question sample: https://payhip.com/b/Jx0YT. The full playbook is £25: https://payhip.com/b/RImif.

Disclosure: I own both linked resources. This article was produced with some AI assistance and reviewed and edited by me.

The last response is not always the latest search

Caner Aksu — Tue, 06 Oct 2026 07:18:21 +0000

Type react into a search box. Then quickly change it to react hooks.

The first request takes 900 milliseconds. The second takes 200. The newer result arrives first, but the older result arrives later and overwrites it.

Both requests succeeded. The screen still shows the wrong result.

This is a useful interview debugging exercise because the failure depends on completion order, not on a syntax error or a failed HTTP request.

Reproduce the order before changing the code

Log the query when each request starts and finishes. Deliberately delay the first response. Check which result is allowed to update the UI.

The rule you want is simple: only the latest requested search may display a result or an error.

Give each request an identity

Here is a small illustration. renderResults and renderError stand for your application's existing UI functions. The endpoint and response shape are examples.

let latestRequest = 0;

async function search(query) {
  const request = ++latestRequest;

  try {
    const response = await fetch(
      `/api/search?q=${encodeURIComponent(query)}`
    );

    if (!response.ok) {
      throw new Error(`Search failed: ${response.status}`);
    }

    const results = await response.json();
    if (request !== latestRequest) return;
    renderResults(results);
  } catch (error) {
    if (request !== latestRequest) return;
    renderError(error);
  }
}

The counter changes when a search starts. A response carries its own request number. An older response cannot pass the final comparison after a newer search has begun.

The error path needs the same check. Otherwise an old request can replace a successful new result with an irrelevant error.

This deliberately makes “latest request wins” the policy. If the newest search fails, the example displays its error. A product might instead preserve the last successful result, but that needs an explicit rule.

Cancellation and debouncing solve different parts

An AbortController can cancel an earlier fetch and consumption of its response body. That can save unnecessary client work. It does not promise that a server never received or processed the request.

Debouncing reduces how often you start a search. It does not, by itself, establish which response may update the screen. Once requests overlap, you still need a policy for stale results.

If this code belongs to a component, keep its request identity within that component's lifetime rather than sharing one global counter across unrelated search boxes. Handle component cleanup too. A framework data-fetching layer may already provide these controls.

Practise the explanation aloud

Try these follow-up questions:

Why can two successful requests produce an incorrect UI?
Why does the error branch need the same identity check?
What changes when the newest request fails?
What does cancellation save, and what does it leave uncertain?

Explain the sequence first, then the invariant your fix preserves. That gives a reviewer something concrete to check.

For more rehearsal prompts, I created a free ten-question software engineering interview sample. If the answer style is useful, the full Software Engineering Interview Playbook is £25.

References: React's data-fetching and race-condition guidance, MDN on aborting a request, and MDN on checking fetch responses.

A success message does not prove your form saved anything

Caner Aksu — Sat, 03 Oct 2026 23:00:27 +0000

A form can show a cheerful confirmation while the server rejects the request. If you're debugging that behaviour, start with a small contract: the interface should show success only after the request returns an accepted result.

Here is an illustrative handler with the state transitions separated from the request. send and setState are injected so the behaviour can be checked without a live server:

async function saveEntry(payload, send, setState) {
  setState({ status: "saving" });
  try {
    const response = await send(payload);
    if (!response.ok) throw new Error("Request was rejected");
    setState({ status: "saved" });
  } catch {
    setState({ status: "error", message: "The save could not be confirmed." });
  }
}

// Example transport, called only when the user submits:
const sendEntry = (payload) => fetch("/api/entries", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(payload)
});

An HTTP error response can still fulfil the fetch promise. Check response.ok before showing success. A network failure can reject the promise, which follows the error path here. MDN documents both behaviours: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

Three focused checks make the change reviewable:

An accepted response ends in saved.
A rejected response ends in error and never sets saved.
A thrown network error also ends in error.

The handler's saved state only means that the client received an accepted response. Verify that the API's contract actually includes a completed write. If the API returns an asynchronous acknowledgement, use a different state and check the eventual outcome. A timeout may leave the server outcome unknown; do not retry a non-idempotent write blindly. Repeated submissions need their own agreed behaviour and checks.

When explaining this in an interview, name the original failure, the boundary you checked, and why those cases establish the fix. That is more useful than narrating every file you opened.

I created a free ten-question software engineering interview sample for more rehearsal prompts: https://payhip.com/b/m4BOf. The full paid Software Engineering Interview Playbook is here: https://payhip.com/b/RImif.