DEV Community: Karuha

Instagram lets you add 5 bio links now. TikTok still hides the field until 1,000 followers

Karuha — Wed, 23 Sep 2026 04:24:03 +0000

Instagram's help center says you can put five websites on a profile. That has been true since April 2023. A lot of the tutorials still circulating were written when the cap was one, so people keep asking why a second link "isn't showing up" when the field for it is sitting right there under Edit profile → Links.

TikTok is the opposite problem. There is no count. Per TikTok's own support page, the website field does not appear at all until you have 1,000 followers or a Verified Business Account. Below that, rearranging bio text will not conjure a link. The limit is a condition, not a number.

YouTube sits in the middle: up to 14 channel profile links on the About tab (YouTube Help). Links inside a regular video description are clickable once advanced features are on. The same URLs pasted into a Shorts description or a Shorts comment are not. YouTube documents that split; it still trips people because "put it in the description" sounds like one rule.

I went back to each platform's help pages on 19 September 2026 instead of trusting search snippets. Snippets cache. Help pages get edited. The two disagree for years sometimes.

What that actually changes

If you have fewer than five destinations and you live on Instagram, the native field probably does the job. You do not need a second product in the stack just to host a list of URLs.

The gap that is still real:

Instagram will not tell you which of those five links got tapped unless you wrap each one yourself.
Reordering them is five separate edits, not a drag handle.
None of those native fields exist outside the app, so there is nothing to put on a printed card or in an email signature.
TikTok's 1,000-follower gate is the sharper one. Anyone under that line has no native link at all, which is the original job a bio-link page was built for.

How to audit your own setup

Start by asking whether the platform is giving you a count or a condition.

A count (Instagram 5, YouTube 14) means you are choosing which links make the cut.
A condition (TikTok 1,000 followers) means the field does not exist yet. No amount of bio-text gymnastics will make it appear.

Instagram states the number in the first sentence of the help article. TikTok hides the threshold in the "important things to know" list under the how-to steps, which is why people skim past it.

I work on Nameplate, a one-page site for portfolios, QR codes, and digital business cards. We do not cap how many links sit on a page, free included. We also do not scrape these platform limits automatically — if TikTok drops the follower gate next quarter, someone has to notice and rewrite this by hand. That is the honest version.

Late Events Do Not Error, They Vanish: Build a Watermark Drill in Node.js

Karuha — Mon, 21 Sep 2026 10:57:15 +0000

A tumbling one-minute window closes when the watermark passes its end, not when the clock does. Seven events stamped 10:00:58 that arrive at 10:01:12 have exactly two possible fates: they correct a result you already published, or they increment a counter nobody reads. Neither one throws an exception.

That is the whole bug. Late data is not an error condition, so nothing in your dashboards turns red while the number is wrong.

Why "late" has no error path

Take a pipeline that reports purchases per region in one-minute tumbling windows. Mobile clients buffer events while they are offline and flush a batch after a reconnect, so the order events arrive on the wire is only loosely related to the timestamps inside them.

The 10:00 window is emitted at 10:01:05. A batch lands at 10:01:12 carrying seven events stamped 10:00:58 and a few stamped 10:01:03.

If the job runs with the default allowed lateness (zero, in Flink), those seven events are gone. Not delayed, not retried, not written to a dead-letter queue: dropped, because the window's state was purged a second after it fired. The metric for 10:00 is now 7 purchases short, and a pipeline that drops 3% of events has the same 5xx rate as one that drops 0%.

That is why this drill is worth an evening: the failure mode is not a crash you can grep for.

Two knobs everyone conflates

Almost everyone I have run this with reaches for one number first: how much out-of-orderness to tolerate. In Flink's vocabulary there are two, and they do different jobs.

Knob	Decides	Costs
Out-of-orderness	How far the watermark trails the newest timestamp seen	Reporting latency on every window, including the ones that were never late
Allowed lateness	How long window state survives after the first result goes out	State size: open windows × keys × retention

Out-of-orderness sets when the first result goes out. Allowed lateness sets whether a late event becomes a correction or a drop. Raising the first does not remove drops. It moves the boundary and delays everything you report.

Flink's window lifecycle is explicit about the second knob: a window is "completely removed when the time (event or processing time) passes its end timestamp plus the user-specified allowed lateness". Their example: with 5-minute tumbling windows and 1 minute of allowed lateness, the window for 12:00–12:05 is removed when the watermark passes 12:06. Internally the condition is maxTimestamp + allowedLateness, where maxTimestamp is the window end minus one millisecond.

Beam calls the same knob withAllowedLateness; Kafka Streams calls it the grace period on a windowed aggregation. The name changes, the contract does not.

Build the aggregator

Roughly 55 lines, no dependencies, no cluster. outOfOrdernessMs and allowedLatenessMs are the two knobs above, onEmit is your sink, and onDrop is the metric you should have had all along.

function createWindowAggregator({
  windowMs,
  outOfOrdernessMs = 0,
  allowedLatenessMs = 0,
  onEmit = () => {},
  onDrop = () => {},
}) {
  let maxEventTs = -Infinity;
  let watermark = -Infinity;
  let pushed = 0;
  let dropped = 0;
  const windows = new Map(); // windowStart -> { fired, revision, keys: Map<key, total> }

  const windowStartOf = (ts) => Math.floor(ts / windowMs) * windowMs;

  function fire() {
    const due = [...windows.entries()]
      .filter(([start, w]) => !w.fired && start + windowMs <= watermark)
      .sort((a, b) => a[0] - b[0]);
    for (const [start, w] of due) {
      w.fired = true;
      for (const [key, total] of w.keys) {
        onEmit({ windowStart: start, windowEnd: start + windowMs, key, total, revision: 0 });
      }
    }
  }

  function purge() {
    // Flink removes a window when the watermark passes maxTimestamp + allowedLateness,
    // where maxTimestamp is windowEnd - 1. For whole-millisecond windows that is windowEnd + lateness.
    for (const [start] of windows) {
      if (start + windowMs + allowedLatenessMs <= watermark) windows.delete(start);
    }
  }

  return {
    push(event) {
      pushed += 1;
      maxEventTs = Math.max(maxEventTs, event.ts); // monotonic: a skewed event cannot pull it back
      watermark = maxEventTs - outOfOrdernessMs;

      const start = windowStartOf(event.ts);
      const expired = start + windowMs + allowedLatenessMs <= watermark;

      if (expired) {
        dropped += 1;
        onDrop(event);
      } else {
        let w = windows.get(start);
        if (!w) {
          w = { fired: false, revision: 0, keys: new Map() };
          windows.set(start, w);
        }
        w.keys.set(event.key, (w.keys.get(event.key) ?? 0) + event.value);
        if (w.fired) {
          // This window already went out. Same (window, key), new total: a correction.
          w.revision += 1;
          onEmit({ windowStart: start, windowEnd: start + windowMs, key: event.key, total: w.keys.get(event.key), revision: w.revision });
        }
      }

      fire();
      purge();
    },
    advanceTo(ts) {
      // A source heartbeat: "nothing older than ts can still arrive". Idle partitions need this,
      // otherwise the global watermark stops moving.
      if (ts > maxEventTs) {
        maxEventTs = ts;
        watermark = maxEventTs - outOfOrdernessMs;
      }
      fire();
      purge();
    },
    watermark: () => watermark,
    stats: () => ({ pushed, dropped, openWindows: windows.size }),
  };
}

Three choices in there are the ones an interviewer will poke at.

The watermark only moves forward. maxEventTs is a running maximum, so a skewed client clock cannot resurrect purged state.

Firing and purging are separate steps. A window can fire and still be open for corrections — that is what allowed lateness buys.

Every drop is reported. Not logged as an error, because it is not one: counted, so you can chart it and alert on it.

Five contracts to prove

A correct-looking aggregator and a correct one differ in the boundary cases, and those are the drill. Five assertions, with node:assert/strict:

1. A window fires once, when the watermark crosses its end. Two events land in window [0, 60000) and nothing fires yet. Then an event at ts: 70000, with a 5-second out-of-orderness bound, moves the watermark to 65000 — and exactly one emission comes out: { windowStart: 0, key: 'us', total: 7, revision: 0 }.

2. An event inside allowed lateness is a correction, not a new row. Add an event stamped 59,500 after that emission:

w.push({ key: 'us', ts: 59_500, value: 5 });

assert.equal(out.length, 2);
assert.deepEqual(out[1], {
  windowStart: 0, windowEnd: 60_000, key: 'us', total: 12, revision: 1,
});

Same windowStart, same key, higher total, revision incremented. If your sink appends, that window now has two rows — 7 and 12 — and a downstream SUM reports 19 where the truth is 12.

3. An event past windowEnd + allowedLateness is dropped, never re-homed. This is the assertion that catches the bug people actually ship: the old window is missing from the state map, so the late event gets counted into the current one. Push an event far enough ahead to move the watermark past the purge point, then push one stamped 30,000 into that purged window. The dropped list grows by one, the emitted totals do not move, and nothing lands in the current window.

4. The watermark never goes backwards. With the same 5-second bound, push ts: 200000 (watermark 195,000), then ts: 1000. The watermark stays at 195,000 and the skewed event is dropped rather than reopening a purged window.

5. Conservation: nothing is unaccounted for. After any stream, the sum of the final totals you emitted plus the value of the events you dropped must equal the value you pushed in.

const finalTotals = (out) => {
  const t = new Map();
  for (const e of out) t.set(`${e.windowStart}:${e.key}`, e.total); // last emission per (window, key) wins
  return t;
};

const counted = [...finalTotals(out).values()].reduce((a, b) => a + b, 0);
const lostValue = dropped.reduce((a, e) => a + e.value, 0);
assert.equal(counted + lostValue, pushedValue); // pushedValue = sum of every event.value you pushed

If that identity fails, you have a bug you cannot see from any dashboard.

The naive fix, measured

The tempting response to all of this is to raise the out-of-orderness bound until nothing is late. So I ran the same 500 events through the same code with one constant changed. Event timestamps are uniformly random across a 5-minute range, replayed in a slightly shuffled arrival order (a seeded PRNG, so these numbers reproduce exactly), then flushed with a heartbeat:

Setting	Events dropped	Value never counted	Emissions before the flush
5s out-of-orderness, 30s lateness	384 of 500	1,874 of 2,429 (77%)	4
600s out-of-orderness, 30s lateness	0	0	0

Both runs satisfy the conservation identity. The second one looks perfect and costs you ten minutes of reporting delay on every window — and it still drops anything later than ten minutes. A bound is a promise about your input, not a property you can configure away. When the input does not honor the promise, the drop counter is the only thing standing between you and a number you cannot defend in a review.

What the interviewer asks next

The global watermark is a minimum, not a maximum

With multiple input partitions, the global watermark is the minimum of the per-partition watermarks. One partition whose newest event is five minutes old holds back every window downstream, no matter how far ahead the others are — and a partition that goes idle holds it back forever. That is why real jobs configure an idle timeout, and why the code above has advanceTo: a source has to be able to say "nothing older than this is coming" even when it has no events to send.

If you have only run single-partition jobs, this is the follow-up that separates "read the Flink docs" from "operated this".

How to pick the two numbers

Measure, do not guess. Take arrival_ts - event_ts per source from your ingestion log, read the p99, set allowed lateness around twice that, and alert on the drop counter. Pick the out-of-orderness bound from how much reporting delay the consumer tolerates — that is a product decision, not a data one.

The sink has to upsert

Corrections mean the same (windowStart, key) can be emitted more than once, so the sink has to upsert on that pair. Append-only inserts double-count after every correction, and delete-then-insert is not idempotent when the emit is at-least-once, which it is. "We dedupe later" only works if the dedupe key is that same pair — in which case you have built the upsert with extra steps.

Replay determinism

