DEV Community: Karuha

WebSocket Reconnects Are a State Machine: Build a Deterministic Interview Drill

Karuha — Sat, 22 Aug 2026 10:27:11 +0000

A reconnect loop is not just call connect() again after a delay. It is a small state machine with a clock, cancellation, and an upper bound. In this drill, you will build one in plain Node.js and prove four contracts: backoff grows and caps, a successful connection resets the attempt count, stopping cancels pending work, and an old timer can never start a second connection.

That last contract is the one I listen for in interviews. Most reconnect bugs are not caused by the formula. They happen when two close events schedule two timers, or when a timer created before stop() still fires after logout.

What should a reconnect controller promise?

Before writing code, write the observable behavior:

A closed socket schedules at most one reconnect attempt.
Delays grow exponentially, but never exceed a cap.
The first successful open returns the client to a clean baseline.
stop() makes future callbacks harmless.
A callback from an older schedule cannot change the current state.

This is deliberately smaller than a production WebSocket client. The point is to isolate the policy so that the policy can be tested without a real network, browser, or fake server.

A useful state vocabulary is:

idle: no connection attempt has started.
connecting: a connection attempt is in flight.
open: the socket is usable.
waiting: a reconnect timer exists.
stopped: the owner has cancelled the client.

Transitions should be explicit. If a timer callback can “just call connect,” you have hidden a transition and made it hard to reason about races.

A dependency-free controller

Save this as reconnect-drill.mjs and run it with Node 18 or newer:

import assert from "node:assert/strict";

function backoff(attempt, { base, cap, jitter = 0, random = Math.random }) {
  const exponential = Math.min(cap, base * 2 ** Math.max(0, attempt - 1));
  const spread = exponential * jitter;
  return Math.round(exponential - spread + random() * spread * 2);
}

class ReconnectController {
  constructor({ base = 250, cap = 8_000, jitter = 0, random = () => 0.5 } = {}) {
    this.base = base;
    this.cap = cap;
    this.jitter = jitter;
    this.random = random;
    this.state = "idle";
    this.attempt = 0;
    this.generation = 0;
  }

  connect() {
    if (this.state === "stopped" || this.state === "connecting" || this.state === "open") {
      return { action: "ignored", state: this.state };
    }
    this.state = "connecting";
    return { action: "connect", state: this.state };
  }

  onOpen() {
    if (this.state === "stopped") return { action: "ignored", state: this.state };
    this.attempt = 0;
    this.state = "open";
    this.generation += 1; // invalidates every older timer
    return { action: "opened", state: this.state };
  }

  onClose() {
    if (this.state === "stopped") return { action: "ignored", state: this.state };
    this.attempt += 1;
    this.state = "waiting";
    this.generation += 1;
    const token = this.generation;
    return {
      action: "scheduled",
      state: this.state,
      attempt: this.attempt,
      delay: backoff(this.attempt, {
        base: this.base,
        cap: this.cap,
        jitter: this.jitter,
        random: this.random,
      }),
      token,
    };
  }

  fire(token) {
    if (this.state === "stopped" || token !== this.generation) {
      return { action: "ignored", state: this.state };
    }
    return this.connect();
  }

  stop() {
    this.state = "stopped";
    this.generation += 1;
    return { action: "stopped", state: this.state };
  }
}

// Contract 1: exponential delay grows, then caps.
const delays = [1, 2, 3, 4, 5].map((attempt) =>
  backoff(attempt, { base: 100, cap: 700, random: () => 0.5 }),
);
assert.deepEqual(delays, [100, 200, 400, 700, 700]);

// Contract 2: an open connection resets the next failure to the base delay.
const reset = new ReconnectController({ base: 100, cap: 700 });
reset.connect();
reset.onOpen();
const afterOpen = reset.onClose();
assert.equal(afterOpen.attempt, 1);
assert.equal(afterOpen.delay, 100);

// Contract 3: stopping makes a pending timer harmless.
const stopped = new ReconnectController({ base: 100, cap: 700 });
stopped.connect();
const pending = stopped.onClose();
stopped.stop();
assert.deepEqual(stopped.fire(pending.token), { action: "ignored", state: "stopped" });

// Contract 4: an older timer cannot win a race with a newer schedule.
const stale = new ReconnectController({ base: 100, cap: 700 });
stale.connect();
const first = stale.onClose();
const second = stale.onClose();
assert.deepEqual(stale.fire(first.token), { action: "ignored", state: "waiting" });
assert.deepEqual(stale.fire(second.token), { action: "connect", state: "connecting" });

console.log("reconnect state-machine assertions passed");

Run it:

node reconnect-drill.mjs
# reconnect state-machine assertions passed

The generation value is a cheap cancellation primitive. Every operation that invalidates a timer increments it. A callback carries the generation it was created with, and fire() refuses to act when the token is old. In a browser implementation, you would still call clearTimeout() for efficiency. The token check is the correctness boundary because a callback may already be queued when clearTimeout() runs.

Why the obvious implementation fails

A common first draft looks like this:

socket.onclose = () => {
  setTimeout(connect, 500);
};

It has at least four failure modes:

Two close events create two timers and two simultaneous sockets.
A fixed delay causes many clients to reconnect together after an outage.
A successful connection does not reset the attempt counter, so a later short outage starts at a needlessly large delay.
A logout path cannot prove that a queued callback will not reconnect the user.

Exponential backoff reduces synchronized pressure, but it is not a complete strategy. In a real client, add a small random jitter, cap the delay, and decide whether the server can send a retry hint. Treat server-provided hints as untrusted input: clamp them to a policy maximum and record why they were accepted.

The policy also needs an owner. “Reconnect forever” is not a requirement; it is an accidental resource leak. A page hidden for hours, a signed-out account, or a mobile app in the background may need a stopped state. The owner should be able to cancel the loop and observe that cancellation in metrics.

How to narrate this in an interview

When asked to design reconnects, answer in this order:

State the invariant. “There is at most one pending reconnect and at most one active socket.”
Name the transitions. “Close moves to waiting; a valid timer moves to connecting; open resets attempts; stop invalidates all future work.”
Give the timing rule. “Use capped exponential backoff with jitter, for example min(cap, base * 2^(attempt-1)).”
Describe the race. “A stale timer can fire after a newer close or after logout, so every callback carries a generation token.”
Choose the recovery boundary. “Reset the attempt count only after open, not after merely starting a connection.”
Add observability. Log attempt number, chosen delay, close reason, and final stop reason. Do not log message payloads just to debug connectivity.

That explanation is stronger than reciting “use exponential backoff.” It shows you understand time, ownership, and failure ordering.

What would change in production?

The drill intentionally leaves out transport details. A production implementation still needs to answer these questions:

Is the handshake authenticated, and how are expired credentials refreshed?
Should messages be queued while waiting, or dropped with an explicit error?
Are outbound messages idempotent if a reconnect causes a retry?
Does the server close with a code that means “do not reconnect”?
How do multiple browser tabs coordinate so they do not all maintain a connection?
Which metrics distinguish a flaky client network from a server outage?

Keep those decisions outside the backoff function. That separation lets you test the policy with deterministic inputs and test the transport with a small number of integration cases.

For practice, record yourself explaining the four contracts, then replay the answer and challenge each assumption with a failure scenario. A tool such as aceround.app — AI interview assistant can generate follow-up questions, but the useful part is still the evidence: show the invariant, run the assertion, and explain the trade-off.

A compact checklist

Before shipping a reconnect loop, verify:

[ ] One active socket and one pending timer at most
[ ] Delay grows, includes bounded jitter, and has a cap
[ ] open resets the attempt counter
[ ] stop invalidates queued callbacks
[ ] Stale timers are rejected by a token or equivalent
[ ] Server retry hints are clamped
[ ] Close reasons and attempts are observable
[ ] Message replay semantics are explicit

The interview lesson is simple: a reconnect policy is a state machine with a clock. Once you write down the states and make stale work unconditionally harmless, the hard part becomes testable instead of hand-wavy.

Sources

Disclosure: I used an AI writing assistant to help outline and edit this article. I reviewed the code and claims, and the embedded Node.js assertions are intended to run as shown.

Turn a Pull Request Into a 10-Minute Technical Interview Drill

Karuha — Fri, 21 Aug 2026 02:50:46 +0000

The fastest way to make a technical answer sound generic is to rehearse it without a real change in front of you. Pick a pull request you can explain, spend 10 minutes turning its diff into a walkthrough, and you will have concrete decisions, risks, and verification steps to discuss instead of a memorized architecture speech.

This is not a trick for performing expertise you do not have. It is a way to surface work you already did: why the change exists, where it can fail, and what evidence would make you trust it.

Why use a PR instead of an interview prompt?

Interview prompts are intentionally underspecified. A real pull request is the opposite: it contains constraints. There are files, tests, callers, migrations, and review comments. That makes it a useful rehearsal artifact.

For a 45-minute technical interview, a strong answer usually needs four things:

Part	What the interviewer can learn	Evidence you can point to
Context	Why the work mattered	Issue, incident, or user path
Decision	Why this approach won	Constraints and rejected options
Safety	How you controlled risk	Tests, compatibility, rollout plan
Outcome	What you checked afterward	Metrics, logs, or manual verification

The mistake is reading the diff line by line. A reviewer can do that alone. Your job is to connect the changes to the system behavior.

A ten-minute rehearsal loop

Use this sequence once per PR. It is deliberately short enough to repeat.

Minute 0–2 — name the before-and-after. Write one sentence: “Before, X happened when Y; now, Z.” If you cannot make that sentence concrete, you are not ready to explain the change.
Minute 2–4 — choose the risk. Pick the one failure that would matter most: a stale write, an authorization bypass, a breaking API response, or a dropped background job. Do not list every theoretical risk.
Minute 4–7 — narrate the control. Explain the code path that prevents or exposes that failure. Mention the test or observable signal that backs it up.
Minute 7–10 — answer one follow-up. Ask yourself what you would change at 10× traffic, with an older client, or after a retry.

Generate the questions from a real diff

The script below is intentionally small. It reads the names of files changed against a base branch and produces follow-up prompts based on likely risk areas. It does not inspect source code or claim to understand your system. You supply the context; the script makes it harder to skip the important questions.

Save it as pr-walkthrough.mjs, then run:

git fetch origin main
node pr-walkthrough.mjs origin/main

import { execFileSync } from "node:child_process";

const base = process.argv[2] ?? "origin/main";
let raw;
try {
  raw = execFileSync("git", ["diff", "--name-status", `${base}...HEAD`], {
    encoding: "utf8",
  });
} catch (err) {
  console.error(`Could not compare ${base} with HEAD.`);
  console.error("Fetch a base branch with shared history, then try again.");
  console.error("Example: git fetch --deepen=100 origin main");
  process.exit(err.status ?? 1);
}