Because events are assigned to windows by event time and the watermark is a pure function of the maximum timestamp seen, replaying the same stream through the same code produces the same final totals. Processing-time windows do not have that property, which is why a backfill of last Tuesday disagrees with what the dashboard showed on Tuesday.

FAQ

Is the timestamp in the payload the event time?

Only if you trust the producer's clock. Client clocks drift, and a device set a day forward pushes the watermark past every open window. Validate skew at ingestion and prefer a broker timestamp when the client cannot be trusted.

Does a large allowed lateness cost anything beyond memory?

State lifetime. Every retained window keeps its keys and accumulators until the watermark passes windowEnd + allowedLateness, so lateness multiplies key space by retention. It also extends how long a correction can arrive, which downstream consumers have to be ready for either way.

What if I cannot change the pipeline?

Recompute the affected windows from the raw events — for a bounded window, a batch correction is cheaper than a streaming rewrite — publish it alongside the streaming number, and label which one is provisional. The mistake is publishing one number and letting the drop counter be the only place the difference shows up.

Where to rehearse the follow-ups

Those two questions arrive as a conversation, not as code, and that is the part a static list of questions cannot rehearse. If you want a live partner for them, aceround.app — AI interview assistant — runs mock sessions where the interviewer follows up on what you just said instead of reading the next item off a list, and its data analyst interview guide walks through the SQL, case-study, and AI-usage rounds a data loop actually puts in front of you. The drill above needs nothing but Node.

Before your next data interview

Write the aggregator above from memory, then run the five assertions until they pass without looking.
Break it on purpose: set allowed lateness to zero and watch contract 2 fail; set it to an hour and watch contract 3 stop firing. Both failures answer "why not just make the bound bigger".
In under a minute, out loud: why the global watermark is a minimum, and what an idle partition does to an otherwise ready window.
Say your sink contract in one sentence: "upsert on (window_start, key), because emissions are corrections and delivery is at-least-once."

Drafting was AI-assisted. The window lifecycle and allowedLateness semantics were checked against Flink's Windows documentation; the drop and correction numbers come from the script in this article, which prints all contracts hold on Node 24. Beam documents the same setting as withAllowedLateness in its programming guide.

Outlook's Business Card button is not a signature link

Karuha — Wed, 16 Sep 2026 04:35:47 +0000

Outlook has a button labeled Business Card. A lot of digital-card tools tell you to put a card in your email signature. Those two instructions look like they solve the same problem. They do not.

One of them attaches a real .vcf file to every message. The other is a hyperlink. Mixing them up is how you end up on Spiceworks asking why every email you send also ships a file you never attached.

Two different objects

1. A hosted card URL. You copy a public link (often a /v/ address that returns a vCard) and hyperlink your name, a line of text, or a small image. The email itself carries no contact data. The recipient has to click.

2. Outlook's native Electronic Business Card. In desktop Outlook's signature editor there is a literal Business Card button. Pick a contact from your local Outlook Contacts and Outlook drops in a card-shaped image and attaches the underlying .vcf to every message that uses that signature. Microsoft documents this. There is no toggle to keep the image and drop the attachment.

If you wanted a quiet link on your name and you used that button, the attachment is working as designed.

What a hosted `/v/` link actually sends

When the URL is a live vCard endpoint rather than a static file, a typical response looks like this:

Content-Type: text/vcard; charset=utf-8
Content-Disposition: attachment; filename="dana.vcf"

attachment is the part that makes a phone show "add to contacts" instead of dumping BEGIN:VCARD into a browser tab. The signature still only contains a hyperlink. Gmail and Outlook will not magically render a card preview from that href; nothing in the email format does that for an ordinary link.

The useful property is that the URL stays the same when you change your title. Mail already sitting in someone's inbox still points at the current card. Outlook's attached .vcf is a snapshot from the moment you built the signature.

Where each one actually shows up

Outlook's rich card view is a desktop Outlook rendering. Send that signature to Gmail or Apple Mail and the recipient usually sees a .vcf attachment and maybe an embedded image, not the paper-card layout. If most of your recipients are not on desktop Outlook, you are maintaining a feature they mostly cannot see.

A plain hyperlink degrades the same way in every client: it is a link. Image blocking does not affect it, because there is no image to block unless you added one yourself.

Setup, without fighting the wrong dialog

For the link version:

Get the public card URL.
Open the ordinary HTML/text signature editor — not Outlook's Business Card button.
Select your name, insert a hyperlink, paste the URL.
Send a test to your phone. Desktop preview is the layer least likely to show a broken link.

For Outlook's native version: place the cursor, click Business Card, pick the local contact. Keep that contact's fields current. Editing a web profile will not update it.

Gmail has no native business-card control. Hyperlink text, or insert an image and hyperlink that image. The image carries no contact data on its own.

This does not make anyone save the contact

An attached .vcf still needs the recipient to open and confirm. A hyperlink still needs a click. A name-as-link in a signature is a way for someone who already wants to reach you to save your details, not a broadcast channel. A card or QR handed over in person converts better, because it is used at the moment of interest.

If you also need a printable version of the same page, a QR code that points at the same URL is the print-side of the same object.

I work on Nameplate, which serves those /v/ links. The Outlook-vs-hyperlink split above is the same whether you host the vCard yourself or use a builder.

CodeSignal GCA Banks Your Highest Submit, Even After a Syntax Error

Karuha — Tue, 15 Sep 2026 05:00:28 +0000

The live CodeSignal GCA is four coding tasks in 70 minutes, scored 200–600. Forum threads that still quote 300–850 are describing a retired scale. The IDE only keeps a task if you hit Submit before you leave it, and it grades your highest-scoring submit even if the last one is a syntax error.

Search still returns codesignal gca, codesignal gca score, and codesignal gca 70 minutes as live queries. The first hit is CodeSignal's own knowledge base: the structure article (19 Aug 2026) and the rules and setup article (25 Jul 2026). Read those two pages before another LeetCode hard.

What is the live GCA, not the 2022 one?

CodeSignal's structure article is short: four questions of varying difficulty, you split the 70 minutes however you want, all questions are visible. The rules article adds the caveat most roundups skip: 70 minutes unless the company configured a different duration. If the invite says 90, believe the invite, not a Reddit recap of Capital One's default.

Scoring is a single Assessment Score from 200 to 600. CodeSignal documented the conversion off the old 300–850 "Coding Score" in 2023 and still publishes the 200–600 range on Understanding Assessment Score (updated 24 Aug 2026). A screenshot of an 800 from 2022 is not a 2026 cutoff.

Certified setup happens before the timer. Face photo, then photo ID, then a checkbox list of rules. The timer does not start until those steps finish. There is a Practice button on that same screen if you have never used the in-browser IDE.

Does the editor autosave when you jump to Q4?

No. The rules page is explicit: you can move between tasks, but you must submit before leaving a task or the code does not save. People lose a working Q2 because they tab over to peek at Q4, change one loop, and come back to a blank or stale editor.

Submit is cheap. The same article says you may submit as many times as you need. Do that before you touch another tab.

Which submit actually gets scored?

The highest-scoring submission for that question, not the last one. CodeSignal's wording: even if the last submit has a syntax error, the higher score is kept.

That changes the last eight minutes. A common panic move is to "just try one more rewrite" on Q3, introduce a missing colon, and assume the whole task is now zero. It is not, if an earlier submit already passed tests. The rewrite only hurts you if you never banked a green run.

What it does not do: recover work you never submitted. Highest-of-submits is not an autosave.

Practical order that matches the scoring contract:

Get a correct, slow solution on Q1 and Q2. Submit. Do not polish.
Same for Q3. Submit as soon as visible tests pass.
Only then open Q4. If you get a partial, submit the partial. Leave Q3 alone unless you still have a passing copy in the bank.

Q4 is supposed to be hard. Community writeups (including the 600/600 Medium post people still link) treat a clean Q1–Q3 plus a partial Q4 as a strong outcome. Chasing Q4 by unsaving Q3 is how a 575-shaped attempt becomes a 500-shaped attempt.

Is Cosmo or ChatGPT allowed on a certified GCA?

On the certified GCA, no. The rules FAQ is narrower than most blogs. Syntax search is allowed so you do not have to memorize every STL method. AI is not allowed, including as a syntax search. Their own examples:

Allowed: open the C++ queue reference to see which methods exist.
Not allowed: open a tutorial on how to implement a deque, because that page is helping you with the solution.

If the company sent you an AI-assisted CodeSignal assessment instead, that is a different product. The GCA rules page does not apply to that transcript. Mixing the two is the same failure mode as treating every HackerRank panel as Copilot: the invite and the in-IDE banner are the source of truth, not the brand name on the calendar invite.

aceround.app — AI interview assistant — keeps a longer GCA prep map (topic mix, score bands, what happens after you pass) at the AceRound CodeSignal GCA guide. The same desktop client also covers OA-style timed tests and the live round after. This article stays on the contract the knowledge base actually states.

What fails hidden tests after the samples pass?

Not a leaked GCA item. A stand-in for the Q2 ticket that shows up in every "I passed the examples and still timed out" thread: count index pairs i < j where a[j] - a[i] == k. Visible tests are n ≤ 200. Hidden tests go to n = 10^5.

The nested loop is correct. It is also O(n²). On the hidden file it is a timeout, not a wrong answer, which is why people screenshot green samples and still drop the task.

from collections import Counter


def count_diff_pairs_slow(a: list[int], k: int) -> int:
    # Correct. Dies at n = 1e5.
    n = len(a)
    total = 0
    for i in range(n):
        for j in range(i + 1, n):
            if a[j] - a[i] == k:
                total += 1
    return total


def count_diff_pairs(a: list[int], k: int) -> int:
    seen: Counter[int] = Counter()
    total = 0
    for x in a:
        total += seen[x - k]
        seen[x] += 1
    return total


assert count_diff_pairs([1, 3, 2, 4], 1) == 2
assert count_diff_pairs([5, 5, 5], 0) == 3

The linear version walks once, asks "how many earlier values equal x - k?", and banks that count. Same answers on the samples. Different wall clock on the hidden file.

GCA-shaped prep is this ticket, not another Hard on a whiteboard: constraints first, then a solution that survives n = 10^5, then Submit, then leave the task. If the nested loop is all you have with four minutes left, submit it anyway. A timeout on hidden tests still beats an empty editor.

Time box that matches the four-task layout:

Task	What "done" means	Budget
Q1	Samples + obvious edges, submitted	5–8 min
Q2	Linear or `n log n`, submitted	8–15 min
Q3	Working solution in the bank before you open Q4	15–25 min
Q4	Partial is a valid submit	leftover

Those buckets are community pattern, not CodeSignal SLAs. The official page only promises "varying difficulty." The budget is there so Q3 gets a submit while it still compiles.

FAQ

Does a 560 always move you forward?
No. Companies set their own cut scores. CodeSignal publishes a guide for employers on setting those thresholds. Public forums will quote Capital One / HubSpot numbers that are a year old. Treat 550 / 575 / 595 as folklore until the recruiter states a number.

Can I retake?
CodeSignal limits how often a certified GCA can be retaken inside a window. The 2024 framework writeup still circulating says three attempts in 180 days. Confirm on the account page the day you sit it; do not burn an attempt to "see the IDE." Use the Practice button on the setup screen for that.

Does tab-switching to docs.python.org fail certification?
The published example of an allowed lookup is a language reference page for methods. A how-to for the algorithm is not. If the in-IDE rule list is stricter than that FAQ, the in-IDE list wins.

Should I paste a finished answer in one shot?
Do not. Independent of whether it is allowed: you want incremental submits so a later syntax error does not leave you with nothing banked. Type it. Submit when tests go green.

What to do in the 24 hours before the invite expires

Open CodeSignal's two GCA articles, not a 2022 score conversion chart.
Run one session in their practice IDE, in the browser, with the language you will actually use.
Drill one n = 10^5 timeout ticket like the pair-count above until the linear version is muscle memory.
Decide the submit rule in advance: nothing leaves a tab without a submit, Q4 never unsaves Q3.

If a company GCA used a duration other than 70 minutes for you, drop the number in the comments. The rules page says that configuration exists. The public threads still pretend every invite is the default.

Drafting was AI-assisted. Facts in this piece were checked against CodeSignal's public knowledge base (GCA structure, 19 Aug 2026; GCA rules and setup, 25 Jul 2026; Assessment Score range, 24 Aug 2026). It is not an official CodeSignal guide and it is not a leaked question set.

NFC vs QR: which business card actually gets scanned

Karuha — Wed, 09 Sep 2026 04:33:34 +0000

NFC cards break on range, metal, and iOS confirmation. QR codes break on print density and light. Neither format is the contact data — both just deliver a URL.

A tap-to-share card works against your own phone because you know where the antenna sits. Hand the same card to someone at a conference and the tap does nothing: no vibration, no popup, nothing to tell either of you whether it even tried. The QR printed on the back of that card is usually what saves the exchange.

Both formats move the same handful of bytes: a name, a title, a URL. The difference is entirely in how those bytes get from the card to the phone.

What's actually being transmitted

An NFC business card is a small chip, usually in plastic or metal, storing an NDEF record — typically a URI, occasionally a full vCard. Tapping it against a phone's NFC antenna powers the chip (no battery) and the OS reads the record.

A QR-code card encodes the same URI as a matrix of squares. A camera reads it instead of a radio.

Neither one is "the data." Both are delivery mechanisms for a link. The two common failure modes have nothing to do with vCard fields. They're specific to radios and cameras.

Where NFC actually breaks

The phone has to be looking for a tag. Android only scans when NFC is on and the screen is unlocked. iPhone background tag reading exists since the XS; older models need an app that explicitly opens the scanner.

The tag format has to match what the OS expects. iOS's background reader only picks up specific NDEF record types, then asks the user to confirm before any app sees the data. "Tap and done" is never literally true on iPhone.

Range is short and inconsistent. Reliable reads happen within about 4cm, and that number moves by device. A card that works against your Pixel can fail against someone else's phone for no reason related to the card.

Metal defeats it outright. A metal NFC card needs an antenna cutout or it blocks its own signal. Plastic cards read more consistently. This is a design tradeoff, not a manufacturing defect.

Where QR actually breaks

The failure modes are almost the inverse: physical, not electronic.

Density scales with content. A URL encodes into a sparse, forgiving pattern. A QR holding an entire vCard (name, phone, title, address) is several times denser and needs better light, a steadier hand, and a cleaner print. Point the code at a page URL and put the .vcf behind a button on that page, not inside the code itself.

Light and print quality matter more than the code. A code that scans off a bright phone screen can fail on a badge under fluorescent conference lighting, especially if it was printed small or on a low-contrast background.

It needs a camera that recognizes QR, which every iPhone since iOS 11 and effectively every Android phone since Android 9 does natively. This is the one area where QR has had fewer compatibility surprises than NFC for years.

Cost, and who controls the card afterward

An NFC card is a physical object with a per-unit cost: plastic roughly $15–$25, metal $40 and up, before any software subscription. Some vendors in this space don't publish that subscription pricing at all.

A QR code costs nothing to generate and nothing to reprint. That's also its main hardware limitation: there's no tactile "tap" moment, and a printed code can be photographed and reused. An NFC chip can't be cloned by a photo.

A two-minute test if you already have both

Tap the NFC card against your own phone with the screen unlocked (Android only scans in that state). If nothing happens, check whether NFC is toggled on before blaming the card.
Hand the same card to someone with a different phone brand and watch what happens with no prompting from you.
Print the QR at the size you'll actually use, then scan it from arm's length under normal indoor light, not from six inches under your desk lamp.
Compare which one a stranger gets through faster, unprompted. That result matters more than either spec sheet.

What neither format fixes

Whichever one gets the tap or the scan through, it hands over a link. The first impression is the page behind it, not the transmission method.

NFC is the better fit for repeat, one-on-one taps where you know both phones support it. QR remains the more compatible option for anything printed at scale or handed to someone whose phone you can't predict.

I work on Nameplate, a page builder with tracked QR links and a vCard export. This is adapted from our longer guide. We don't sell NFC hardware.

HackerRank AI-Assisted Interview: If the Assistant Won't Write Code, Check the Question Type

Karuha — Tue, 08 Sep 2026 07:38:17 +0000

A HackerRank AI-assisted interview is a live round where the hiring company turns on an in-IDE assistant. If that assistant refuses to write a full solution, you are probably on a single-file Coding question in Guarded mode, not a broken panel. Code Repos run Unguarded, with Plan mode and Agent mode, and the interviewer sees every prompt in real time.

Google autocomplete still surfaces hackerrank ai assisted interview practice and hackerrank ai assisted interview reddit. Most of those threads collapse the format into "they gave me Copilot." The candidate knowledge base, last updated 11 days ago, is more specific than that. The format splits by question type, and the two sides do not behave the same.

What actually gets turned on?

You cannot enable the assistant yourself. HackerRank's candidate docs are blunt: it appears only when the hiring company enables it for that interview, and only on supported question types. If the panel is missing, treat the round as a standard live coding session. Using an outside model in that case is the same as any other unauthorized aid.

Two interviewer UIs exist right now. The new candidate article describes the current Interview experience. The admin article still labels itself as the legacy experience. You can tell which one you got from the workspace: a single editor vs an Agentic Development Environment with a repo, terminal, and file tree.

Default model, when the company does not pin one, is GPT-5.6 Terra. The selector can also offer Claude Opus 5 / Sonnet 5 / Haiku 4.5 and GPT-5.6 Sol / Luna. The set on screen is whatever that company configured. Do not spend the first three minutes hunting for a model that is not there.

Why does Guarded mode look broken?

This is the part Reddit threads keep misreading.

In the new Interview experience, HackerRank maps the assistant like this:

Question type	Workspace	Mode	What the assistant will do
Coding	Single-file editor	Guarded	Syntax, navigation, errors, concepts. No complete solutions.
Code Repos	Agentic Development Environment	Unguarded	Plan mode + Agent mode: investigate, generate, edit files, fix issues.

That table is from the candidate knowledge base, not a blog recap. If you paste "write the function" into a single-file Coding question and the assistant talks about the algorithm instead of dumping a passing solution, that is the product working as designed.

The legacy admin FAQ still says "in interviews the assistant operates in unguarded mode." That sentence is about the interview product as opposed to HackerRank Tests (the take-home / OA product), where the assistant stays guarded and will not reveal full solutions. It is not a promise that every live question will generate code. On legacy Coding questions, even unguarded mode only exposes Ask mode. Plan, Agent, inline completions, and model switching are documented as unavailable in Guarded mode, and they only show up on Project / Code Repository questions when Unguarded is on.

So the first diagnostic, before you panic that "AI is off":

Is the panel visible at all? If not, the company did not enable it, or this question type does not support it.
Are you in a single file or a repo? Single file → expect Ask, not an agent that rewrites the file.
Did a Pending tool call dialog appear? That is Agent mode. You have to Allow or Cancel. Ignoring it is not a stall; it is a decision the interviewer can see.

HackerRank's Summer 2026 release added 159 Plan-Build-Review repository tasks for interviews. The industry default is drifting toward the repo side. Do not walk in having only practiced LeetCode in a blank editor.

What does the interviewer actually see?

Three surfaces, all from HackerRank's own interviewer docs — not from "someone on Blind said":

Live panel. Prompts and assistant replies stream to the interviewer as they happen. Plan, Ask, and Agent are all visible. Inline completions you accept land in the shared editor.
Chat transcript in the interview report. The interview report has an AI Assistant Chat control on both Coding and Code Repos responses. Nothing you typed into the panel is off the record.
Diff View, but only on front-end, back-end, and full-stack questions. It compares the project at the start of the interview with the current tree. It is not a hidden plagiarism score. It is a "what changed" view.

HackerRank's admin FAQ also says Plan mode is optional. You can go Ask → Agent, or live in Agent the whole time. Skipping Plan is allowed. It is also obvious, because the transcript then has no plan. Interviewers are told they can weigh those Plan interactions as part of how you collaborate with AI. That is not a published numeric rubric. It is a visible absence.

Ask mode has a mechanical rule that eats people: you have to tag the problem statement. Untagged questions get generic answers. The interviewer sees you retry the same vague prompt three times. Tag it once.

You can also choose not to use the assistant at all. That is documented. It is a valid strategy on a Guarded Coding question where the panel cannot write the solution anyway. On a Code Repo ticket, sitting next to an unused agent for 40 minutes is a different signal — you are leaving a tool on the table that the format was built to watch you use.

What does a strong Code Repo session look like?

Take a ticket that shows up in real repo rounds: implement LRU cache, capacity 2, then hit the hidden eviction order.

This is the first patch models ship. get() returns the value and does not move the key to recent. The public tests still pass if they only check return values.

class LRUCache:
    def __init__(self, capacity: int):
        self.cap = capacity
        self.order = []  # oldest at index 0
        self.data = {}

    def get(self, key: int) -> int:
        if key not in self.data:
            return -1
        # missing: move key to most-recent
        return self.data[key]

    def put(self, key: int, value: int) -> None:
        if key in self.data:
            self.data[key] = value
            self.order.remove(key)
            self.order.append(key)
            return
        if len(self.data) == self.cap:
            old = self.order.pop(0)
            del self.data[old]
        self.data[key] = value
        self.order.append(key)


cache = LRUCache(2)
cache.put(1, 1)
cache.put(2, 2)
assert cache.get(1) == 1
cache.put(3, 3)
print("get(1) after put(3) =", cache.get(1))  # -1  (1 was evicted)
print("get(2) =", cache.get(2))                 # 2

The hidden test is: after get(1), key 1 is more recent than 2, so put(3) should evict 2, not 1. The agent wrote a map plus a list and forgot that get is a recency event. The code compiles. That is the trap.

A session that matches what the interviewer docs say they are watching looks like this:

Plan mode first, no code. One paragraph: hash map plus recency list, get and put both bump recency, evict the head on overflow. Edge case: get on a missing key must not shuffle the list. Plan mode, per HackerRank, does not edit files. If the plan already skipped get recency, Agent will implement the skip.
Allow the tool call, then read the diff before Accept. The Pending dialog is a gate. Cancel is a documented, legal action. Accepting a 40-line rewrite you have not read is the thing Diff View exists to show.
Say the bug out loud, then patch one line. get needs self.order.remove(key); self.order.append(key) before the return. That edit is worth more than a clean Agent dump, because the transcript now has: plan → generation → you catching the model.

Fixed get:

    def get(self, key: int) -> int:
        if key not in self.data:
            return -1
        self.order.remove(key)
        self.order.append(key)
        return self.data[key]

Rerun the same four calls. get(1) after put(3) is now 1, and get(2) is -1. That is the whole interview skill in twelve lines: the assistant wrote something that looked done, and you refused to ship it.

On a Guarded single-file question the same LRU still appears, but the assistant will not dump this class for you. Ask about "what recency means on get" or "why a dict alone is not enough." Then you type. The transcript still exists. The prompts are the answer.

How is this different from a HackerRank OA?

Do not mix the two products.

Interview (this article): a human is on the call. AI use is in the open. The report is a chat transcript, not a plagiarism flag for using the panel.

Tests / Screen (the OA / take-home): the admin FAQ says the assistant stays in Guarded mode and will not reveal full solutions. Proctoring, tab switches, and integrity reports are a different stack. "Can I use ChatGPT during the OA?" is not this format. If your recruiter said "HackerRank assessment" with no interviewer on the calendar, you are probably in Tests.