const rules = [
  [/^(src|app|pages)\//, "Which user-facing behavior changes, and how would you verify it manually?"],
  [/(api|router|route|server)/i, "What is the request contract, and which old callers could break?"],
  [/(db|schema|migration|prisma|drizzle)/i, "Can old and new code run against this data shape at the same time?"],
  [/(auth|permission|role|token|session)/i, "Who is allowed to take this path, and how is that checked on the server?"],
  [/(test|spec)\./i, "Which failure would this test catch that a happy-path demo would miss?"],
  [/(queue|worker|job|cron)/i, "What happens on retry, duplicate delivery, or a partial failure?"],
];

const files = raw.trim().split("\n").filter(Boolean).map((line) => {
  const [status, path] = line.split("\t");
  return { status, path };
});

if (!files.length) {
  console.error(`No changes found against ${base}. Fetch the base branch or pass a different ref.`);
  process.exit(1);
}

const questions = new Map();
for (const file of files) {
  for (const [pattern, question] of rules) {
    if (pattern.test(file.path)) questions.set(question, (questions.get(question) ?? 0) + 1);
  }
}

console.log(`# PR walkthrough: ${files.length} changed file${files.length === 1 ? "" : "s"}`);
console.log("\n## Start with the change");
for (const { status, path } of files.slice(0, 12)) console.log(`- ${status}: ${path}`);
if (files.length > 12) console.log(`- …and ${files.length - 12} more`);

console.log("\n## Rehearse these follow-ups");
for (const [question, matches] of questions) console.log(`- (${matches} file${matches === 1 ? "" : "s"}) ${question}`);
console.log("- What did you deliberately leave unchanged, and why?");
console.log("- What observable signal would tell you the rollout is safe?");

Here is what a useful result looks like for a change that touches an API route, a database migration, and tests:

# PR walkthrough: 4 changed files

## Rehearse these follow-ups
- (1 file) What is the request contract, and which old callers could break?
- (1 file) Can old and new code run against this data shape at the same time?
- (1 file) Which failure would this test catch that a happy-path demo would miss?
- What did you deliberately leave unchanged, and why?
- What observable signal would tell you the rollout is safe?

That output is a prompt sheet, not a script you should recite. Answer every line with a detail visible in the PR. “We added a migration” is not enough; “the new column is nullable first, so the old worker can continue writing while the backfill runs” is an explanation a teammate can challenge productively.

Turn one change into a concise answer

Suppose the change adds an idempotency key to a payment endpoint. A vague answer sounds like this:

“I made the endpoint retry-safe and wrote tests.”

The rehearsal version has a shape:

“Retries from the client could create two charges when the response was lost. I stored a key plus a request fingerprint before calling the provider, so the same key and payload return the first result while a conflicting payload is rejected. The test starts two requests with the same key and asserts one provider call. In production, I would watch duplicate-charge support tickets and the rate of key conflicts; an unexpected rise in conflicts suggests a client bug rather than a successful retry.”

Notice the answer is still short. It establishes a cause, a control, a proof, and a signal. If the interviewer asks about multi-region writes or provider timeouts, you now have a real boundary to discuss instead of inventing one.

What to do when the PR is too large

Large diffs create bad rehearsal sessions because they invite a tour of unrelated files. Narrow the artifact before you practice:

Select one user journey, such as “checkout after a network retry.”
Select one invariant, such as “a completed order is charged exactly once.”
Select one proof: a test, a dashboard, or a manual reproduction.
Put the remaining changes in the “what I would cover next” bucket.

This is also a good way to answer “tell me about a challenging project” without wandering through three months of work. You can say which slice you are choosing and why it best demonstrates the trade-off.

Practice the follow-up, not just the opening

The best self-check is to ask a hostile-but-fair question after each answer:

If the interviewer asks…	Do not say…	Try explaining…
“Why not just retry?”	“Retries are bad.”	Which action is safe to repeat, which one is not, and where the deduplication record lives.
“How did you test that?”	“I added unit tests.”	The exact precondition, failure mode, and invariant the test asserted.
“What would you do differently?”	“I would improve it.”	The constraint that would justify a different design: scale, consistency, cost, or time to recover.

Record one run, then listen for two failure modes: unsupported claims (“it was more scalable”) and missing evidence (“we monitored it”). Replace either with a concrete number, test name, log field, or user behavior from the work.

If you want a structured place to repeat these sessions, aceround.app — an AI interview assistant can be useful for running a mock round. Bring the PR and your own evidence; treat any feedback as a prompt to sharpen the explanation, not as a substitute for understanding the change.

Sources and disclosure

The command interface used here follows the Git documentation for git diff.
AI assistance was used for copyediting. The workflow and code were reviewed and tested by the author.

Conditional Requests Are an Interview Contract: Build an ETag Drill in Node.js

Karuha — Wed, 19 Aug 2026 08:47:31 +0000

Conditional Requests Are an Interview Contract: Build an ETag Drill in Node.js

An ETag is not just a cache header. In a backend interview, it is a compact way to show that you can define an HTTP contract, avoid needless transfer, and prevent an older edit from silently overwriting a newer one. This small Node.js drill implements both paths: 304 Not Modified for cache revalidation and 412 Precondition Failed for stale writes.

A common interview prompt sounds deceptively simple: "How would you add caching to this profile endpoint?" A weak answer jumps to Redis. A stronger one first asks what a client is allowed to reuse, how it knows that a representation changed, and what happens when two clients edit the same record.

HTTP already gives us useful vocabulary:

Request	Server condition	Result	Why it matters
`GET` with `If-None-Match`	Client's validator still matches	`304`, no body	The client reuses its cached representation
`PUT` with `If-Match`	Client's validator matches current state	`200`	The write is based on the version the client read
`PUT` with `If-Match`	Validator is stale	`412`	The server refuses a lost update
`PUT` without `If-Match`	This API requires a precondition	`428`	A caller cannot accidentally bypass concurrency control

The semantics come from RFC 9110's conditional-request section. The important part is not memorizing status codes. It is making the resource lifecycle explicit.

What are we proving?

Our tiny endpoint will preserve four properties:

A client that already has the current representation gets a 304 and no response body.
A changed representation gets a new ETag.
A write without an If-Match precondition is rejected for this resource.
A stale write cannot overwrite the current record.

That is enough to practice a complete answer without hiding the hard parts behind a framework.

Build the smallest useful contract

Save this as etag-drill.js and run it with Node 18 or later. It has no dependencies.

const assert = require("node:assert/strict");
const crypto = require("node:crypto");

const etag = (value) =>
  `"${crypto
    .createHash("sha256")
    .update(JSON.stringify(value))
    .digest("base64url")}"`;

function getProfile(headers, profile) {
  const tag = etag(profile);
  const cacheHeaders = {
    etag: tag,
    "cache-control": "private, max-age=60",
  };

  if (headers["if-none-match"] === tag) {
    return { status: 304, headers: cacheHeaders, body: null };
  }

  return { status: 200, headers: cacheHeaders, body: profile };
}

function updateProfile(headers, patch, current) {
  const currentTag = etag(current);

  if (!headers["if-match"]) {
    return {
      status: 428,
      headers: { etag: currentTag },
      body: { error: "If-Match required" },
    };
  }

  if (headers["if-match"] !== currentTag) {
    return {
      status: 412,
      headers: { etag: currentTag },
      body: { error: "stale representation" },
    };
  }

  const next = {
    ...current,
    ...patch,
    version: current.version + 1,
  };

  return {
    status: 200,
    headers: { etag: etag(next) },
    body: next,
  };
}

const profile = { id: "u1", displayName: "Mina", version: 7 };

const firstRead = getProfile({}, profile);
assert.equal(firstRead.status, 200);
assert.deepEqual(firstRead.body, profile);

const cachedRead = getProfile(
  { "if-none-match": firstRead.headers.etag },
  profile,
);
assert.equal(cachedRead.status, 304);
assert.equal(cachedRead.body, null);

assert.equal(
  updateProfile({}, { displayName: "Mina K." }, profile).status,
  428,
);

assert.equal(
  updateProfile(
    { "if-match": "\"old\"" },
    { displayName: "Mina K." },
    profile,
  ).status,
  412,
);

const accepted = updateProfile(
  { "if-match": firstRead.headers.etag },
  { displayName: "Mina K." },
  profile,
);
assert.equal(accepted.status, 200);
assert.equal(accepted.body.version, 8);
assert.notEqual(accepted.headers.etag, firstRead.headers.etag);

console.log("etag contract assertions passed");

The hash is only a stand-in for a production validator. The point is that every representation has a stable, opaque identifier, and a material change produces a different one. Clients should treat an ETag as opaque; they do not need to know whether it came from a version column, a content hash, or an object-store generation number.

Why does `304` need an empty body?

A 304 means "your stored representation is still valid." Sending the body again defeats the main purpose: a browser, mobile app, or CDN can reuse bytes it already owns. The response should still include the relevant cache metadata, especially the ETag and cache-control policy.

The private directive is intentional here. A profile may vary by viewer or contain user-specific fields, so a shared cache must not serve one person's representation to another. For a truly public resource, public can be appropriate, but only after checking authorization, locale, content encoding, and every other input that changes the response.

That caveat is a useful interview signal. "Add an ETag" is incomplete until you say what exact representation it validates.

Why is `If-Match` different from cache revalidation?

Cache revalidation asks, "Can I reuse what I read?" A guarded write asks, "Am I still editing what I read?"

Imagine two browser tabs:

Both read profile version 7 and receive ETag A.
Tab one changes the display name. The server accepts ETag A, stores version 8, and returns ETag B.
Tab two submits an older form with ETag A.
The server sees that A is no longer current and returns 412 Precondition Failed.

Without the precondition, tab two may silently erase tab one's change. With it, the client can refetch, show a conflict UI, or ask the user to merge the fields.

Notice that the example requires If-Match and returns 428 Precondition Required when it is absent. That policy is not universal. It is appropriate when a blind write would be harmful. For an append-only event endpoint, insisting on a representation validator could be needless friction. State the resource-specific rule rather than claiming one status code fits every API.

What would change in a real service?

The drill intentionally keeps state in one object. Production code needs a few decisions that should be named out loud.

Generate validators from durable state. A database version column is often cheaper and clearer than hashing a large serialized response.
Make the comparison atomic with the write. In SQL, update with both the record ID and expected version in the WHERE clause, then check whether one row changed. Reading, comparing, and writing in separate transactions reintroduces the race.
Define the representation boundary. If permissions or feature flags change the returned fields, the validator must reflect the variant the caller saw.
Use weak ETags carefully. Weak validators are useful for semantic cache equivalence, but If-Match is about avoiding conflicting updates and needs a strong validator.
Measure the result. Track revalidation rate, 304 rate, 412 conflicts, and payload bytes saved. A cache is a performance feature only if the access pattern makes it one.

Those choices turn a header-level answer into a system-design answer.

How would I say this in an interview?

A concise answer can follow this sequence:

"For reads, I would return an ETag for the exact authorized representation. Clients send it back in If-None-Match; unchanged data gets a 304 without a body. For edits, I would require If-Match and atomically compare a durable version during the update. A mismatch becomes 412 so the client can refetch instead of overwriting a newer edit. I would scope cache-control to the data sensitivity and monitor both 304 savings and 412 conflicts."

Then invite the follow-up: "Do you want the database query for the atomic update, or the client conflict-recovery flow?" That shows you have a next level without burying the interviewer in implementation detail.

For practice, say the explanation while running the assertions, then have a partner challenge one assumption at a time. An interview practice tool such as aceround.app can be useful here because the value is in responding to the follow-up, not reciting the first answer.

FAQ

Is an ETag a security control?

No. It helps a client validate freshness and can support optimistic concurrency. Authorization must still happen before a representation is read or updated. Do not rely on an unguessable-looking ETag as access control.

Should every GET return an ETag?

Not automatically. It adds the most value when clients revisit a resource and the response body is worth avoiding. Start from request patterns and payload size, then measure.

Why not use a timestamp?

A timestamp can work, but clocks and precision create awkward boundaries. A monotonic version is usually easier to compare atomically. The contract matters more than the token format.

What does the client do after a `412`?

It fetches the current representation, compares it with the user's pending edit, and either retries with the new validator or asks the user to resolve a meaningful conflict. Never blindly retry an old patch without deciding how fields should merge.

AI assistance disclosure: AI helped draft and edit this article. The example, HTTP semantics, code execution, and technical claims were reviewed before publication.

Streaming LLMs Need a Terminal Contract: A Node.js Interview Drill

Karuha — Mon, 17 Aug 2026 08:36:37 +0000

TL;DR: Streaming text is evidence of progress, not evidence of success. Treat the terminal event as part of your API contract: normalize it, test it, record it, and never silently present a partial model response as complete. That distinction makes for a much stronger AI-engineering interview answer than saying "I would use streaming for lower latency."

A streamed response can look healthy right up until it is not. Tokens appear in the UI, the socket stays open for a while, and then the connection disappears or the provider reports a non-successful finish state. If the product displays whatever arrived as a completed answer, it has converted an unknown result into a confident one.

That is a small implementation mistake with large consequences. In an AI product, a partial answer can look plausible enough to be acted on. In an interview, it is also a useful way to show that you distinguish transport progress from application completion.

This post builds a tiny Node.js contract test for that boundary. It has no SDK dependencies and is deliberately provider-neutral.

Why chunks are not a success signal

A streamed answer has at least two layers of state:

The transport layer: bytes or events are still arriving.
The generation layer: the provider has declared why generation ended.

Those states are independent. A request can emit 90% of a useful answer and then stop because it hit an output limit, a safety policy, a cancelled request, or a broken connection. The first layer says "some work happened." Only the second can say "this result is complete."

Provider event names differ, which is exactly why application code should not spread raw event checks throughout a UI. OpenAI documents lifecycle events for streaming responses, while Anthropic documents a distinct message streaming event sequence. Keep the provider-specific parsing at one adapter boundary and give the rest of the product a small, stable contract.

For this drill, the adapter produces just two relevant events:

Event	Meaning
`{ type: "text", value }`	A displayable text fragment arrived.
`{ type: "final", reason, requestId }`	The provider completed the stream and supplied an outcome.

Build the terminal contract

Here is the collector. It accepts text only when it has seen a final event with reason: "stop". It also rejects the surprisingly common bug where a late event is processed after the response has already been finalized.

function collectText(events) {
  let text = "";
  let terminal = null;

  for (const event of events) {
    if (terminal) {
      throw new Error("received an event after the terminal event");
    }

    if (event.type === "text") {
      text += event.value;
      continue;
    }

    if (event.type === "final") {
      terminal = event;
    }
  }

  if (!terminal) {
    throw new Error("stream ended without a terminal event");
  }

  if (terminal.reason !== "stop") {
    throw new Error(`stream did not complete normally: ${terminal.reason}`);
  }

  return { text, requestId: terminal.requestId };
}

The point is not that every provider literally calls the successful state stop. Map the provider's documented terminal state to your own domain vocabulary. The point is that "the iterator ended" is not a substitute for a terminal contract.

In production, I would return a tagged result instead of throwing directly from a request handler. Throwing keeps the drill compact; a real client needs a state it can render and telemetry it can aggregate.

Prove the unhappy paths

A happy-path demo is not a contract test. The valuable cases are the ones that make a partial answer tempting to show.

Save this as stream-contract-drill.mjs and run node stream-contract-drill.mjs.

import assert from "node:assert/strict";

function collectText(events) {
  let text = "";
  let terminal = null;

  for (const event of events) {
    if (terminal) {
      throw new Error("received an event after the terminal event");
    }

    if (event.type === "text") {
      text += event.value;
      continue;
    }

    if (event.type === "final") {
      terminal = event;
    }
  }

  if (!terminal) {
    throw new Error("stream ended without a terminal event");
  }

  if (terminal.reason !== "stop") {
    throw new Error(`stream did not complete normally: ${terminal.reason}`);
  }

  return { text, requestId: terminal.requestId };
}

assert.deepEqual(
  collectText([
    { type: "text", value: "Ship " },
    { type: "text", value: "the test." },
    { type: "final", reason: "stop", requestId: "req_42" },
  ]),
  { text: "Ship the test.", requestId: "req_42" },
);

assert.throws(
  () => collectText([{ type: "text", value: "half" }, { type: "final", reason: "length" }]),
  /length/,
);

assert.throws(
  () => collectText([{ type: "text", value: "half" }]),
  /without a terminal event/,
);

assert.throws(
  () =>
    collectText([
      { type: "final", reason: "stop" },
      { type: "text", value: "late" },
    ]),
  /after the terminal event/,
);

console.log("stream terminal contract assertions passed");

Those four assertions answer four different operational questions:

Does a normal stream preserve every fragment and the request identifier?
Does an output-limit termination refuse to masquerade as a full answer?
Does a dropped connection remain visibly unknown?
Does the consumer reject an ordering violation rather than corrupting a finalized answer?

A fifth worthwhile test in a real system is cancellation: assert that a client-aborted request is recorded as cancelled, not as a provider failure. That distinction matters when you decide whether the next change is a UI fix, a timeout adjustment, or a model-capacity investigation.

Decide the product behavior before you ship

Once a terminal reason is explicit, the UI and operations choices become much less vague.

Terminal state	User-facing behavior	Operational action
`stop`	Render the answer as complete.	Record latency and token counts.
`length`	Mark it incomplete; offer a deliberate continuation where safe.	Track prompt/output sizing and continuation rate.
Safety refusal	Show the refusal, not a clipped substitute.	Preserve the reason for policy and product review.
No terminal event	Say the response was interrupted.	Record provider, request ID, elapsed time, and retry eligibility.

The subtle row is retry. A blind retry can duplicate writes, tool calls, or side effects. For an idempotent text-only request, a retry or continuation may be reasonable. For an agent that can send messages or mutate data, first make the request idempotent and ensure the tool layer can distinguish "not attempted" from "attempted but response lost."

Turn it into an interview answer

When an interviewer asks how you would build a streaming AI feature, start with the user-visible latency benefit, then make the reliability boundary concrete:

"I would stream text to improve time-to-first-token, but I would not treat the arrival of chunks as completion. I would normalize provider events behind an adapter, require a terminal outcome, test successful, length-limited, interrupted, and out-of-order cases, and instrument the terminal reason with the request ID. That lets the UI be honest about partial answers and lets us decide whether a retry is safe."

That is a compact answer, but it carries several senior signals: an interface boundary, failure-state design, observability, and idempotency awareness.

For rehearsal, aceround.app is an AI interview assistant that can help keep this four-part explanation visible while you practice responding to follow-up questions under time pressure. The important part is still being able to defend the trade-off in your own words.

FAQ

Should I automatically continue every `length`-limited response?

No. A continuation can be useful for a read-only explanation, but it may repeat or contradict the partial answer. Give the continuation a clear boundary, preserve the incomplete state, and never replay a request with side effects unless the downstream action is idempotent.

Is a transport error the same as a refusal?

No. A refusal is a known terminal outcome. A disconnected stream without a terminal event is unknown. Conflating them makes support, monitoring, and user messaging worse because the recovery options differ.

Do I need this abstraction if I use only one model provider?

Yes. Even one provider can evolve event names and finish states. A narrow adapter keeps that churn out of the UI, and the test documents the behavior your product relies on.

Sources

OpenAI, Streaming responses
Anthropic, Streaming Messages

Disclosure: This article was drafted with AI assistance and reviewed, tested, and edited by the author.

Stop Guessing srcset: Build a Responsive-Image Selection Drill

Karuha — Fri, 14 Aug 2026 06:40:17 +0000

A responsive image bug is often a reasoning bug, not an HTML bug. Before adding another srcset candidate, write down three values: the image's rendered slot in CSS pixels, the device pixel ratio (DPR), and the candidate widths you actually ship. The smallest candidate that can cover the requirement is usually the useful starting point.

This post turns that sentence into a tiny JavaScript drill you can run before a frontend interview. It is deliberately smaller than a browser's real selection algorithm, but it gives you a clean way to explain srcset, sizes, DPR, and the trade-off between sharpness and transferred bytes.

What problem are `srcset` and `sizes` solving?

An image displayed at 480 CSS pixels needs roughly 960 source pixels on a 2x screen to stay sharp. Sending a 2,000-pixel asset to that slot can waste bytes; sending a 480-pixel asset can look soft. Responsive images let the browser choose among candidates before it fetches one.

The roles are easy to mix up:

Attribute or input	What it tells the browser
`srcset="... 480w, ... 960w"`	The intrinsic width of each available file
`sizes="(max-width: 600px) 100vw, 50vw"`	The expected layout slot, in CSS pixels
DPR	How many physical pixels each CSS pixel maps to
CSS	The actual rendered layout; it must agree with the `sizes` hint

The important detail: a w descriptor is not a display instruction. It says how wide the file is. The sizes attribute supplies the layout hint that makes choosing a candidate possible.

Build a selection drill

Here is a simplified chooser. It intentionally ignores network quality, browser heuristics, zoom, image format support, and cache state. Real browsers consider more than this. The point is to test the explanation you will give in an interview, not to replace the HTML standard.

import assert from "node:assert/strict";

function chooseWidth({ slotCssPx, dpr, candidates }) {
  if (!Number.isFinite(slotCssPx) || slotCssPx <= 0) {
    throw new TypeError("slotCssPx must be a positive number");
  }
  if (!Number.isFinite(dpr) || dpr <= 0) {
    throw new TypeError("dpr must be a positive number");
  }

  const widths = [...new Set(candidates)]
    .filter((width) => Number.isFinite(width) && width > 0)
    .sort((a, b) => a - b);

  if (widths.length === 0) throw new TypeError("provide at least one width");

  const required = Math.ceil(slotCssPx * dpr);
  return widths.find((width) => width >= required) ?? widths.at(-1);
}

assert.equal(
  chooseWidth({ slotCssPx: 480, dpr: 2, candidates: [480, 960, 1440] }),
  960,
);
assert.equal(
  chooseWidth({ slotCssPx: 320, dpr: 3, candidates: [480, 960, 1440] }),
  960,
);
assert.equal(
  chooseWidth({ slotCssPx: 900, dpr: 2, candidates: [480, 960, 1440] }),
  1440,
);

console.log("responsive-image selection assertions passed");

Run it with node responsive-image-drill.mjs. The first case is the common 480 CSS pixel / 2x DPR example: 960 is the first candidate that meets 960 required source pixels. The second shows that a small mobile layout can still need a large source on a dense screen. The last case makes the compromise explicit: when no candidate is large enough, the script picks the largest available file, which may still be upscaled.

Map the drill to real markup

For a card image that is full width on small screens and half the viewport on larger screens, the markup might look like this:

<img
  src="/images/profile-960.jpg"
  srcset="
    /images/profile-480.jpg 480w,
    /images/profile-960.jpg 960w,
    /images/profile-1440.jpg 1440w
  "
  sizes="(max-width: 600px) 100vw, 50vw"
  width="1440"
  height="960"
  alt="Developer reviewing a pull request"
/>

At a 480-pixel mobile viewport, 100vw tells the browser the slot is about 480 CSS pixels. At a wide viewport, 50vw gives it a smaller slot estimate. width and height reserve the aspect ratio, which helps prevent layout shifts while the image loads.

Do not copy those values blindly. If a sidebar, grid gap, or max-width changes the rendered width, update sizes too. A misleading sizes="100vw" on a narrow card can cause a browser to select a much larger resource than the layout needs.

How do you debug a candidate that looks wrong?

Start with evidence rather than an asset-size guess:

Inspect the image's rendered width in DevTools. This is your observed CSS slot.
Check window.devicePixelRatio, then multiply it by that slot for a useful first estimate.
Open the Network panel in a private window or with cache disabled and see which URL was fetched.
Compare that URL's intrinsic width with the selected slot and DPR.
Change one thing: either the candidate set, sizes, or the layout. Reload and observe again.

This sequence is useful in an interview because it separates diagnosis from a proposed fix. Saying “I would compress the image” skips the key question: was the browser given an accurate choice in the first place?

When should you use `<picture>` instead?

Use img plus width-descriptor srcset when the image content is the same and only the resolution changes. Use <picture> when the image itself should change, such as a wide desktop crop that would hide the subject on a narrow screen. That is art direction, not just resolution switching.

<picture>
  <source media="(max-width: 600px)" srcset="/images/team-close.jpg" />
  <img src="/images/team-wide.jpg" alt="Product team at a whiteboard" />
</picture>

You can also use <source type="image/avif"> with a fallback format, but treat format support as a separate decision from layout width. Mixing all of those ideas into one untested snippet is how responsive-image configuration becomes hard to reason about.

A concise interview answer

A strong answer does not need to recite the full browser algorithm:

“I first estimate the layout slot in CSS pixels, then account for DPR. With width-based srcset, I use sizes to tell the browser that slot so it can select an appropriate source before downloading it. I verify the selected resource in DevTools, and I keep image dimensions on the element to avoid layout shift. If the mobile composition needs a different crop, I switch to picture rather than shipping a smaller version of the same bad crop.”

That answer names the decision inputs, acknowledges verification, and draws the important boundary between sizing and art direction.

Where to practice the explanation

A code snippet proves that you can calculate a candidate; a mock conversation tests whether you can explain the trade-off when the constraints change. For frontend interview preparation, aceround.app — an AI interview assistant is useful as a practice setting for follow-ups such as “what happens at 3x DPR?” or “why did the browser fetch the 1440w resource?”

Use it after you can explain the fundamentals in your own words. A tool can give you more repetitions, but it should not replace opening DevTools and seeing what the browser actually requested.

References

Disclosure: AI assisted with outlining and copy editing. The examples, constraints, and technical review were checked before publication.

Persisted GraphQL Queries: Test the APQ Fallback Before Your Interview

Karuha — Thu, 13 Aug 2026 09:48:05 +0000

TL;DR: Persisted GraphQL queries are two different designs that are often described as one. Automatic persisted queries (APQ) can recover from a cache miss by sending the full document once. A strict safelist must reject an unknown hash and never learn from an arbitrary client. Make that distinction executable and your interview answer becomes a production contract instead of a vocabulary test.

A GraphQL interview question about persisted queries sounds simple: “Why send a query hash instead of the whole document?” The shallow answer is bandwidth. The useful answer is about the failure path.

A hash-only request can miss the server’s cache. The client may then retry with the complete operation, depending on the APQ policy. A security-sensitive endpoint may instead accept only build-time registered operations. If you describe these as the same behavior, you will miss the trade-off an interviewer is actually testing: who is allowed to introduce a new query?

This tutorial builds a dependency-free Node.js model for both policies. It uses SHA-256, a tiny in-memory registry, and assertions you can run with node persisted-query-contract.js.

What should happen after a hash miss?

A persisted query maps an identifier to a known GraphQL document. The identifier is commonly a SHA-256 digest of the exact query text. The request can carry only the digest, which makes the payload smaller and gives an intermediary a stable cache key.

There are two legitimate policies:

Policy	Unknown hash	Full-document retry	Typical use
APQ (automatic persisted queries)	Return a miss	Allowed once, then the server may cache it	Controlled first-party clients
Strict safelist	Reject	Rejected unless registered during deployment	Public or high-risk endpoints

Neither policy is “more GraphQL.” They are operational choices. APQ optimizes rollout convenience. A strict safelist optimizes control over query cost and attack surface. The important part is that the client can tell a recoverable miss from a permanent rejection.

A runnable contract test

Save this as persisted-query-contract.js and run it with Node 18 or newer:

const assert = require("node:assert/strict");
const crypto = require("node:crypto");

const document = "query Viewer { viewer { id name } }";
const hash = (text) => crypto.createHash("sha256").update(text).digest("hex");

class PersistedQueryServer {
  constructor({ strict = false } = {}) {
    this.strict = strict;
    this.allowlist = new Map();
  }

  register(query) {
    const id = hash(query);
    this.allowlist.set(id, query);
    return id;
  }

  execute({ id, query }) {
    const known = this.allowlist.get(id);
    if (known && query && known !== query) return { ok: false, error: "HASH_QUERY_MISMATCH" };
    if (known) return { ok: true, data: { viewer: { id: "42", name: "Ada" } } };
    if (this.strict) return { ok: false, error: "PERSISTED_QUERY_NOT_FOUND" };
    if (!query || hash(query) !== id) return { ok: false, error: "PERSISTED_QUERY_NOT_FOUND" };
    this.allowlist.set(id, query);
    return { ok: true, data: { viewer: { id: "42", name: "Ada" } } };
  }
}

const apq = new PersistedQueryServer();
const id = apq.register(document);
assert.equal(apq.execute({ id }).ok, true, "known hash should execute");

const newDocument = "query New { viewer { email } }";
const miss = apq.execute({ id: hash(newDocument) });
assert.equal(miss.error, "PERSISTED_QUERY_NOT_FOUND");
assert.equal(apq.execute({ id: hash(newDocument), query: newDocument }).ok, true, "APQ may learn a missing query only by policy");
assert.equal(apq.execute({ id: hash(newDocument) }).ok, true, "the next request can send only the hash");

const strict = new PersistedQueryServer({ strict: true });
assert.equal(strict.execute({ id }).error, "PERSISTED_QUERY_NOT_FOUND");
assert.equal(strict.allowlist.size, 0, "strict mode must not learn from clients");
assert.equal(strict.execute({ id, query: document }).error, "PERSISTED_QUERY_NOT_FOUND", "an unregistered document is still rejected");
assert.equal(apq.execute({ id, query: "query Different { viewer { id } }" }).error, "HASH_QUERY_MISMATCH");
console.log("persisted-query contract assertions passed");

The first assertions establish the happy path. A registered query executes with only its hash. An APQ miss returns a sentinel error, then the same hash plus the full document succeeds and becomes available for the next hash-only request.

The strict server behaves differently. It starts with an empty registry. An unknown hash is rejected, and even sending the full document cannot register it at request time. That is the property you want when the server should execute only operations reviewed and shipped by your application.

The final assertion catches a subtle integrity bug: a known hash paired with different query text must fail. Without that check, a proxy, cache layer, or client bug could associate one identifier with another operation.

Why the fallback must be bounded

A common implementation mistake is “retry on every GraphQL error.” That is not an APQ policy. The fallback should happen only for the explicit persisted-query-miss signal, and it should happen at most once.

A safe client sequence is:

Send the operation hash.
If the response says the hash is unknown and the endpoint allows APQ, retry once with the full query and the same hash.
For any other GraphQL error, network error, authorization failure, or validation error, stop or use the endpoint’s normal retry policy.
Record whether the fallback happened so you can measure registry drift and unexpected clients.

The distinction matters for cost. Retrying a validation error repeats work without changing the input. Retrying an authorization error can turn one request into a noisy loop. A bounded, typed fallback is easier to observe and explain.

What changes in a strict safelist?

Strict mode moves registration into deployment. Extract operations from the client build, review the manifest, and load it into the server before traffic arrives. At runtime:

Unknown hashes return a stable error such as PERSISTED_QUERY_NOT_FOUND.
Full query text is not accepted as an implicit registration request.
The server still validates variables, authorization, and resolver cost for known operations.
Removing an operation is a deployment change, not a cache eviction accident.

This is not a replacement for authorization. A safelisted query can still expose another user’s record if resolver-level access checks are missing. It is also not a replacement for depth, complexity, or timeout limits. It narrows the set of executable documents; it does not make every permitted document cheap.

For APQ, use an explicit registry policy and a bounded cache. If the registry is shared across instances, give it a durable store and an eviction strategy. If it is per-process memory, a deploy or scale-out can create a wave of misses. That is acceptable only when the client and server have a tested fallback.

How to explain this in an interview

A concise answer can follow four beats:

Contract. “The client sends a SHA-256 operation identifier. Known identifiers execute without the document.”

Failure. “On an APQ miss, the client retries once with the full document. In strict safelist mode, the server rejects and registration happens during deployment.”

Safety. “I verify the hash matches the document, keep authorization and query-cost limits, and never retry unrelated errors.”

Evidence. “I have assertions for known hashes, one-time APQ recovery, strict rejection, and hash/document mismatch.”

That answer shows you understand the protocol at the boundary where systems fail. It leaves room for the follow-up questions interviewers usually ask: how do you roll out a new operation, how do you invalidate a removed one, and what happens when two application versions are live during a deployment?

A practical rehearsal loop

Take one real operation from a project you know. Write down its exact document, variables, expected cost, and the version that introduced it. Then answer these questions out loud:

Which clients may send a full document?
What metric tells you APQ misses are rising?
Can an old mobile build still use the operation after the server deploy?
Which error is safe to retry, and which one should fail fast?
How would you revoke one query without taking the endpoint down?

You do not need a GraphQL server to rehearse this. The small contract above is enough to expose whether your explanation has a missing branch.

For candidates who want a structured rehearsal partner for technical explanations, AceRound AI — an AI interview assistant — can turn this contract into follow-up prompts and mock rounds. Use it before the interview to practice the explanation; the value is in making the trade-offs your own.

FAQ

Are persisted queries the same as query caching?

No. A persisted-query registry maps an identifier to a document. Response caching stores the result for a particular operation, variables, identity, and freshness policy. You can use one without the other.

Does APQ prevent GraphQL denial-of-service attacks?

Not by itself. APQ reduces repeated document transfer and can improve cacheability. Attackers may still send expensive registered operations, and a permissive APQ server may accept arbitrary documents after fallback. Add authorization, depth or complexity limits, timeouts, and rate limits.

Should every API use strict safelisting?

No. First-party web clients with frequent releases may prefer APQ for rollout flexibility. Public APIs, mobile clients with long upgrade tails, and endpoints with costly resolvers often benefit from a strict manifest. Choose based on who controls clients and how much query cost you can tolerate.

How do I test a real client?

Keep the contract test for policy, then add an integration test against your GraphQL transport. Assert the exact error extension, whether the fallback includes the document, and whether a second request sends only the hash. Test both an old and a new client during a rolling deployment.

Sources

GraphQL Learn, “Persisted Queries” (protocol concepts and trade-offs).
Apollo GraphQL, “Persisted GraphQL Queries with Apollo Client” (APQ request sequence).
GraphQL over HTTP specification (transport and error semantics).
Adobe Experience Manager documentation, “Persisted GraphQL queries” (GET/cache behavior).

Disclosure: I used an AI writing assistant to outline and edit this article, then reviewed the code and claims manually.

Stop Rehearsing Technical Interview Answers: Build an Evidence Ledger Instead

Karuha — Wed, 12 Aug 2026 14:17:38 +0000

Stop Rehearsing Technical Interview Answers: Build an Evidence Ledger Instead

The fastest way to make a technical interview answer more credible is not to make it longer. It is to make every important statement traceable to a decision, an observation, or a trade-off. A small evidence ledger gives you that structure. In 20 minutes, it turns a vague story such as "we improved performance" into an answer you can defend under follow-up questions.

This post builds a dependency-free Node.js reviewer for that ledger. It is useful after a mock interview, after a take-home walkthrough, or when you are preparing stories from projects you have actually worked on. The point is not to memorize a script. The point is to know what evidence you would offer when an interviewer asks, "How did you know?"

Why does a technical answer become shaky under follow-ups?

Most weak answers have a familiar shape:

"The service was slow, so I added caching and it got better."

That can be true and still leave an interviewer with four unanswered questions:

What made you believe caching was the bottleneck rather than the database, an external dependency, or an overloaded worker?
Which metric changed, and over what window?
What risk did the cache introduce?
What would have made you reverse or adjust the decision?

Those are not gotchas. They are how an interviewer distinguishes remembered terminology from engineering judgment. A defensible answer is a compact chain:

Part	What it proves	Example
Claim	You made a specific decision	"I cached inventory reads for 30 seconds."
Evidence	The decision came from observation	"Traces showed inventory accounted for 1.1 s of a 1.8 s p95."
Trade-off	You understand the cost	"A short TTL could briefly show stale stock."
Next check	You can operate the change	"I would watch checkout p95 and oversell rate."

This format works for debugging, system design, performance work, and behavioral answers about technical leadership. It also makes rehearsal more honest: if you cannot fill one cell from a real project, do not invent it. Mark it as a question to investigate before the interview.

What belongs in an evidence ledger?

Use one small record per answer, not a giant document. Keep the prompt as written because the wording often tells you what an interviewer is testing.

const answers = [
  {
    question: "How would you reduce checkout latency?",
    claim: "I would measure the slow path before changing the cache.",
    evidence: ["p95 was 1.8 s", "traces put 1.1 s in inventory"],
    tradeOff: "A short cache TTL can return briefly stale stock.",
    nextCheck: "Compare p95 and oversell rate after the change.",
  },
];

The important constraint is that evidence is plural. One number can be noisy or misleading. A latency percentile plus a trace segment, a log count plus a customer-visible symptom, or a benchmark plus a production guardrail gives you a more useful basis for a decision.

For a project you cannot disclose, preserve the relationship but generalize the value: "the dependency represented roughly two thirds of our p95" is better than pretending there was no measurement at all. Do not bring internal dashboards, credentials, or customer data into an interview.

Can a tiny script catch the holes before a mock interview?

Yes. The reviewer below accepts only four answer fields. It reports missing evidence separately from a missing trade-off, because those produce different practice tasks.

import assert from "node:assert/strict";

const blanks = (answer) =>
  ["claim", "evidence", "tradeOff", "nextCheck"].filter((field) => {
    const value = answer[field];
    return Array.isArray(value) ? value.length === 0 : !value?.trim();
  });

function review(answer) {
  const missing = blanks(answer);
  return {
    question: answer.question,
    complete: missing.length === 0,
    missing,
    evidenceCount: answer.evidence.length,
    rehearsal: missing.length === 0
      ? "State the decision, name one measurement, then volunteer the trade-off."
      : `Add ${missing.join(", ")} before rehearsing this answer.`,
  };
}

assert.deepEqual(
  review({ question: "What changed?", claim: "We shipped it.", evidence: [], tradeOff: "", nextCheck: "" }).missing,
  ["evidence", "tradeOff", "nextCheck"],
);

Run the complete version with node interview-evidence-ledger.mjs. The assertion is deliberate. A checklist that has never been exercised is easy to misunderstand in exactly the way an interview answer is easy to hand-wave.

Why not score answers with one number?

Because a single score encourages gaming. You can make an answer sound polished while leaving out the one fact that would change the decision. A field-level result gives a better next action:

Missing field	Better rehearsal move
Claim	Say exactly what you chose or changed.
Evidence	Find a metric, trace, test result, incident timeline, or code path.
Trade-off	Name the cost, failure mode, or alternative you rejected.
Next check	Define the metric, alert, rollback condition, or customer signal to watch.

How do you rehearse from the ledger without sounding rehearsed?

Use a two-pass drill.

First, answer the question in 90 seconds with the ledger hidden. Then ask yourself only one follow-up: "What evidence made that the right decision?" If you can answer it naturally, add a second follow-up about trade-offs. This mirrors a good technical conversation better than reciting a four-part template.

Second, choose exactly one missing cell to repair. Do not rewrite all of your stories in one sitting. If your cache story lacks a rollback condition, research or design that condition, add it, and rehearse the same answer once more. Small, verifiable changes compound faster than restarting your preparation every day.

Where does AI fit, and where does it not?

AI can be useful for producing follow-up questions, checking whether your spoken answer actually contains the four fields, or comparing two versions of a story. It should not become the source of your evidence. A generated benchmark, invented incident detail, or fabricated metric will collapse under a basic follow-up.

For the review stage, a transcript is more useful than memory. aceround.app, an AI interview assistant, has a transcript-review workflow that can help surface places where your answer lost its decision or measurement. Treat that output as a prompt to inspect your own work, not as a substitute for knowing it.

The durable skill is simple: connect an engineering claim to the evidence that justified it, the trade-off it accepted, and the check that would prove it wrong. Once you can do that, your answer is shorter, clearer, and much harder to shake.

FAQ

What counts as evidence in a technical interview?

Metrics, logs, traces, tests, incident timelines, code-level observations, user reports, and benchmark results can all count. State what you observed and why it changed the decision. Avoid exposing confidential values or customer information.

What if I did not own the final decision?

Say what you contributed: the investigation you ran, the options you compared, the risk you raised, or the check you owned after rollout. Clear scope is stronger than inflated ownership.

Does this work for system design interviews?

Yes. Use estimated load and constraints as evidence, name the cost of each major choice, and say what metric or failure mode would trigger a design change.

AI tools assisted with drafting and editing. The code, technical claims, structure, and links were reviewed by the author before publication.

Stop Guessing the Event Loop: Build a JavaScript Timeline Test for Interviews

Karuha — Tue, 11 Aug 2026 06:09:10 +0000

If you can predict one short program's output and explain why, you can answer most JavaScript event-loop interview follow-ups without memorizing a diagram. Start with synchronous code, drain microtasks, then let the runtime take the next task. The useful preparation step is to make that order executable.

Most event-loop answers fail because they begin with vocabulary: "macrotasks, microtasks, call stack..." The interviewer then adds one Promise.then() inside a timer and the explanation turns into guesswork.

A better answer has two parts:

State the ordering rule.
Prove it with the smallest program that exercises it.

This is a 15-minute drill for exactly that.

What should you say before writing code?

Use a precise, short opening:

JavaScript runs the current synchronous work to completion. Before the runtime takes another task such as a timer callback, it drains the microtask queue. Promise reactions and queueMicrotask use that queue; setTimeout schedules a later task.

That is a strong starting point, not a universal promise about every host API. Browsers and Node.js provide different APIs and have runtime-specific phases. In an interview, say which environment you are discussing when the question gets specific.

The practical consequence is simple: a resolved promise does not interrupt currently running synchronous code, but it usually runs before a zero-delay timer scheduled in that same turn.

Can you prove the timeline instead of narrating it?

Save this as event-loop-drill.mjs and run node event-loop-drill.mjs. It uses only Node's built-in assertion module.

import assert from "node:assert/strict";

const events = [];
const mark = (label) => events.push(label);

mark("sync: start");

setTimeout(() => {
  mark("timer: initial");
}, 0);

queueMicrotask(() => {
  mark("microtask: queueMicrotask");
});

Promise.resolve().then(() => {
  mark("microtask: promise.then");
  setTimeout(() => {
    mark("timer: scheduled by microtask");
  }, 0);
});

mark("sync: end");

await new Promise((resolve) => setTimeout(resolve, 25));

assert.deepEqual(events, [
  "sync: start",
  "sync: end",
  "microtask: queueMicrotask",
  "microtask: promise.then",
  "timer: initial",
  "timer: scheduled by microtask",
]);

console.log("event-loop timeline assertions passed");

The result has five useful facts:

Observation	What it demonstrates
Both `sync` labels appear first	The current stack finishes before callbacks run.
`queueMicrotask` precedes `Promise.then`	They were inserted into one FIFO microtask queue in that order.
Both microtasks precede the first timer	The microtask queue drains before the next timer task.
The initial timer precedes the nested timer	The first timer was scheduled earlier.
A 25 ms wait appears only in the test harness	It gives both timer callbacks time to run; it is not part of the ordering rule.

The assertion is the important bit. A console log is easy to glance at and misread. A failing assertion gives you a concrete question: did the code, the environment, or my assumption differ?

Which follow-up questions expose shallow understanding?

After you can predict the first script, change one thing at a time.

What if a timer creates a promise?

Move the promise into the first timeout:

setTimeout(() => {
  mark("timer: first");
  Promise.resolve().then(() => mark("microtask: after first timer"));
}, 0);

setTimeout(() => {
  mark("timer: second");
}, 0);

The useful explanation is not merely "promises are faster." It is: after the first timer callback returns, the runtime drains the microtasks it created before continuing to the next available task. That is why the promise reaction belongs between the two timer callbacks.

What if a microtask keeps scheduling microtasks?

This is the operational edge case:

let remaining = 3;

queueMicrotask(function repeat() {
  mark(`microtask: ${remaining}`);
  remaining -= 1;
  if (remaining > 0) queueMicrotask(repeat);
});

With a bounded counter, the timer eventually gets a turn. Without a bound, repeatedly enqueueing microtasks can delay rendering and other tasks. In production code, that is a responsiveness problem, not a clever scheduling technique.

Does `setTimeout(fn, 0)` mean immediately?

No. It means "eligible after the current work and the relevant scheduling delay." The browser may clamp or delay timers; Node's event loop has its own phases. In an interview, avoid promising an exact millisecond. Explain the relative ordering that your test establishes.

How do you turn the code into an interview answer?

Use this four-step structure when the interviewer gives you a snippet.

Name the current work. "The top-level statements run first."
List queues by insertion order. "This queues a timer, then two microtasks."
Apply the boundary. "When the current stack clears, microtasks drain before another task."
State one caveat. "The relative order is the point; exact timer timing depends on the host."

Then pause. Do not race to define every event-loop term. If asked about browser rendering, I would add that rendering is host-controlled and should not be reduced to a blanket claim that it happens after every callback. If asked about Node, I would distinguish this basic timer-and-microtask example from Node-specific scheduling APIs and phases.

That restraint matters in senior interviews. It shows that you know where the general model ends.

A 15-minute practice routine

Minutes 1-3: Predict the first script without running it.
Minutes 4-6: Run it and make the assertion pass.
Minutes 7-10: Put a promise inside the first timer and write the new expected order.
Minutes 11-13: Explain the result aloud in four steps.
Minutes 14-15: Name one host-specific caveat you would check before shipping code.

Repeat with a different ordering tomorrow. The goal is not to recite a fixed answer; it is to build a reliable way to reason under a follow-up question.

For structured rehearsals that pair technical questions with answer feedback, aceround.app - AI interview assistant is one option to use after you have built your own explanation.

FAQ

Are promises always before timers?

For the ordinary case shown here, promise reactions placed in the microtask queue run after the current synchronous code and before a later timer task. Do not generalize that into a claim about every asynchronous API or every runtime phase.

Should I mention `process.nextTick` in a Node interview?

Only when asked, or when the code uses it. It has Node-specific behavior and can distract from the standard microtask-versus-timer explanation. First establish the portable model, then discuss Node's extra scheduling semantics.

Is this enough for a frontend interview?

It is the foundation. Pair it with one real scenario: stale search responses, an event handler that schedules work, or a rendering-performance issue. The interviewer wants to see that you can use the model to prevent a bug, not only recite its terminology.

References

MDN, JavaScript execution model
MDN, Using microtasks in JavaScript

Disclosure: This article was drafted with AI assistance and reviewed for technical accuracy, examples, and wording by the author.

When One Bad Job Freezes the Queue: A Node.js Dead-Letter Drill

Karuha — Mon, 10 Aug 2026 14:12:20 +0000

Most queue failures are not "retry problems." They are routing problems. A transient timeout deserves another attempt; a malformed payload should leave the hot path; and a poison message must not hold every healthy job hostage. This short Node.js drill turns those decisions into executable assertions you can explain in a backend interview.

What is the invariant?

In an interview, start with the invariant instead of naming a broker:

Every delivery ends in exactly one observable outcome: acknowledged, retried with a bounded budget, or isolated for inspection.

That sentence is more useful than "we will use SQS" or "we will add retries." It gives you something to test.

A message should carry a stable identifier and an attempt count. The count must increase monotonically. A successful handler acknowledges the message. A retryable failure returns it to the queue, usually with backoff. A permanent failure, or a retry budget that has been exhausted, moves it to a dead-letter destination and raises an alert.

This is the core idea behind a dead-letter queue (DLQ). In Amazon SQS, a redrive policy uses maxReceiveCount\ to decide when a message is moved from the source queue to its DLQ. AWS describes the DLQ as a place to inspect and diagnose unconsumed messages, then redrive them after the cause is fixed. A DLQ is not a trash can and it is not a substitute for observability.

Which failures should retry?

The first design decision is classification.

Retry a failure when the next attempt could plausibly see a different world:

a timeout or connection reset
a temporary database outage
a downstream 429 or 503
a worker crash before the message was acknowledged

Do not retry just because an exception was thrown. A malformed payload, a missing required record, or a violated business rule will usually fail the same way forever. Retrying it burns worker capacity and can block an ordered lane.

The classifier does not need to predict the future perfectly. It needs to make the policy explicit and leave unknown errors visible. In production, you might attach an error code, a retry-after duration, and the queue name to the log entry.

A minimal routing function

Here is a dependency-free policy function. It does not pretend to be a complete broker client; it isolates the decision you should be able to defend on a whiteboard.

\`js
import assert from "node:assert/strict";

const MAX_ATTEMPTS = 3;
const retryableCodes = new Set(["ETIMEDOUT", "ECONNRESET", "429"]);

function route(message, process) {
const attempt = message.attempt + 1;

try {
process(message);
return {
action: "ack",
message: { ...message, attempt },
};
} catch (error) {
const retryable = retryableCodes.has(error.code);
const exhausted = attempt >= MAX_ATTEMPTS;

return {
  action: retryable && !exhausted ? "retry" : "dead-letter",
  message: {
    ...message,
    attempt,
    failureCode: error.code,
  },
};

}
}
`\

There are two details worth calling out.

First, attempt\ is calculated before the handler runs. The failure record therefore tells you which delivery failed, even when the handler throws immediately.

Second, "retryable" is not enough. The retry budget is a second gate. A flaky dependency can be transient for hours; without a ceiling, your queue has an infinite loop disguised as resilience.

Test the boundaries, not just the happy path

A good interview answer includes the smallest test that would catch a bad policy. Add these assertions below the function:

\`js
const timeout = Object.assign(
new Error("upstream timed out"),
{ code: "ETIMEDOUT" },
);
const invalid = Object.assign(
new Error("missing account id"),
{ code: "INVALID_PAYLOAD" },
);
const base = {
id: "evt-42",
idempotencyKey: "order-81",
attempt: 0,
};

assert.equal(
route(base, () => { throw timeout; }).action,
"retry",
);

assert.equal(
route({ ...base, attempt: 2 }, () => { throw timeout; }).action,
"dead-letter",
);

assert.equal(
route(base, () => { throw invalid; }).action,
"dead-letter",
);

assert.equal(
route(base, () => {}).action,
"ack",
);

console.log("queue routing assertions passed");
`\

Run it with Node.js and you should see:

\queue routing assertions passed \\

The useful part is not the number three. It is that the policy has four observable exits:

Input	Decision	Why
timeout on attempt 1	retry	the dependency may recover
timeout on attempt 3	dead-letter	the budget is exhausted
invalid payload	dead-letter	another delivery will not repair the data
successful handler	ack	the message can leave the source queue

What changes in a real worker?

The function above returns an action. The worker has to make that action safe.

Backoff and visibility. A retry should not immediately hammer a failing dependency. Use exponential backoff with jitter, and make the broker's visibility timeout longer than the handler's expected processing window. A timeout that expires while the handler is still running can create duplicate deliveries.

Partial batch failure. If a broker delivers ten messages at once, do not fail the whole batch because one payload is bad. Acknowledge successful records, retry only the retryable records, and dead-letter the permanent ones. The exact API differs by broker, but the contract is the same.

Per-key ordering. A DLQ can intentionally break strict ordering. AWS warns against using a DLQ with FIFO workloads when moving one message out of the sequence would change the meaning of later operations. If ordering is a hard business invariant, pause the affected partition and escalate instead of silently skipping.

Metrics. Alert on DLQ depth, age of the oldest dead-lettered message, retry rate, and per-key lag. Total queue depth alone can look healthy while one partition is stuck behind a poison message.

Replay is a new delivery

A replay is not a magical undo. It is another delivery with another chance to create a side effect.

Before redriving a message, record:

the original message id and failure reason;
the code or data change that should make the replay succeed;
a replay id or idempotency key;
the operator and timestamp;
the result of the replay.

The handler should use an idempotency key when it calls an external system. Otherwise, a message that succeeded at the payment provider but timed out before acknowledgement can be charged again on replay. Keep the original payload for diagnosis, and make the replay command rate-limited so a fixed bug does not create a second traffic spike.

For a small system, a manual redrive command plus a dashboard may be enough. For a high-volume system, put replay behind a separate worker with a canary batch, a maximum messages-per-second setting, and a kill switch.

How to say this in an interview

A concise answer can follow this sequence:

"I will classify failures into retryable and permanent."
"I will cap attempts and add backoff so a poison message cannot loop forever."
"Permanent or exhausted messages go to a DLQ with an alert and enough metadata to diagnose them."
"I will preserve idempotency across retries and replays."
"I will call out the ordering trade-off: a DLQ may be wrong for a strict FIFO workflow."
"I will test one transient failure, one exhausted retry, one permanent failure, and one success."

That answer demonstrates judgment, not just vocabulary. You are showing how the system behaves when the happy path disappears.

For a timed practice round, spend five minutes drawing the states, five minutes implementing route\, and five minutes explaining replay and ordering. A tool such as aceround.app - AI interview assistant can provide follow-up questions while you practice, but the important artifact is still your own failure policy and tests.

Sources

Disclosure: AI assistance was used for outlining and editing. The code and technical claims were reviewed and the assertions were run with Node.js 22.

Your Node.js Stream Is Not Safe Until write() Returns False

Karuha — Sat, 08 Aug 2026 02:31:45 +0000

Backpressure is not a stream feature you turn on. It is a contract you either honor or silently bypass. In Node.js, the contract is tiny: when writable.write(chunk) returns false, stop producing and wait for drain. Ignore that boolean and your "streaming" code can still queue the whole payload in memory.

That distinction makes a better backend interview answer than "streams are memory efficient." Let's prove it with a slow consumer and two producers.

What failure are we trying to reproduce?

Imagine an export endpoint reading rows quickly and sending them to a slower destination: a compressed file, an HTTP response, or object storage. The producer can create data faster than the destination can flush it.

Node buffers the excess. A buffer is useful; an unbounded queue is not.

The official Node.js backpressure guide demonstrates the stakes with a roughly 9 GB compression workload. Its normal binary peaked at about 87.8 MB of resident memory. A modified binary that always returned true from write() peaked at about 1.52 GB. That is a controlled demonstration, not a universal benchmark, but it isolates the contract very clearly: the return value limits how far the producer can outrun the consumer.

We can reproduce the shape of that failure without a 9 GB file.

How do we build a deliberately slow writable?

Create a Writable whose _write method waits 1 millisecond before acknowledging each chunk. Set highWaterMark to 16 KiB so the queue reaches its threshold quickly.

import { Writable } from "node:stream";

const HIGH_WATER_MARK = 16 * 1024;

class SlowSink extends Writable {
  constructor() {
    super({ highWaterMark: HIGH_WATER_MARK });
  }

  _write(_chunk, _encoding, callback) {
    setTimeout(callback, 1);
  }
}

highWaterMark is a threshold, not a hard memory ceiling. Once the internal queue reaches it, write() starts returning false. Already accepted chunks remain queued, and one write can take the length beyond the threshold. The caller's job is to stop adding more.

What does the broken producer do?

The broken version records canContinue and then ignores it:

for (let i = 0; i < CHUNK_COUNT; i += 1) {
  const canContinue = sink.write(chunk);
  peakQueuedBytes = Math.max(peakQueuedBytes, sink.writableLength);

  // Broken: canContinue may be false, but production continues.
}

The code is asynchronous in the least useful sense. write() returns quickly, so the loop creates all 800 chunks before the destination has processed more than a few. The event loop stays responsive, but memory becomes the waiting room.

This is the interview trap. "It does not block" does not mean "it applies flow control." Non-blocking production can still overwhelm a non-blocking consumer.

What is the smallest correct fix?

Wait for drain whenever write() returns false:

import { once } from "node:events";

for (let i = 0; i < CHUNK_COUNT; i += 1) {
  const canContinue = sink.write(chunk);
  peakQueuedBytes = Math.max(peakQueuedBytes, sink.writableLength);

  if (!canContinue) {
    await once(sink, "drain");
  }
}

The flow is a two-state protocol, not a timing guess:

drain means the buffered amount has fallen below the threshold and writing may resume. It does not mean the entire stream is finished. finish is the separate lifecycle event emitted after end() and after all accepted data has flushed.

Can we turn that claim into an executable contract?

Here is the complete dependency-free script. Save it as backpressure.mjs and run it with a current Node.js release.

import assert from "node:assert/strict";
import { once } from "node:events";
import { Writable } from "node:stream";

const HIGH_WATER_MARK = 16 * 1024;
const CHUNK_BYTES = 2 * 1024;
const CHUNK_COUNT = 800;

class SlowSink extends Writable {
  constructor() {
    super({ highWaterMark: HIGH_WATER_MARK });
  }

  _write(_chunk, _encoding, callback) {
    setTimeout(callback, 1);
  }
}

async function run({ respectBackpressure }) {
  const sink = new SlowSink();
  const chunk = Buffer.alloc(CHUNK_BYTES);
  let peakQueuedBytes = 0;

  for (let i = 0; i < CHUNK_COUNT; i += 1) {
    const canContinue = sink.write(chunk);
    peakQueuedBytes = Math.max(peakQueuedBytes, sink.writableLength);

    if (respectBackpressure && !canContinue) {
      await once(sink, "drain");
    }
  }

  sink.end();
  await once(sink, "finish");
  return peakQueuedBytes;
}

const carelessPeak = await run({ respectBackpressure: false });
const carefulPeak = await run({ respectBackpressure: true });

console.table({
  ignored: { peakQueuedBytes: carelessPeak },
  respected: { peakQueuedBytes: carefulPeak },
});

assert.ok(carelessPeak > carefulPeak * 20);
assert.ok(carefulPeak <= HIGH_WATER_MARK);
console.log("backpressure assertions passed");

On this setup, the careless producer queues roughly 1.6 MiB. The careful one stays at or below 16 KiB. The exact timing does not matter; the two assertions describe the behavior we care about.

That is worth emphasizing in an interview: test the queue bound, not how many milliseconds the machine happened to take.

When should you use `pipeline()` instead?

If you already have a readable source, transforms, and a writable destination, prefer pipeline() from node:stream/promises:

import { createReadStream, createWriteStream } from "node:fs";
import { pipeline } from "node:stream/promises";
import { createGzip } from "node:zlib";

await pipeline(
  createReadStream("large.log"),
  createGzip(),
  createWriteStream("large.log.gz"),
);

pipeline() wires backpressure between stages and propagates errors while cleaning up the chain. Manual write() plus drain is still appropriate when your producer is not itself a Readable: a database cursor, a message consumer, or a loop generating report rows.

The decision rule is simple:

Situation	Prefer
Readable → Transform → Writable	`pipeline()`
Manual producer calling `write()`	Check the boolean and await `drain`
Entire payload must be transformed at once	A buffer may be clearer; enforce a size limit

Streams are not automatically better. For a 4 KiB configuration file, buffering is simpler. Backpressure matters when payload size is unbounded or meaningfully larger than your acceptable memory budget.

How would I explain this in a backend interview?

Use four sentences:

"Backpressure is flow control between a faster producer and a slower consumer."
"In Node.js, Writable.write() returning false tells the producer to pause until drain."
"Ignoring that signal allows the internal queue and GC workload to grow with the input."
"I would use pipeline() for connected streams, or explicitly test a queue bound for a manual producer."

Then offer the trade-off: increasing highWaterMark may improve throughput by batching more work, but it increases per-stream memory. Multiply that value by concurrent requests before changing it.

If you are practicing that explanation aloud, use a follow-up that forces a decision: "Would you raise highWaterMark for 500 concurrent exports? What would you measure first?" A mock interviewer should challenge the memory math, not merely confirm the definition. aceround.app — AI interview assistant is one way to rehearse those follow-ups, but the script above is the artifact that keeps the answer honest.

Quick FAQ

Does `write()` returning `false` mean the chunk was rejected?

No. The chunk was accepted into the queue. false means stop adding more until drain.

Is `highWaterMark` a hard cap?

No. It is the threshold that changes the write() return value. A caller can exceed it by ignoring that value, and an individual chunk may also carry the queue past it.

Does `pipe()` handle backpressure?

Yes, for a normal readable-to-writable connection. For robust error propagation and cleanup across multiple stages, use pipeline().

What should a production test assert?

Assert a behavior tied to risk: bounded queued bytes, cancellation cleanup, output integrity, and error propagation. Avoid a fragile wall-clock threshold unless latency itself is the contract.

Sources

Disclosure: AI assisted with outlining and copy editing. I verified the API behavior against the Node.js documentation and ran the complete script locally before publication.

AI-Enabled Coding Interviews: Turn Model Answers Into Test Cases

Karuha — Fri, 07 Aug 2026 04:08:16 +0000

AI-Enabled Coding Interviews: Turn Model Answers Into Test Cases

The useful skill in an AI-enabled coding interview is not producing the cleverest prompt. It is turning a model's suggestion into a claim you can try to break. Give yourself one small function, one edge case the first answer is likely to miss, and one test that makes the result visible. That is a 20-minute drill you can repeat before the real round.

Some companies are experimenting with interviews where an assistant is part of the environment. That changes the signal. A candidate who can ask a model for a patch but cannot identify the patch's assumptions has not demonstrated much engineering judgment. The stronger move is to narrate a short verification loop: what the answer claims, the smallest input that challenges it, and the evidence that decides whether to keep it.

This is not a recipe for using tools where they are not permitted. Check the instructions for the round first. When a tool is explicitly part of the exercise, use it like you would use a teammate's code review: useful, fallible, and accountable.

Why does a plausible answer need a counterexample?

A generated solution often looks complete because it handles the happy path cleanly. Interviews become interesting at the boundary: empty input, duplicate work, a zero value, a stale response, a mutation that callers did not expect.

The fastest way to inspect an answer is to turn its central promise into one sentence:

Model claim	Smallest challenge	Evidence to collect
"This deduplicates records by ID."	An ID of `0`; numeric `1` and string `"1"`	Returned IDs, input immutability
"This handles invalid rows."	`null` or an object with no `id`	A clear, intentional error
"This preserves first-seen order."	The same ID appears in both lists	Exact output sequence

The table takes less than two minutes to make. It also gives you a much better explanation than "the model said this should work."

A runnable 20-minute drill

Imagine an interviewer asks you to merge two event lists. You ask an assistant for a dedupe implementation. Before accepting it, define the contract:

Each row must be an object with its own id.
The first row for an ID wins.
IDs are type-sensitive: 1 and "1" are different IDs.
The input arrays must not be mutated.
Invalid rows should fail loudly rather than disappearing.

Here is a dependency-free Node.js version with tests. Save it as merge-events.test.js and run node merge-events.test.js.

const assert = require("node:assert/strict");

function rowKey(row) {
  return `${typeof row.id}:${String(row.id)}`;
}

function mergeFirstSeen(left, right) {
  const seen = new Set();

  return [...left, ...right].filter((row) => {
    if (
      row === null ||
      typeof row !== "object" ||
      !Object.hasOwn(row, "id")
    ) {
      throw new TypeError("Every row needs its own id");
    }

    const key = rowKey(row);
    if (seen.has(key)) return false;

    seen.add(key);
    return true;
  });
}

const left = [
  { id: 0, source: "left-zero" },
  { id: 1, source: "left-number" },
];
const right = [
  { id: "1", source: "right-string" },
  { id: 0, source: "right-duplicate" },
  { id: 2, source: "right-new" },
];

assert.deepEqual(
  mergeFirstSeen(left, right).map((row) => row.id),
  [0, 1, "1", 2],
);
assert.deepEqual(left, [
  { id: 0, source: "left-zero" },
  { id: 1, source: "left-number" },
]);
assert.throws(
  () => mergeFirstSeen([{ label: "missing id" }], []),
  /needs its own id/,
);

console.log("contract holds");

The important line is not the Set. It is the test data. A truthiness check such as if (!row.id) would silently lose the valid 0 record. A coercive key could collapse 1 and "1". Neither problem is obvious from a tidy-looking implementation.

Notice the use of Object.hasOwn rather than a truthiness check. It asks whether the property is actually present, even when its value is 0, false, or an empty string. That is exactly the distinction this contract needs. The MDN reference for Object.hasOwn is worth bookmarking for these boundary checks.

How should you use the drill in an interview?

Do not read the whole test file aloud. Use a four-part narration:

State the invariant. "First-seen order matters, and I want numeric and string IDs to remain distinct."
Name the risk. "The tempting implementation is likely to mishandle a falsy ID or coerce keys."
Show one discriminating test. "I would include 0, 1, and "1" before trusting the helper."
Explain the trade-off. "This is in-memory and linear time for this call. At a database boundary, I would enforce the identity rule there as well."

That answer communicates more than algorithm recall. It shows that you can establish a contract, choose evidence, and describe where the current solution stops being sufficient.

What should you ask the model?

Specific questions create inspectable output. Avoid "write the best merge function." Instead try:

Implement a pure JavaScript function that merges two arrays, preserves first-seen order, distinguishes numeric from string IDs, rejects rows without an own id, and list three edge cases your code might still miss.

Then verify the model's response against your table. The assistant may offer a good implementation, but it can also expose an assumption you did not think to test. Either way, you leave with a stronger solution.

A useful follow-up is: "Which test would fail if the function used truthiness to validate an ID?" This forces the discussion from general confidence to a falsifiable prediction. If the answer cannot predict the failing test, it has not earned your trust.

What changes when the assistant is officially allowed?

The task is still engineering. CoderPad's discussion of AI-enabled interviews makes the case for evaluating work that resembles the job: investigate unfamiliar code, use tools deliberately, and justify decisions. That makes the verification step visible rather than optional.

A practical session plan is:

Minutes 0-4: read the code and restate the contract in your own words.
Minutes 4-9: ask for one narrow implementation or explanation, not an entire architecture.
Minutes 9-15: write two counterexamples that distinguish a robust answer from a merely plausible one.
Minutes 15-20: run the tests and practice a 60-second explanation of the result.

Practice tools such as aceround.app — an AI interview assistant can help create follow-up pressure before a live conversation. The goal of the practice is still the same: be able to defend the evidence in your own words.

FAQ

Is prompt quality more important than coding in an AI-enabled interview?

No. A clear prompt helps, but it is only the start. The stronger signal is whether you can identify the assumptions in the output and design a small test that would prove the answer wrong.

Should I write tests for every line during a timed round?

No. Choose tests with high information value. One falsy ID, one type-boundary case, and one invalid input reveal more than a long list of normal examples.

What if the model's answer passes my first tests?

Explain what the tests establish and what they do not. For this example, the helper is linear in the number of rows and deliberately in-memory. A production system may need a database uniqueness constraint, a memory limit, or a policy for later updates.

Can I use this workflow when tools are not explicitly allowed?

Use the verification mindset everywhere, but follow the interview's stated tool policy. The method does not depend on a model: turn a proposed solution into a contract, try to break it, then explain the evidence.

Sources and disclosure

CoderPad, AI in the interview is not cheating; it is the job.
DEV Community, Guidelines for AI-assisted articles.

Disclosure: This article was drafted with AI assistance and reviewed for technical accuracy.

Cursor Pagination Is an Interview Contract, Not a Database Trick

Karuha — Thu, 06 Aug 2026 02:28:39 +0000

Cursor Pagination Is an Interview Contract, Not a Database Trick

Cursor pagination is the answer when a feed must remain navigable while rows are arriving. The important part is not the encoded string. It is the contract: define one stable order, place the next query strictly after one visible row, and prove that adjacent pages neither overlap nor skip a row.

That is a much stronger interview answer than “offset gets slow, so I would use a cursor.”

What does a cursor have to mean?

A cursor is a boundary in an ordered set. It is not an arbitrary database primary key and it is not a page number in disguise.

Imagine an activity feed sorted newest first. Sorting only by createdAt DESC looks reasonable until two events share the same timestamp. If page one ends at 10:00:01, a next-page predicate such as createdAt < 10:00:01 drops every sibling created during that second. Using <= fixes the gap by creating a duplicate.

The practical fix is a unique, deterministic compound order:

ORDER BY created_at DESC, id DESC

The cursor carries both fields from the final visible row. The next page asks for rows strictly after that boundary in the same order:

WHERE created_at < :cursorCreatedAt
   OR (created_at = :cursorCreatedAt AND id < :cursorId)
ORDER BY created_at DESC, id DESC
LIMIT :pageSize + 1

The extra row answers a separate question: is there another page? Return the first pageSize rows, then derive the next cursor from the final returned row only when the extra row exists.

Can you prove the boundary instead of describing it?

Here is a dependency-free Node.js drill. It deliberately gives two rows the same timestamp, which is where a timestamp-only cursor usually fails.

const assert = require("node:assert/strict");

const compare = (a, b) =>
  b.createdAt.localeCompare(a.createdAt) || b.id.localeCompare(a.id);

const encode = ({ createdAt, id }) =>
  Buffer.from(JSON.stringify({ createdAt, id })).toString("base64url");

const decode = (token) =>
  JSON.parse(Buffer.from(token, "base64url").toString());

function page(rows, after, limit) {
  const boundary = after && decode(after);

  return rows
    .slice()
    .sort(compare)
    .filter((row) => !boundary || compare(row, boundary) > 0)
    .slice(0, limit);
}

const rows = [
  { id: "d", createdAt: "2026-08-06T10:00:02.000Z" },
  { id: "c", createdAt: "2026-08-06T10:00:01.000Z" },
  { id: "b", createdAt: "2026-08-06T10:00:01.000Z" },
  { id: "a", createdAt: "2026-08-06T10:00:00.000Z" },
];

const first = page(rows, null, 2);
const second = page(rows, encode(first.at(-1)), 2);

assert.deepEqual(first.map((row) => row.id), ["d", "c"]);
assert.deepEqual(second.map((row) => row.id), ["b", "a"]);

const delivered = [...first, ...second].map((row) => row.id);
assert.deepEqual(delivered, ["d", "c", "b", "a"]);
assert.equal(new Set(delivered).size, delivered.length);

console.log("cursor pagination assertions passed");

The last two assertions are the point of the exercise. Together, they assert the two properties a caller cares about: every expected row appears, and no row appears twice.

Why is offset not the same contract?

Offset pagination is fine for a static admin table, exports, or a result set with a fixed snapshot. It becomes misleading when new records can land before the next offset.

Suppose a client receives rows 1 through 20, then three newer rows arrive. OFFSET 20 now begins three rows later than the caller expects. Depending on the direction of writes, the client sees duplicates, gaps, or both. A cursor anchored to the last seen row does not promise a frozen universe, but it does keep moving forward from a known boundary.

That distinction matters in an interview. Say what your product needs:

Requirement	Design consequence
Infinite feed	Compound cursor and stable ordering
Jump to page 47	Offset or a separate indexed navigation model
Repeatable export	Snapshot timestamp or transaction
Newly inserted rows	Decide whether they appear only after refresh

A good answer also names the limitation. Cursor pagination cannot provide cheap random page access, and a mutable sort key can move a row across a boundary. For a timeline, prefer an immutable creation timestamp. For a ranking feed, use an explicit snapshot or accept that refreshed results can reorder.

What should the API expose?

Keep the token opaque. A base64 JSON token is convenient in a demo, but clients should not build behavior around its fields. The response shape can remain small:

{
  "items": [{ "id": "d" }, { "id": "c" }],
  "nextCursor": "eyJjcmVhdGVkQXQiOiIuLi4iLCJpZCI6ImMifQ"
}

On the server, validate decoding, field types, and expected sort version. If the feed's ordering ever changes, a versioned cursor lets the API reject old tokens clearly instead of silently returning a wrong continuation.

In a real database, index the ordering columns in the same direction as the query where the engine supports it. Then inspect the query plan with a realistic cursor, not just the first page. The first page is often cheap; the continuation query is the one this design is meant to protect.

How would I say this out loud?

My compact answer would be:

“I would define a unique order first, usually created_at DESC, id DESC. The cursor is the last visible tuple, and the next query uses a strict lexicographic predicate against that tuple. I fetch one extra row to compute hasNextPage, and I test equal timestamps because that is where gaps and duplicates appear. If the product needs page 47 or a repeatable export, I would choose a different contract.”

That is concrete enough to invite follow-up questions about indexes, snapshots, and changing rank scores.

For practice, I find it useful to explain the predicate before writing it and then let a mock interviewer challenge one assumption at a time. aceround.app, an AI interview assistant, is one option for rehearsing that kind of technical follow-up without turning the session into a memorized script.

FAQ

Why not put only the ID in the cursor?

That works only when the feed is ordered by that same unique ID. If ordering is by timestamp, score, or another field, the cursor must contain enough data to reproduce the boundary.

Should a cursor be encrypted?

Not necessarily. It should be opaque to clients and validated by the server. Sign it when tampering would create a meaningful risk or reveal sensitive data.

Does cursor pagination eliminate all consistency issues?

No. It gives a clear continuation boundary. Snapshot requirements, mutable rank fields, and deletions still need an explicit product decision.

AI assistance was used for drafting. The code and pagination invariants were reviewed and executed before publication.

DEV Community: Karuha

WebSocket Reconnects Are a State Machine: Build a Deterministic Interview Drill

What should a reconnect controller promise?

A dependency-free controller

Why the obvious implementation fails

How to narrate this in an interview

What would change in production?

A compact checklist

Sources

Turn a Pull Request Into a 10-Minute Technical Interview Drill

Why use a PR instead of an interview prompt?

A ten-minute rehearsal loop

Generate the questions from a real diff

Turn one change into a concise answer

What to do when the PR is too large

Practice the follow-up, not just the opening

Sources and disclosure

Conditional Requests Are an Interview Contract: Build an ETag Drill in Node.js

Conditional Requests Are an Interview Contract: Build an ETag Drill in Node.js

What are we proving?

Build the smallest useful contract

Why does 304 need an empty body?

Why is If-Match different from cache revalidation?

What would change in a real service?

How would I say this in an interview?

FAQ

Is an ETag a security control?

Should every GET return an ETag?

Why not use a timestamp?

What does the client do after a 412?

Streaming LLMs Need a Terminal Contract: A Node.js Interview Drill

Why chunks are not a success signal

Build the terminal contract

Prove the unhappy paths

Decide the product behavior before you ship

Turn it into an interview answer

FAQ

Should I automatically continue every length-limited response?

Is a transport error the same as a refusal?

Do I need this abstraction if I use only one model provider?

Sources

Stop Guessing srcset: Build a Responsive-Image Selection Drill

What problem are srcset and sizes solving?

Build a selection drill

Map the drill to real markup

How do you debug a candidate that looks wrong?

When should you use <picture> instead?

A concise interview answer

Where to practice the explanation

References

Persisted GraphQL Queries: Test the APQ Fallback Before Your Interview

What should happen after a hash miss?

A runnable contract test

Why the fallback must be bounded

What changes in a strict safelist?

How to explain this in an interview

A practical rehearsal loop

FAQ

Sources

Stop Rehearsing Technical Interview Answers: Build an Evidence Ledger Instead

Stop Rehearsing Technical Interview Answers: Build an Evidence Ledger Instead

Why does a technical answer become shaky under follow-ups?

What belongs in an evidence ledger?

Can a tiny script catch the holes before a mock interview?

Why not score answers with one number?

How do you rehearse from the ledger without sounding rehearsed?

Where does AI fit, and where does it not?

FAQ

What counts as evidence in a technical interview?

What if I did not own the final decision?

Does this work for system design interviews?

Stop Guessing the Event Loop: Build a JavaScript Timeline Test for Interviews

What should you say before writing code?

Can you prove the timeline instead of narrating it?

Which follow-up questions expose shallow understanding?

What if a timer creates a promise?

What if a microtask keeps scheduling microtasks?

Does setTimeout(fn, 0) mean immediately?

How do you turn the code into an interview answer?

A 15-minute practice routine

Why does `304` need an empty body?

Why is `If-Match` different from cache revalidation?

What does the client do after a `412`?

Should I automatically continue every `length`-limited response?

What problem are `srcset` and `sizes` solving?

When should you use `<picture>` instead?

Does `setTimeout(fn, 0)` mean immediately?

Should I mention `process.nextTick` in a Node interview?

When should you use `pipeline()` instead?

Does `write()` returning `false` mean the chunk was rejected?

Is `highWaterMark` a hard cap?

Does `pipe()` handle backpressure?