If the pipeline is OA then live, those are two preps. The OA side is take-home / timed coding. The live side is the format above. aceround.app — an AI interview assistant — is built for the live round, including catching a bad AI patch while someone is watching. The same desktop client also covers coding-test / OA practice; do not walk into Screen with Interview habits, or the other way around.

Ask the recruiter the only question that changes the plan: is this an AI-assisted Interview, or a HackerRank test? If they do not know, assume standard until the panel appears.

A 20-minute practice you can run tonight

You do not need HackerRank's IDE to rehearse the judgment the format scores.

Pick a small repo bug, not a blank-editor LeetCode. LRU, a rate limiter that uses wall-clock time, a pagination off-by-one.
Write a five-line plan in a comment. No code.
Ask any coding model for the implementation. Do not paste it in yet.
Run one hidden case you did not put in the prompt. For LRU: put 1, put 2, get 1, put 3.
Narrate the first thing the model got wrong, then patch it yourself.

If you cannot find the bug in step 4, you are not ready for Unguarded Agent mode. That is the actual practice, not memorizing Plan Mode's UI labels.

The question worth leaving in the comments: when the assistant is on, do you still write the first draft yourself, or do you start in Agent and only keep the edits you can defend?

Sources: HackerRank candidate KB — AI Assistant in Interview (updated 11 days ago); HackerRank admin KB — AI-Assisted Interviews (legacy UI, updated 8 days ago); Interview Report; Summer 2026 release notes (159 Plan-Build-Review repo tasks).

Disclosure: I used AI to help draft and edit this post. The Guarded vs Unguarded split, feature tables, and interviewer surfaces are from HackerRank's public knowledge base, checked today. The LRU example is a local Python replay, not a dump from an interview session.

The Second Worker Never Saw Job 2

Karuha — Fri, 04 Sep 2026 10:11:14 +0000

SELECT … FOR UPDATE LIMIT 1 does not mean "give me the next free job." It means "lock the first matching row, and wait if somebody else already has it." Worker 2 parks on job 1. Job 2 sits queued. SKIP LOCKED, added in PostgreSQL 9.5, is the clause that hands worker 2 the next unlocked row instead.

I replayed it on a five-row table with two workers. Same shape: CPU bored, queue depth 4, throughput 1.

What does `FOR UPDATE LIMIT 1` actually wait on?

The locking clause lives in the PostgreSQL 18 SELECT docs. Default behavior: if the row you want is already locked, you wait. NOWAIT errors. SKIP LOCKED skips.

None of FOR NO KEY UPDATE, FOR SHARE, FOR KEY SHARE, NOWAIT, or SKIP LOCKED are in the SQL standard. Postgres documented that in the same page. So "I'll write standard SQL and the queue will fan out" is not an answer.

The usual claim query looks innocent:

BEGIN;
SELECT id
FROM jobs
WHERE status = 'queued'
ORDER BY id
FOR UPDATE
LIMIT 1;

UPDATE jobs SET status = 'running' WHERE id = /* that id */;
-- work happens here, still inside the transaction
COMMIT;

Worker 1 takes job 1 and holds the row lock until COMMIT. Worker 2's identical SELECT wants job 1 first — ORDER BY id LIMIT 1 — and blocks.

Job 2 is still queued. Nobody is running it.

Why is job 2 still queued while worker 2 is idle?

Because LIMIT 1 applies to returned rows, not to "rows I am willing to wait on." Worker 2 is still trying to return job 1. It has not moved on.

Postgres is explicit about another version of this trap: "If a LIMIT is used, locking stops once enough rows have been returned to satisfy the limit (but note that rows skipped over by OFFSET will get locked)."

So:

Clause	Locked row in front of you	Job 2
`FOR UPDATE` (default)	wait	sits there
`FOR UPDATE NOWAIT`	error, transaction can abort	never attempted
`FOR UPDATE SKIP LOCKED`	skip	claimed

SKIP LOCKED shipped in PostgreSQL 9.5 ("Add SELECT option SKIP LOCKED to skip locked rows", Thomas Munro). The 18 docs still warn that skipping locked rows "provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table."

That last clause is the interview sentence. Queues: yes. Account balances: no.

Can you prove the wait without standing up Postgres?

Yes. A 70-line in-memory table is enough to encode the three lock policies and the OFFSET footgun. I ran this locally before writing the rest of the post; it printed skip-locked assertions passed.

class MiniQueue {
  constructor(ids) {
    this.rows = ids.map((id) => ({
      id, status: 'queued', lock: null, claimedBy: null,
    }));
  }

  claim(worker, { skipLocked = false, nowait = false } = {}) {
    for (const row of this.rows) {
      if (row.status !== 'queued') continue;
      if (row.lock) {
        if (skipLocked) continue;
        if (nowait) {
          const err = new Error('could not obtain lock on row in relation "jobs"');
          err.code = 'NOWAIT';
          throw err;
        }
        return { blocked: true, waitingOn: row.id, job: null };
      }
      row.lock = worker;
      row.claimedBy = worker;
      return { blocked: false, waitingOn: null, job: row.id };
    }
    return { blocked: false, waitingOn: null, job: null };
  }

  commit(worker) {
    for (const row of this.rows) {
      if (row.lock === worker) {
        row.lock = null;
        if (row.claimedBy === worker) row.status = 'running';
      }
    }
  }
}

The wait case is the one people draw wrong on a whiteboard:

const q = new MiniQueue([1, 2, 3, 4, 5]);
const a = q.claim('A');            // job 1
const b = q.claim('B');            // blocked on 1, job === null
assert(b.waitingOn === 1);
assert(q.rows.find((r) => r.id === 2).status === 'queued');

Worker B does not "fall through" to job 2. Job 2's status never changes. That is the whole bug.

Flip the flag:

const q = new MiniQueue([1, 2, 3, 4, 5]);
const a = q.claim('A', { skipLocked: true }); // 1
const b = q.claim('B', { skipLocked: true }); // 2
const c = q.claim('C', { skipLocked: true }); // 3
assert(new Set([a.job, b.job, c.job]).size === 3);

Three workers, three distinct jobs, zero waits. NOWAIT on the same setup throws could not obtain lock on row in relation "jobs" instead of skipping — which matches the 9.5 release note: it does not throw for locked rows the way NOWAIT does.

After A commits, job 1 is running and unlocked. B with SKIP LOCKED then takes job 2, not a second copy of job 1. The lock and the status are different columns in your head even when they live on the same row.

Why does `OFFSET` lock rows you never returned?

Because Postgres said so, in the sentence I quoted above. I encoded it:

selectForUpdate(worker, { offset = 0, limit = 1, skipLocked = false } = {}) {
  let skipped = 0, taken = 0;
  const locked = [], returned = [];
  for (const row of this.rows) {
    if (row.status !== 'queued') continue;
    if (row.lock) {
      if (skipLocked) continue;
      return { blocked: true, locked, returned };
    }
    row.lock = worker;
    locked.push(row.id);
    if (skipped < offset) { skipped += 1; continue; }
    if (taken < limit) {
      row.claimedBy = worker;
      returned.push(row.id);
      taken += 1;
      if (taken >= limit) break;
    }
  }
  return { blocked: false, locked, returned };
}

OFFSET 1 LIMIT 1 on jobs [1, 2, 3] returns job 2 and also locks job 1. Worker B with SKIP LOCKED is forced onto job 3.

Do not paginate a queue with OFFSET. Use WHERE id > $last or SKIP LOCKED plus a real cursor. OFFSET in a locker is how you accidentally serialize workers on a row you did not even claim.

How do you say this in the interview?

I walk it as four beats, then stop.

Name the default. FOR UPDATE LIMIT 1 waits on the first matching row. Extra workers go idle while later rows sit queued.
Name the clause. SKIP LOCKED skips rows that cannot be locked immediately. Official docs restrict that to queue-like tables because the snapshot is inconsistent on purpose.
Name the sibling. NOWAIT fails the statement. Retries of NOWAIT still stampede the same hot row. That is not a queue.
Name the footgun. OFFSET locks skipped rows. I have the sentence from the SELECT page; I do not paraphrase it.

Then the production shape: claim and UPDATE in a short transaction, COMMIT, then do the work. Holding FOR UPDATE across an HTTP call is how worker 2 waits five minutes for job 1's Stripe round-trip while job 2–5 idle.

This is not a toy pattern. Graphile Worker claims with limit ${batchSize} for update skip locked. If an interviewer asks "have you seen this outside a blog," that file is the receipt.

If you are rehearsing the same job-queue answer for a Staff-loop system-design round — multiple consumers, no double-processing, what you do when a worker dies mid-job — walk the wait / NOWAIT / SKIP LOCKED table out loud, then add the lock-hold timeout. aceround.app is the AI interview assistant I use to get pushed on the follow-up ("the worker crashed, job 1 stays running, now what?"). The SQL does not change because the interviewer added a crash; the status machine around it does.

What I still want to hear in a loop: how you recover a lock that outlived the process. SKIP LOCKED does not help you there. A locked_at timestamp plus a reclaim query does. That is a different pad.

This post was drafted with AI assistance and then edited against the PostgreSQL 18 SELECT locking clause, the PostgreSQL 9.5 release notes, and Graphile Worker's getJobs.ts. The Node assertions were run locally before publish.

Forgot client.release()? Postgres Never Sees Request 11

Karuha — Thu, 03 Sep 2026 08:27:27 +0000

If pg_stat_activity is quiet and /health is still 200, it is not slow SQL. node-postgres defaults max to 10 and connectionTimeoutMillis to 0. Skip client.release() after pool.connect(), and request 11 never reaches Postgres — it waits in a FIFO queue with no timer.

What does the interviewer actually mean by "the pool is exhausted"?

They do not mean "Postgres hit max_connections."

PostgreSQL's default max_connections is typically 100, with 3 slots reserved for superusers. That is a server cap. The Node pool is a process cap. node-postgres will create clients lazily up to max, then park extra connect() calls in a FIFO wait list until somebody calls release().

Two different ceilings, two different dashboards:

Layer	Default	What "full" looks like
`pg.Pool` in one Node process	`max: 10`	`waitingCount` climbs, handlers hang or hit `connectionTimeoutMillis`
PostgreSQL	`max_connections` ≈ 100	new backends fail; superuser still has 3 reserved slots

I have walked this on-call more than once. CPU on the database is bored. p99 on the API is 30 seconds. The missing chart is pool.waitingCount.

Why does `pool.connect()` hang instead of throwing?

Because the default timeout is not "a few seconds." It is off.

From the pool docs, connectionTimeoutMillis defaults to 0, which means no timeout. idleTimeoutMillis defaults to 10_000 (idle clients get recycled after 10 seconds). Those two numbers get swapped in people's heads. Idle recycle is not a checkout deadline.

Official warning, almost word for word: if you forget to release, further pool.connect() calls timeout or hang indefinitely when connectionTimeoutMillis is 0.

So the production shape is:

Handler calls const client = await pool.connect().
It awaits something else (a payment API, S3, another SQL client) while still holding the checkout.
Under load, all 10 slots are busy doing not-SQL.
Request 11 waits forever. The process looks "up." Postgres never saw the query.

How do you prove the checkout contract without standing up Postgres?

I do not spin Docker for this drill. The failure is the lease, not the SQL. A tiny pool with max, FIFO waiters, and connectionTimeoutMillis is enough. Save it as pool-release.mjs and run node pool-release.mjs.

import assert from "node:assert/strict";

class MiniPool {
  constructor({ max = 10, connectionTimeoutMillis = 0 } = {}) {
    this.max = max;
    this.connectionTimeoutMillis = connectionTimeoutMillis;
    this.totalCount = 0;
    this.idle = [];
    this.waiters = [];
    this.nextId = 1;
  }
  get idleCount() { return this.idle.length; }
  get waitingCount() { return this.waiters.length; }

  connect() {
    return new Promise((resolve, reject) => {
      const give = (client) => { client.busy = true; resolve(client); };
      if (this.idle.length > 0) return give(this.idle.pop());
      if (this.totalCount < this.max) {
        this.totalCount += 1;
        return give({ id: this.nextId++, busy: true, released: false });
      }
      const waiter = { resolve, reject, timer: null };
      if (this.connectionTimeoutMillis > 0) {
        waiter.timer = setTimeout(() => {
          const i = this.waiters.indexOf(waiter);
          if (i !== -1) this.waiters.splice(i, 1);
          reject(new Error(`connection timeout after ${this.connectionTimeoutMillis}ms`));
        }, this.connectionTimeoutMillis);
      }
      this.waiters.push(waiter);
    });
  }

  release(client) {
    if (!client || client.released) {
      throw new Error("cannot release a client that is not checked out");
    }
    client.busy = false;
    client.released = true;
    if (this.waiters.length > 0) {
      const waiter = this.waiters.shift();
      if (waiter.timer) clearTimeout(waiter.timer);
      waiter.resolve({ id: client.id, busy: true, released: false });
      return;
    }
    this.idle.push({ id: client.id, busy: false, released: false });
  }
}

const wait = (ms) => new Promise((r) => setTimeout(r, ms));

Eight contracts I actually run. The first two are the ones that catch people:

{
  const pool = new MiniPool({ max: 2, connectionTimeoutMillis: 40 });
  await pool.connect();
  await pool.connect();
  await assert.rejects(() => pool.connect(), /connection timeout after 40ms/);
}

{
  const pool = new MiniPool({ max: 2, connectionTimeoutMillis: 0 });
  await pool.connect();
  await pool.connect();
  let settled = false;
  pool.connect().then(() => { settled = "resolved"; }, () => { settled = "rejected"; });
  await wait(50);
  assert.equal(settled, false);
  assert.equal(pool.waitingCount, 1);
}

Then FIFO (first waiter gets the first release()), try/finally still returns the client when the query throws, a handler that holds the client across an 80ms await starves a 30ms checkout, the same handler with finally { pool.release(client) } lets the next request through, and a pool.query helper that connect/release internally can run two sequential queries on max: 1.

That last one is the docs' shortcut: pool.query borrows an idle client and puts it back. Use it for a single statement. Do not use it for a transaction. Postgres transactions are scoped to one backend. Dispatching BEGIN on client A and COMMIT on client B is how you get a "it worked on my laptop" incident.

What do you say when they ask how big `max` should be?

Leave it at 10 until you have a reason. That is not me being cute; it is the pool-sizing guide. The author (Brian Carlson, who maintains pg) writes that he usually does not bother changing the default, and that if the app is starved for connections the queries are the problem.

The napkin math they want out loud:

Postgres usable slots ≈ max_connections - superuser_reserved_connections → 100 − 3 = 97.
12 Node instances × max: 10 = 120 possible backends.
120 > 97. You will get too many connections during a deploy overlap, not during a clever SQL spike.
Safe ceiling per instance: Math.floor(97 / 12) = 8. I still would not jump there on day one. I would keep 10 and put a pooler (PgBouncer / RDS Proxy) in front before I grow instance count.

If you are on Vercel fluid compute or a long-lived container, the same default 10 is the starting point. If you are on a fully stateless worker that dies every request, you still should not set max: 1 unless you enjoy turning batched queries into a single-file line; call pool.end() when the invocation is done.

How do you narrate this in a backend / SRE interview?

I walk the incident, not the class diagram.

Symptom: API p99 blew up. Postgres CPU stayed under 10%. pg_stat_activity had a handful of idle sessions, not a lock pileup.
Mitigate first: shed load, roll back the handler that started awaiting Stripe with a checked-out client, bounce the Node pods so leaked checkouts die with the process. Do not "add max: 50" while you are on fire. That just converts a queue in Node into FATAL: remaining connection slots are reserved for superuser.
Prove the bug: a pad like the one above, plus one production metric: pool.waitingCount. If that number is above 0 while the database is idle, you are leaking checkouts or holding them across I/O.
The fix: try/finally { client.release() } for any transaction. pool.query for one-shot statements. connectionTimeoutMillis: 2000 (the number in the official example) so a leak becomes a fast 500 instead of a silent hang. 2000ms is a product choice, not a law; the law is "0 means never."
Trade-off they will poke: a short checkout timeout fails the user; a missing timeout fails every later user. I would rather fail the leaked request.

If the round is a DevOps / SRE loop, they will ask what you freeze when this burns error budget. Same answer as any saturation bug: stop shipping handlers that hold scarce leases across unbounded I/O, then add the queue metric. I keep a punch-list of those operational follow-ups on aceround.app's DevOps interview guide when I want to rehearse the incident narrative out loud.

What I would not say

I would not say "we should raise max." I would not say "Postgres is slow." I would not claim a connection pooler makes release() optional. A pooler multiplexes TCP. It does not return a client you still hold in JavaScript.

Run the pad. If contract 2 does not stay pending at 50ms, your mental model of connectionTimeoutMillis: 0 is still the idle timeout. Those are not the same knob.

Sources: node-postgres Pool API (max default 10, connectionTimeoutMillis default 0, idleTimeoutMillis default 10000, FIFO wait, must-release warning), pool sizing, PostgreSQL max_connections / superuser_reserved_connections.

This article was drafted with AI assistance and then edited against the official docs and a locally run Node pad (8 assertions). Any leftover mistake is mine.

Drain In-Flight HTTP Before Kubernetes Sends SIGKILL

Karuha — Wed, 02 Sep 2026 04:49:55 +0000

Kubernetes’s default terminationGracePeriodSeconds is 30. That is not a suggestion and it is not process.exit(0). SIGTERM means: stop taking new work, finish what you already accepted, then leave. Miss the window and kubelet sends SIGKILL. The in-flight request you already 200-OK’d on the client side never gets a body.

Google autocomplete for graceful shutdown currently offers golang, spring boot, kubernetes, and nodejs. terminationGracePeriodSeconds fills in with default, default value, 30, k8s, openshift, karpenter. kubernetes sigterm fills in with grace period, vs sigkill, timeout, pid 1. People search the signal. The interview is whether you spend the 30 seconds or throw them away.

What is the interviewer actually asking?

Most answers stop at “I listen for SIGTERM.” Node’s own process docs make that the trap. 'SIGTERM' and 'SIGINT' have default handlers that exit with 128 + signal number. The moment you install a listener, that default goes away. Node will no longer exit. If your handler calls process.exit(0) on the first tick, you did the same thing as having no handler: you tore down sockets that still had a request on them.

The Kubernetes pod-lifecycle page is more specific than a blog post. On delete, the Pod is marked Terminating. The kubelet runs any preStop hook. Then the container runtime sends TERM to process 1. When the grace period expires, remaining processes get SIGKILL. The default grace period in the Pod API is 30 seconds. preStop is not extra time. It comes out of the same 30.

sequenceDiagram
  participant K as kubelet
  participant P as PID 1
  participant S as in-flight request
  K->>P: SIGTERM (grace = 30s)
  P->>P: server.close()
  P->>S: still writing the body
  Note over K,P: preStop + drain share the 30s
  alt in-flight hits 0
    P->>K: exit 0
  else still busy at 30s
    K->>P: SIGKILL
  end

The other half of the contract sits in EndpointSlice. Terminating endpoints report ready: false, so new regular traffic should stop arriving. That does not cancel the POST that already made it onto this process. You still have to drain it.

Why doesn't `server.close()` by itself finish the job?

It stops accepting new connections. Since Node 19.0.0 it also reaps idle keep-alive sockets before the callback fires. The Node docs are explicit: server.close() “closes all connections connected to this server which are not sending a request or waiting for a response.” Active requests stay. That is the correct default. You want those to finish.

Two follow-ups the interviewer will poke.

First: you are on Node 18 in production. Then close() does not reap idle keep-alive. server.close() never fires because a phone from 40 seconds ago is still sitting in keep-alive. The documented escape is closeIdleConnections(), called after close(), because a connection accepted between the two calls would otherwise race. Node 19 made that automatic. Libraries that still support 18 call it anyway. Harmless on 24.

Second: a request that will not finish inside the grace period. A 2-minute report download. A webhook you forwarded to a partner who is slow. close() waits forever. Kubernetes does not. At second 30 you get SIGKILL and the client sees a TCP reset. The Node API for that case is closeAllConnections(), again after close(). It is forceful. The docs say so. Use it as the deadline, not as step one.

How small is the pad version?

A gate, not an http.Server. Clock and grace are injected so the tests do not sleep. wrap is the request. begin is SIGTERM. wait is “I am allowed to exit.” tickForce is second 30.

const REFUSED = "refused";
const FORCED = "forced";
const DRAINED = "drained";

function createShutdownGate({ now, graceMs = 30_000 } = {}) {
  let draining = false;
  let forceAt = null;
  let inFlight = 0;
  const waiters = [];
  const events = [];

  function maybeResolve() {
    if (inFlight === 0) {
      for (const w of waiters.splice(0)) w({ ok: true, reason: DRAINED });
    }
  }

  function begin() {
    if (draining) return;
    draining = true;
    forceAt = now() + graceMs;
    events.push("begin");
  }

  function wrap(work) {
    if (draining) {
      events.push("refuse");
      return Promise.reject(Object.assign(new Error(REFUSED), { code: REFUSED }));
    }
    inFlight += 1;
    events.push("accept");
    return Promise.resolve()
      .then(work)
      .finally(() => {
        inFlight -= 1;
        maybeResolve();
      });
  }

  function wait() {
    if (!draining) throw new Error("wait_before_begin");
    if (inFlight === 0) return Promise.resolve({ ok: true, reason: DRAINED });
    if (forceAt !== null && now() >= forceAt) {
      events.push("force");
      return Promise.resolve({ ok: false, reason: FORCED, inFlight });
    }
    return new Promise((resolve) => waiters.push(resolve));
  }

  function tickForce() {
    if (!draining || forceAt === null || now() < forceAt) return null;
    if (waiters.length === 0 && inFlight === 0) {
      return { ok: true, reason: DRAINED };
    }
    events.push("force");
    const leftover = inFlight;
    for (const w of waiters.splice(0)) {
      w({ ok: false, reason: FORCED, inFlight: leftover });
    }
    return { ok: false, reason: FORCED, inFlight: leftover };
  }

  return { begin, wrap, wait, tickForce, isDraining: () => draining, inFlight: () => inFlight, events: () => events.slice() };
}

Production wires begin to process.on("SIGTERM"), wrap around the request listener, wait to server.close()'s callback, and tickForce to closeAllConnections(). The pad exists so you can fail the contracts in 20 seconds without standing up kubelet.

Which four contracts do you have to show?

Contract 1: a request accepted before SIGTERM still completes. New work after begin is refused. Event order is accept, begin, refuse.

const clock = { t: 0 };
const gate = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });

const slow = gate.wrap(
  () => new Promise((resolve) => setImmediate(() => resolve("ok-inflight"))),
);
gate.begin();
assert.equal(gate.inFlight(), 1);
await assert.rejects(() => gate.wrap(async () => "should-not-run"), { code: REFUSED });
assert.equal((await gate.wait()).reason, DRAINED);
assert.equal(await slow, "ok-inflight");
assert.deepEqual(gate.events(), ["accept", "begin", "refuse"]);

That is the whole drain. If you cannot show this, you do not have graceful shutdown. You have a signal handler that prints a log line.

Contract 2: process.exit on the first tick drops the in-flight request. The work never settles. The process is gone anyway.

function createNaiveExit() {
  const events = [];
  return {
    wrap: (work) => {
      events.push("accept");
      return Promise.resolve().then(work);
    },
    exitNow: () => {
      events.push("exit");
      return { ok: false, reason: "dropped" };
    },
    events: () => events.slice(),
  };
}

const naive = createNaiveExit();
naive.wrap(() => new Promise(() => {})); // still on the wire
assert.equal(naive.exitNow().reason, "dropped");

This is the rolling-deploy 502. The replica coming up is healthy. The replica going down reset a connection the load balancer already handed it.

Contract 3: a request that outlives the grace period is forced. inFlight stays 1. SIGKILL does not wait for your await.

clock.t = 0;
const late = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });
late.wrap(() => new Promise(() => {}));
late.begin();
clock.t = 30_000;
const forced = late.tickForce();
assert.equal(forced.reason, FORCED);
assert.equal(forced.inFlight, 1);

The spoken version: I would not pretend a 2-minute export fits in 30 seconds. Either I fail that request with 503 on SIGTERM and let the client retry another replica, or I raise terminationGracePeriodSeconds to a number I measured. I would not sit in close() and hope kubelet is patient.

Contract 4: preStop spends the same budget. At t=10_000 the force window has not opened. At t=29_999 it still has not. At t=30_000 an idle drain is allowed to finish. There is no bonus 30.

clock.t = 0;
const prestop = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });
prestop.begin();
clock.t = 10_000;
assert.equal(prestop.tickForce(), null);
clock.t = 29_999;
assert.equal(prestop.tickForce(), null);
clock.t = 30_000;
assert.equal(prestop.tickForce().reason, DRAINED);

The Kubernetes docs even give a 2-second one-off extension if preStop is still running when the grace period expires. That is kubelet covering the hook, not extra drain time for your HTTP server. If the hook sleeps 25 seconds, you have about 5 seconds of SIGTERM left. I have seen a preStop: sleep 20 copied from a nginx snippet into a Node service. Then people wonder why in-flight GraphQL requests reset during every rollout.

I ran those four with node sigterm-drain.mjs. All green.

What do you say out loud in the backend / SRE round?

Something like:

I treat SIGTERM as a drain, not an exit. First I stop being a Service endpoint: fail readiness, then server.close() so we do not accept new TCP. In-flight requests keep running. I wait on a counter, not on a sleep(30). If the counter hits zero I exit 0. If the grace period is about to expire I call closeAllConnections(), log how many were still open, and exit. preStop time is subtracted from the same 30 seconds, so I would not sleep in the hook. TERM has to reach PID 1. If the container PID 1 is a shell that does not forward signals, none of this runs and kubelet SIGKILLs a process that never knew it was dying.

The AceRound DevOps engineer interview guide puts rolling deploys and probe failures in the production-scenario bucket. aceround.app — AI interview assistant is useful when the next hour is talking through the 30-second window while someone interrupts you. It does not replace running the four contracts above.

A few follow-ups I would expect:

Follow-up	What I would not say
Can't we just raise the grace period to 300?	"Then we never have to drain." Long grace periods make rollouts slow. Measure p99 in-flight duration, set grace to that plus a buffer, still refuse new work immediately.
What about HTTP/2 or WebSockets?	`closeAllConnections()` does not destroy upgraded sockets. Those need their own shutdown. I would say so instead of waving `server.close()`.
Why fail readiness before SIGTERM?	Because EndpointSlice removal is not instantaneous. A `preStop` that only sleeps, with no readiness fail, still takes traffic for part of the window. Fail the probe first.
`process.on("SIGTERM", () => process.exit(0))`?	That uninstalls Node's default handler and then exits anyway. Same dropped request, extra confidence.

I would not ship this Map as the process manager. Production is http.Server plus a readiness flag plus a deadline timer. The pad exists so you can fail “new work after SIGTERM” in 20 seconds instead of drawing a rectangle labelled “graceful” on a whiteboard.

FAQ

Does server.close() wait for in-flight requests?

It stops new connections and, since Node 19, idle keep-alive. Active requests keep running until they end or you call closeAllConnections().

Is SIGTERM the same on Windows?

Node can listen for 'SIGTERM' on Windows. Kubernetes Linux nodes send TERM to PID 1. Do not demo this with Ctrl+C and assume it is the same path. Ctrl+C is SIGINT.

Why 30 seconds?

That is the Pod API default when terminationGracePeriodSeconds is nil. kubectl delete uses the same default. You can set it. You cannot ignore SIGKILL after it.

If my handler never calls process.exit, what happens?

Node no longer exits on SIGTERM once a listener exists. You sit in Terminating until kubelet SIGKILLs you at second 30. The log line that says “received SIGTERM” is not a shutdown.

Should the drain reject new HTTP with 503 or just close the listen socket?

Both. Close the listen socket so the kernel refuses new TCP. Return 503 for anything already accepted that you choose not to run. Clients retry the next replica.

If you already handle SIGTERM in production, does the handler wait for inFlight === 0, or does it process.exit on the first tick?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Grace period default of 30 seconds and TERM-then-KILL: Kubernetes Pod lifecycle and the Pod API. server.close / closeIdleConnections / closeAllConnections: Node.js HTTP docs, including the v19.0.0 idle-connection change. SIGTERM listener replacing the default exit: Node.js process signal events.

Fencing Tokens Stop the Write Your Redis Lease Already Released

Karuha — Tue, 01 Sep 2026 09:47:31 +0000

A Redis SET NX PX lock is a lease. It is not mutual exclusion. If the holder pauses longer than the TTL, a second client acquires the same key, writes, and the first client still writes when it wakes up. The fix is a fencing token: a number that only goes up, checked by storage, not by lease.isHeld().

Google autocomplete for fencing token currently suggests pattern, redis, lock, zookeeper, etcd, and redlock. redis distributed lock fills in with Java, Python, Go, C#, Spring Boot. People are searching the primitive by name. The interview is whether you know the lease is not the safety boundary.

What is the interviewer actually asking?

Most whiteboard answers stop at Redis:

SET lock:acct:1 <random> NX PX 30000

That is the pattern Redis itself documents on the SET command page: create the key only if it is missing, auto-release with an expiry, unlock with a Lua compare-and-delete so you do not DEL someone else's lease. Fine for efficiency. Martin Kleppmann's 2016 note on distributed locking splits the use cases in one paragraph. If two nodes do the same work and you pay AWS five extra cents, a best-effort lock is enough. If two nodes debit the same account, you need correctness. SET NX does not give you that.

The failure is not exotic. Kleppmann's diagram is the whole interview: client A gets token 33, pauses (GC, a page fault, a SIGSTOP, a delayed packet), the lease expires, client B gets token 34 and writes. A resumes and writes with 33. Storage that only checks "did you once hold a lock?" accepts both.

I ran that sequence in 70 lines of Node with an injected clock. No Redis process. The clock is the point.

Why doesn't checking the lease just before the write save you?

Because the pause can happen after the check. Kleppmann is blunt about this: you cannot insert if (!lock.expired) write() and call it fixed. GC can stop the thread between the last check and the write. A packet can sit in the network for a long time after you sent it. He cites a GitHub incident where packets were delayed about 90 seconds. Your isHeld() returned true. The write arrived after B already committed.

So the resource has to be the one that says no. The lock service only issues a strictly increasing token. Storage remembers the highest token it accepted and rejects anything that went backwards.

ZooKeeper people already have this: zxid or the znode version. etcd has revision. Redis SET NX returns OK or nil. It does not return a monotonic fence. That is Kleppmann's actual objection to Redlock as a correctness lock, not a dunk on Redis.

How small is the pad version?

Two objects. A lease map that mints a fence on every successful acquire. An account that optionally enforces token > lastFence on every debit. Clock and TTL are injected so the tests do not sleep.

const STALE = "stale_fence";
const HELD = "lock_held";

function createLeaseLock({ now, ttlMs = 30 } = {}) {
  const locks = new Map();
  let nextFence = 33; // Kleppmann's diagram

  function acquire(key, owner) {
    const current = locks.get(key);
    if (current && current.expiresAt > now()) {
      return { ok: false, error: HELD, holder: current.owner };
    }
    const fence = nextFence++;
    locks.set(key, { owner, fence, expiresAt: now() + ttlMs });
    return { ok: true, fence };
  }

  function isHeld(key, owner) {
    const current = locks.get(key);
    return Boolean(current && current.owner === owner && current.expiresAt > now());
  }

  return { acquire, isHeld };
}

function createAccount({ fence = true } = {}) {
  let balance = 100;
  let lastFence = 0;
  const writes = [];

  function debit(amount, token) {
    if (fence && !(token > lastFence)) {
      return { ok: false, error: STALE, lastFence, token };
    }
    if (fence) lastFence = token;
    balance -= amount;
    writes.push({ amount, token, balance });
    return { ok: true, balance };
  }

  return { debit, getBalance: () => balance, getLastFence: () => lastFence, writes };
}

The starting fence is 33 so the narration matches the blog post you should actually cite. Production would start at 1. I do not care.

Which six contracts do you have to show?

Contract 1: while the lease is live, B cannot acquire. This is the NX part. If you cannot show this, you do not have a lock at all.

const clock = { t: 0 };
const lock = createLeaseLock({ now: () => clock.t, ttlMs: 30 });
const a = lock.acquire("acct:1", "A");
const b = lock.acquire("acct:1", "B");
assert.equal(a.ok, true);
assert.equal(a.fence, 33);
assert.equal(b.ok, false);

Contract 2: TTL is a liveness feature. After 31ms, A is not the holder. B acquires. The new fence is 34, strictly greater.

clock.t = 31;
const b2 = lock.acquire("acct:1", "B");
assert.equal(lock.isHeld("acct:1", "A"), false);
assert.equal(b2.fence, 34);

Redis documents this as a liveness property: even if the client crashes, the key expires. That is the part people remember. The next contract is the part they skip.

Contract 3: turn fencing off. Same pause. B debits 10 with token 34. A wakes up and debits 10 with token 33. Both succeed. Balance is 80. Last write is token 33. You just lost B's update, or you double-charged the account, depending how you read the ledger.

const unfenced = createAccount({ fence: false });
unfenced.debit(10, 34);
assert.equal(unfenced.debit(10, 33).ok, true);
assert.equal(unfenced.getBalance(), 80);

That is the broken writeData in Kleppmann's post, executable.

Contract 4: same sequence, fencing on. B's debit is accepted. A's debit returns stale_fence. Balance stays 90. lastFence is 34.

const fenced = createAccount({ fence: true });
const lock2 = createLeaseLock({ now: () => clock.t, ttlMs: 30 });
clock.t = 0;
const aLease = lock2.acquire("acct:1", "A");
clock.t = 31;
const bLease = lock2.acquire("acct:1", "B");
assert.equal(fenced.debit(10, bLease.fence).ok, true);
assert.equal(fenced.debit(10, aLease.fence).error, STALE);
assert.equal(fenced.getBalance(), 90);

Contract 5: equal token is stale. > not >=. A retry of the same successful write should be idempotent at the business layer (same debit id), not by sending the same fence again as a second debit.

assert.equal(fenced.debit(5, 40).ok, true);
assert.equal(fenced.debit(5, 40).error, STALE);

Contract 6: the TOCTOU the interviewer will poke. A checks isHeld at t=0. Clock jumps to 31. B acquires and writes. A then writes with the old fence. Fencing still rejects it. The check was theater.

assert.equal(lock.isHeld("acct:1", "A"), true);
clock.t = 31;
// B writes, A writes. Only B's token survives.

I ran those six with node fencing-token.mjs. All green.

What do you say out loud in the system-design round?

Something like:

I would ask whether the lock is for efficiency or correctness. For a cache fill, SET NX PX on one Redis is enough and I would say so. For an account debit I would not trust the lease. The lock service returns a monotonically increasing fencing token. Every write to the resource carries that token. The resource rejects anything less than or equal to the highest token it has already accepted. The check lives in the UPDATE ... WHERE last_fence < $token (or the equivalent compare-and-set). A client-side if (lease.isValid()) is not the check.

If they say "we use Redlock," I would not pick a fight with Redis's page. I would say: Redlock still does not hand me a fence. Without a fence, a paused holder can still write after a new holder has written. For correctness I want ZooKeeper/etcd (zxid / revision) or a database unique constraint plus a generation column. Redis is fine as an efficiency lock.

The backend round that asks "how do you lock this?" is the same round as outbox, idempotency keys, and the 3 AM CPU spike. The AceRound backend-developer interview guide puts those in the production-scenario bucket. aceround.app — AI interview assistant is useful when the next hour is talking through the pause while someone interrupts you. It does not replace running the six contracts above.

A few follow-ups I would expect:

Follow-up	What I would not say
Can't we just heartbeat and extend the TTL?	"Then the pause cannot happen." Heartbeats help a healthy holder. They do not fence a write that is already in flight after the lease died.
Redis `GET` the lock just before `SET` the account?	That is two round trips and still a race. The account write has to be conditional on the fence in one atomic step.
UUID as the token?	UUIDs do not order. Storage cannot tell 33 from 34. Monotonic is the whole trick.
What about Redlock's five nodes?	Majority voting is about the lock service surviving a Redis crash. It still does not produce a fence. Kleppmann's critique starts there.

I would not ship this Map. Production needs the fence on the resource that can actually lose money, persisted, compared atomically. The pad exists so you can fail the stale debit in 20 seconds instead of drawing a mutex on a whiteboard.

FAQ

Is a fencing token the same as an idempotency key?

No. An idempotency key says "this client intent runs once." A fencing token says "this generation of the lock is allowed to write, older generations are not." You usually want both. The debit should have an idempotency key so B's retry does not debit twice, and a fence so A's delayed packet cannot debit after B.

Does every lock need this?

No. Kleppmann's efficiency case is real. Singleflight for a cache stampede, a rate-limit counter, a "don't send the same email twice if we can help it" lock: lose one and you are annoyed. Do not pay ZooKeeper for that.

Why start the demo at 33?

So the story matches the diagram in the 2016 post. Interviewers who have read it will nod. If they have not, 1 and 2 work the same.

Can the storage service skip the check if the client promises it still holds the lock?

That is the broken code sample. The client is the one that paused. Storage is the only place the side effect becomes true.

If you already use Redis locks in production, does the resource you protect compare a fence, or does it trust SET NX?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Lease vs mutex, token 33 vs 34, and the "check before write" hole: Kleppmann, 8 Feb 2016. SET key value NX EX|PX: Redis SET. Redlock's safety/liveness list: Distributed locks with Redis.

Why JWT Refresh Token Rotation Fails Without a Token Family

Karuha — Mon, 31 Aug 2026 14:22:12 +0000

JWT refresh token rotation is not "issue a new token and delete the old one." RFC 9700 says you keep the relationship. If a spent token shows up again, you revoke the whole family. I ran that contract in 80 lines of Node. Rotation without reuse detection still hands the session to whoever got there second.

Google autocomplete for jwt refresh token rotation currently suggests meaning, header, Stripe, example, generator, and pattern. People are searching the mechanism by name, not "auth in general."

What do interviewers actually want when they say "rotate the refresh token"?

A common whiteboard answer is: access token lives 15 minutes, refresh token lives 30 days, each refresh mints a new access token. That is a session, not rotation.

RFC 9700 section 4.14 is the current OAuth 2.0 security BCP (January 2025). For public clients it requires one of two things: sender-constrained refresh tokens (DPoP / mTLS), or rotation. Rotation is defined as:

issue a new refresh token on every access-token refresh
invalidate the previous one
retain the relationship
if a later request presents the invalidated token, revoke the active one

The last two bullets are the interview. Delete-on-use with no memory of the parent grant is just a shorter-lived secret. The attacker who wins the race keeps working. The legitimate client gets invalid_grant and you never find out why.

Auth0's public docs call the retained relationship a token family and the alarm "automatic reuse detection." Their example is the one I use in loops: legitimate client holds RT1, it leaks, legitimate client exchanges RT1 for RT2, attacker replays RT1, the family including RT2 dies, everyone re-authenticates. The log event they name is ferrt.

I am not reimplementing Auth0. I wanted a store I can run in the pad with node:assert/strict and then narrate.

Why does deleting the old token fail the theft case?

Three records. That is the whole model.

{
  token,       // opaque string the client holds
  familyId,    // the grant / lineage
  generation,  // 0, 1, 2...
  spentAt,     // null while this row is current
  replacement, // the token issued when this row was spent
}

Spent is not deleted. If you Map.delete(rt1) after minting RT2, a replay of RT1 looks identical to a typo: invalid_grant. You cannot tell theft from a stale client. You also cannot revoke RT2, because you no longer know they are siblings.

The store below is dependency-free. Clock and leeway are injected so the tests do not sleep.

import { randomBytes } from "node:crypto";

const REUSE = "refresh_token_reused";
const UNKNOWN = "invalid_grant";
const FAMILY_REVOKED = "family_revoked";

function createStore({ now = () => Date.now(), leewayMs = 2000 } = {}) {
  const byToken = new Map();
  const families = new Map();

  function mint(familyId, generation) {
    const token = randomBytes(16).toString("hex");
    const record = { token, familyId, generation, spentAt: null, replacement: null };
    byToken.set(token, record);
    const family = families.get(familyId);
    family.current = token;
    family.lineage.push(token);
    return record;
  }

  function issue(userId) {
    const familyId = randomBytes(8).toString("hex");
    families.set(familyId, { userId, current: null, lineage: [], revoked: false });
    return mint(familyId, 0);
  }

  function rotate(presented) {
    const record = byToken.get(presented);
    if (!record) return { ok: false, error: UNKNOWN };

    const family = families.get(record.familyId);
    if (family.revoked) return { ok: false, error: FAMILY_REVOKED };

    if (record.token === family.current) {
      record.spentAt = now();
      const next = mint(record.familyId, record.generation + 1);
      record.replacement = next.token;
      return { ok: true, token: next.token, generation: next.generation };
    }

    const isImmediatePrevious =
      record.replacement != null && record.replacement === family.current;
    if (isImmediatePrevious && now() - record.spentAt <= leewayMs) {
      const current = byToken.get(family.current);
      return { ok: true, token: current.token, generation: current.generation, retry: true };
    }

    family.revoked = true;
    family.current = null;
    return { ok: false, error: REUSE };
  }

  return { issue, rotate };
}

Which five contracts do you have to show?

Contract 1: happy path. RT1 in, RT2 out, different string, generation 1.

const store = createStore();
const rt1 = store.issue("u1");
const r2 = store.rotate(rt1.token);
assert.equal(r2.ok, true);
assert.equal(r2.generation, 1);
assert.notEqual(r2.token, rt1.token);

Contract 2: rotate twice, then replay RT1. RT1 is no longer the immediate previous, so this is reuse, not a retry. The family dies. RT3, which the legitimate client is holding, must also fail.

const r3 = store.rotate(r2.token);
assert.equal(store.rotate(rt1.token).error, REUSE);
assert.equal(store.rotate(r3.token).error, FAMILY_REVOKED);

That is the RFC 9700 sentence in executable form: the server "cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token."

Contract 3: flaky network. Auth0's dashboard calls this the rotation overlap period, in seconds. A mobile client sends RT1, loses the response, retries RT1 500ms later. If you treat that as theft, you lock out real users. The demo uses 2000ms so the test can move a fake clock.

const clock = { t: 0 };
const retryStore = createStore({ now: () => clock.t, leewayMs: 2000 });
const a1 = retryStore.issue("u2");
const a2 = retryStore.rotate(a1.token);
clock.t = 500;
const retry = retryStore.rotate(a1.token);
assert.equal(retry.retry, true);
assert.equal(retry.token, a2.token); // same RT2, not a new generation

Contract 4: same retry after the window. 2501ms later, RT1 is theft. Family gone.

clock.t = 2501;
assert.equal(retryStore.rotate(a1.token).error, REUSE);

Auth0's support note on leeway is stricter than "any spent token may retry." Only the previous generation is inside the window. The generation before that still kills the family, even if the clock says you are inside N seconds. Contract 2 already covers that: RT1 after RT1→RT2→RT3 is older than previous.

Contract 5: attacker spends RT1 first. Advance the clock past leeway, then the legitimate client presents RT1. Same alarm. The attacker's RT2 dies too. I ran this with an injected clock at t=0 then t=2501. If you skip the clock and default Date.now(), the second call lands inside 2 seconds and looks like a retry. That is a real production footgun, not a test smell.

Unknown tokens stay invalid_grant. Do not revoke some other user's family because of a random string.

I ran those eight assertions (happy path, double-rotate replay, post-revoke current, retry inside window, retry after window, attacker-first plus family kill, unknown token) with node rt-rotation.mjs. All green.

What do you say out loud in the 45-minute backend round?

Something like:

I would keep refresh tokens one-time. I would not delete the spent row. Replay of a spent token is reuse detection: revoke the family, force a new grant. Retry of the immediate previous token inside a short overlap is a lost response, not theft. RFC 9700 also allows DPoP instead of rotation. I picked rotation because the pad is an in-memory map. Production still needs idle expiry.

That speech is the score. The map is evidence.

A few follow-ups I would expect, and the short answers:

Follow-up	What I would not say
Why not put the family id inside a signed JWT refresh token?	"Because JWTs cannot be revoked." They can, you still need a denylist or a family row. Encoding the grant id in the token is an RFC 9700 implementation note, not a substitute for the store.
How long is access token vs refresh token?	Numbers without rotation are trivia. 5–60 minutes for access is common. Refresh idle expiry is the SHOULD in 4.14.2. Pick a number and say it is policy, not physics.
SPA / localStorage?	Auth0's rotation doc exists partly because ITP broke silent iframe cookie refresh. Rotation is the remediation they document. I still would not keep a refresh token in `localStorage` if I have an HttpOnly cookie option.
Stripe Idempotency-Key vs this?	Different object. Idempotency keys dedupe a POST. Token families detect two holders of one secret. I already shipped a Node idempotency guard in July; this is the sibling question.

The backend interview that asks "JWT vs session cookies, OAuth flows, idempotency keys" is the same round. The AceRound backend-developer interview guide lists those as the REST/architecture bucket, sitting next to the 3 AM CPU production scenario. Rotation is one concrete artifact from that bucket. aceround.app — AI interview assistant is useful when the next hour is verbal walkthrough under interruption. It does not replace running the five contracts above.

What this is not

It is not "never use JWT." Access tokens can stay JWT. The refresh token in this pad version is an opaque random 16 bytes on purpose. Mixing "stateless JWT" with "I need to revoke a family" is how people invent a denylist and then claim they are stateless.

It is not a license to skip sender-constrained tokens. RFC 9700 lists rotation or DPoP/mTLS for public clients. If the interviewer is on a native app with a secure enclave, DPoP is the stronger answer and you should say so.

I would not ship this Map. Production needs a row per token, a unique constraint on the current token, and the rotate-and-revoke in one transaction. The pad version exists so you can fail the replay case in 30 seconds.

FAQ

Is reuse detection the same as token rotation?

No. Rotation makes the secret one-time. Reuse detection is the alarm when a one-time secret is presented twice. Skip the alarm and the attacker who exchanged first keeps a valid RT2.

Why kill RT2, which the legitimate user is holding?

Because the server cannot tell who is the thief. RFC 9700 is explicit: stop the attack at the cost of a fresh grant. The legitimate user signs in again. The attacker does not keep a quiet session.

How long should the overlap window be?

Auth0 configures it in seconds. Too long and you widen the replay margin. Too short and a lost mobile response locks the user out. I would start at a few seconds, log ferrt-style events, and tune from false-positive rate, not from a blog number.

Do confidential server clients still need this?

RFC 6749 already binds refresh tokens to the client that received them. 9700 still recommends rotation as an extra measure. For public clients (SPA, native) it is a MUST: rotation or sender-constrained.

If you already rotate refresh tokens in production, does a replay of generation N-2 revoke the family, or does it just return invalid_grant?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Rotation + reuse detection: Auth0 docs. Public-client MUST: RFC 9700 §4.14.2. Overlap / previous-generation only: Auth0 support on leeway.

Google's AI-Assisted Coding Interview: Catch the Cached 503 the Model Will Ship

Karuha — Sun, 30 Aug 2026 13:17:50 +0000

Google's 2026 AI-assisted coding interview does not grade a green test run. The new code-comprehension round scores whether you reject a patch that compiles. I planted a sticky 503 in a promise cache. The model's first fix still shipped the outage.

I have not sat the Google pilot. I'm going off Business Insider's May 7 reporting and Google's own April 22 Cloud Next note. The drill below is what I would run the night before a sanctioned AI-assisted loop, not a stealth overlay for a round that still bans tools.

What does Google's AI-assisted coding interview actually score?

Business Insider reviewed an internal document and got a Google spokesperson on the record. Starting in the second half of 2026, junior and mid-level software roles on selected US teams (Cloud, plus platforms and devices) get an approved assistant during a code comprehension round. The assistant in the pilot is Gemini. Candidates are expected to read, debug, and optimize an existing codebase. Interviewers score "AI fluency": prompt engineering, output validation, and debugging.

Brian Ong, Google's VP of recruiting, told BI the pilot exists "to be more reflective of how our teams are operating in the AI era."

That maps to a number Google already published. On April 22, 2026, Sundar Pichai wrote that 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall. If three quarters of the diff is model-authored, the interview that still asks you to invert a binary tree from a blank buffer is testing a job that is shrinking.

The document's phrase is "human-led, AI-assisted." You own the hypothesis. Gemini types. You decide whether the types were allowed to land.

This is not unique to Google. CoderPad's October 30, 2025 writeup of Meta's pilot quotes Meta recruiting saying it is not cheating, it is how the job is evolving. BI also names Canva and Cognition as companies that already let candidates use AI in technical interviews. Google search autocomplete for ai assisted coding interview currently suggests Meta, Microsoft, Canva, prep, mock, and reddit as follow-on queries. People are searching the format by name.

If your loop does not say AI is allowed, none of this is permission to sneak a second window onto a shared screen. The sanctioned round and the stealth overlay are opposite products. Mixing them up is how people get offers pulled.

Why does caching the in-flight promise look correct?

Here is the kind of 40-line module I would expect in a code-comprehension pad. It looks like a reasonable answer to "don't stampede the origin."

const cache = new Map();

async function fetchJsonCached(url, fetcher) {
  if (cache.has(url)) return cache.get(url);

  const pending = fetcher(url).then(async (res) => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  });

  cache.set(url, pending);
  return pending;
}

Two parallel /user reads hit fetcher once. That part is right. The bug is the rejected promise staying in the Map. A single 503 becomes the answer forever.

I asked a model to "fix the cache so a 503 does not break later requests." The first patch looked like this:

async function fetchJsonCached(url, fetcher) {
  try {
    if (cache.has(url)) return cache.get(url);
    const pending = fetcher(url).then((res) => res.json());
    cache.set(url, pending);
    return pending;
  } catch {
    return { error: true };
  }
}

Three mistakes, all the kind that still compile:

The try/catch does not wrap the awaited promise, so it never sees the 503.
res.ok is gone, so a 503 body gets parsed as success JSON.
The 503 payload is still sticky in the Map. The next call never reaches the network.

That is the failure mode the round is built to catch. The model optimized for "don't throw." The interviewer is scoring "don't poison the cache."

How do you prove the 503 is still sticky?

Do not argue with the model. Replay the outage.

function sequenceFetcher(responses) {
  let i = 0;
  let calls = 0;
  const fetcher = async () => {
    calls += 1;
    const next = responses[Math.min(i, responses.length - 1)];
    i += 1;
    return next;
  };
  return { fetcher, getCalls: () => calls };
}

function jsonRes(status, body) {
  return {
    ok: status >= 200 && status < 300,
    status,
    json: async () => body,
  };
}

Contract 1, buggy module: first call 503, second call should have been 200.

const seq = sequenceFetcher([
  jsonRes(503, { error: "upstream" }),
  jsonRes(200, { id: 7 }),
]);

await fetchJsonCached("/user", seq.fetcher); // throws HTTP 503
await fetchJsonCached("/user", seq.fetcher); // throws HTTP 503 again
seq.getCalls(); // 1. The origin never got a second chance.

Contract 2, the model's patch: even worse, because it returns { error: "upstream" } as if it were a user record. getCalls() is still 1.

The actual one-line repair is not a retry library. Delete the entry when the promise rejects, then let the next caller start a new in-flight promise.

const pending = fetcher(url)
  .then(async (res) => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  })
  .catch((err) => {
    cache.delete(url);
    throw err;
  });

cache.set(url, pending);
return pending;

Contract 3, after the delete: first call still throws 503. Second call returns { id: 7 }. getCalls() is 2.

Contract 4, still required: two parallel first calls coalesce. getCalls() stays 1 on a 200. You are not allowed to "fix" the 503 by removing in-flight dedupe. Interviewers notice when you swing from one bug to the stampede.

I ran those four plus the model's sticky-body case as a local Node script, no dependencies, node:assert/strict. Five contracts, all green on the delete-on-reject version.

What should you say out loud while Gemini is typing?

The round is 60 minutes of shared editing. Silence while you wait on a stream is the other way to fail. Narrate the contract before you accept the diff.

I would say, roughly:

I would cache the in-flight promise so two mounts don't double-fetch. I would not cache a rejection. If Gemini's patch drops res.ok or wraps this in an empty catch, I want a replay: 503 then 200. If the second call never hits the fetcher, we reject the diff.

That speech is the score. The code is evidence.

A few other tells I would look for in whatever module they hand you, same 10-minute budget:

Smell in the model's patch	What you replay
Empty `catch` / `return null`	The error path now looks like success
Cache written before `res.ok`	4xx/5xx bodies become canonical JSON
TTL added, rejection kept	You paid for expiry and still serve the 503 for the whole window
Lock around the wrong key	Concurrent URLs share one poisoned slot
Tests only cover the 200	Add the 503-then-200 case yourself

None of those need a framework. They need you to keep a failing fixture in the pad and refuse to delete it.

What this format is not

It is not "the interviewer wants to watch you prompt." Prompt quality is one of three bullets in Google's fluency rubric, sitting next to output validation and debugging. A candidate who pastes the whole file into Gemini and then reads the answer aloud is doing the opposite of "human-led."

It is also not a license for every company. Meta's CoderPad pilot is opt-in and still rolling. Google's is a 2026 pilot on selected US teams. If the scheduler, the recruiter, or the pad header does not say an assistant is in the environment, assume it is not.

The prep that transfers across both the Google comprehension round and Meta's AI-enabled pad is the same muscle: take an unfamiliar repo, keep a failing fixture, and treat the model as a junior who ships the first compile.

I use aceround.app — AI interview assistant when the next round is verbal (system design, "walk me through this diff") and I need to rehearse the explanation under interruption. It does not replace the Node replay above. If you cannot show the 503-then-200 contract in the pad, the spoken version will not save you.

FAQ

Does Google let every candidate use Gemini in the coding round?

No. BI describes a second-half 2026 pilot for junior and mid-level roles on selected US teams, with Gemini as the approved assistant. Do not assume your loop is in that cohort until someone says so.

If the tests pass after I accept Gemini's patch, am I done?

Not if the tests never sent a 503. Add that case. A green suite that only covers 200 is how the sticky cache ships.

Is this the same skill as "turn the model's answer into unit tests"?

Related, different fixture. That version starts from a blank solution. This version starts from a repo that already almost works. Google's comprehension round is the second one.

Should I still practice LeetCode?

Yes, for loops that still ban AI. For loops that allow it, spend equal time reading someone else's 200-line module and listing the contracts you would refuse to drop.

What 503-then-200 fixture would you add to the last model patch you accepted at work?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Google pilot details: Business Insider, May 7, 2026. 75% figure: Pichai, April 22, 2026. Meta pilot: CoderPad, October 30, 2025.

DEV Community: Karuha

Instagram lets you add 5 bio links now. TikTok still hides the field until 1,000 followers

What that actually changes

How to audit your own setup

Late Events Do Not Error, They Vanish: Build a Watermark Drill in Node.js

Why "late" has no error path

Two knobs everyone conflates

Build the aggregator

Five contracts to prove

The naive fix, measured

What the interviewer asks next

The global watermark is a minimum, not a maximum

How to pick the two numbers

The sink has to upsert

Replay determinism

FAQ

Where to rehearse the follow-ups

Before your next data interview

Outlook's Business Card button is not a signature link

Two different objects

What a hosted /v/ link actually sends

Where each one actually shows up

Setup, without fighting the wrong dialog

This does not make anyone save the contact

CodeSignal GCA Banks Your Highest Submit, Even After a Syntax Error

What is the live GCA, not the 2022 one?

Does the editor autosave when you jump to Q4?

Which submit actually gets scored?

Is Cosmo or ChatGPT allowed on a certified GCA?

What fails hidden tests after the samples pass?

FAQ

What to do in the 24 hours before the invite expires

NFC vs QR: which business card actually gets scanned

What's actually being transmitted

Where NFC actually breaks

Where QR actually breaks

Cost, and who controls the card afterward

A two-minute test if you already have both

What neither format fixes

HackerRank AI-Assisted Interview: If the Assistant Won't Write Code, Check the Question Type

What actually gets turned on?

Why does Guarded mode look broken?

What does the interviewer actually see?

What does a strong Code Repo session look like?

How is this different from a HackerRank OA?

A 20-minute practice you can run tonight

The Second Worker Never Saw Job 2

What does FOR UPDATE LIMIT 1 actually wait on?

Why is job 2 still queued while worker 2 is idle?

Can you prove the wait without standing up Postgres?

Why does OFFSET lock rows you never returned?

How do you say this in the interview?

Forgot client.release()? Postgres Never Sees Request 11

What does the interviewer actually mean by "the pool is exhausted"?

Why does pool.connect() hang instead of throwing?

How do you prove the checkout contract without standing up Postgres?

What do you say when they ask how big max should be?

How do you narrate this in a backend / SRE interview?

What I would not say

Drain In-Flight HTTP Before Kubernetes Sends SIGKILL

What is the interviewer actually asking?

Why doesn't server.close() by itself finish the job?

How small is the pad version?

Which four contracts do you have to show?

What do you say out loud in the backend / SRE round?

FAQ

Fencing Tokens Stop the Write Your Redis Lease Already Released

What is the interviewer actually asking?

Why doesn't checking the lease just before the write save you?

How small is the pad version?

Which six contracts do you have to show?

What do you say out loud in the system-design round?

FAQ

Why JWT Refresh Token Rotation Fails Without a Token Family

What do interviewers actually want when they say "rotate the refresh token"?

Why does deleting the old token fail the theft case?

Which five contracts do you have to show?

What do you say out loud in the 45-minute backend round?

What this is not

FAQ

What a hosted `/v/` link actually sends

What does `FOR UPDATE LIMIT 1` actually wait on?

Why does `OFFSET` lock rows you never returned?

Why does `pool.connect()` hang instead of throwing?

What do you say when they ask how big `max` should be?

Why doesn't `server.close()` by itself finish the job?