JavaScript Polyfills & Language Internals: The Interview Guide

Short answer: Polyfill questions aren't about the code — they test whether you understand the spec behavior you're recreating. The winning approach is always the same: state the behavior precisely (including edge cases), derive the implementation from it, then name the modern built-in you'd actually use. A handful of techniques recur across every one of them.

This is the pillar for the "rebuild the standard library" cluster. Each family links to a focused, worked deep-dive.

Why interviewers ask polyfills

Recreating a built-in forces you to demonstrate mechanics you otherwise take for granted: how this is bound at the call site, how the prototype chain resolves, what the accumulator contract of reduce really is, how a serializer handles cycles. The interviewer isn't buying the code — they're buying the explanation around it. So the strongest candidates narrate the spec as they type.

The techniques that recur

These show up again and again — recognize them and most polyfills become variations on a theme:

• The Symbol temp-key trick. To set this without call/apply, you make the function a property of the target and invoke it as a method (obj.fn() binds this to obj). Use a unique Symbol key with enumerable: false so it never collides with or leaks onto the caller's object.
• try/finally cleanup. Anything that mutates a caller-owned object (the temp-key trick) must undo it in a finally, so a throwing callee doesn't leave a stray property behind.
• == null, not falsy. thisArg == null catches only null/undefined; thisArg || globalThis wrongly rebinds 0, '', false, and NaN. This is the single most-planted bug in the family.
• Primitive boxing. Sloppy-mode call(42) sees this as a Number object — Object(thisArg). Naming where the polyfill can't match native behavior (frozen objects, strict-mode unboxed this) is a senior signal.
• Spec-accurate edge cases. Empty inputs, array-likes vs iterables, NaN/-0, cyclic references, undefined values — the built-in has a defined answer for each, and reproducing it is the whole point.
• The index cursor / two-pointer scan. String and parser polyfills walk input with an advancing cursor rather than allocating intermediates.

The families

Function internals: this-binding

The this-binding trio is the most-asked family, and it escalates cleanly:

• Function.prototype.call & apply — the Symbol temp-key trick, == null, boxing, and apply's array-like argument handling.
• Function.prototype.bind — closures over the bound args plus the new-operator edge case (a bound function used as a constructor ignores the bound this).
• The new operator — create an object whose prototype is fn.prototype, run the constructor, and honor an explicit object return.
• instanceof — walk the prototype chain against Constructor.prototype.

All four lean on how this is bound and the prototype chain.

Object & type utilities

• Object.assign — own enumerable copy, getters, and the Symbol key detail.
• Object.is — SameValue equality: the two cases === gets wrong, NaN (equal to itself) and +0 vs -0 (not equal).
• Custom typeof — the historical typeof null === "object" bug and reliable type tagging via Object.prototype.toString.

Array & iteration

• Array.prototype.reduce — the universal fold, and the no-initial-value case (first element seeds the accumulator; empty array with no seed throws).

JSON serialization

• JSON.stringify — type dispatch, undefined/function omission, toJSON, and the TypeError on cycles.
• JSON.parse — a recursive-descent parser with a cursor; the smallest real parser you'll write in an interview.

String & scanning

• String tokenizer — the index-cursor scan that also underlies JSON.parse and lexers.

Trimming whitespace is the smallest member of this family, and it hides two teeth. First, "whitespace" is bigger than ' \t\n\r' — the spec set includes \v, \f, the no-break space   (the   from scraped HTML that four-character implementations fail on), the BOM , and every Unicode Space_Separator. The clean answer is a two-pointer scan that advances over a whitespace Set:

function trim(str) {
  let start = 0;
  let end = str.length - 1;
  while (start <= end && WHITESPACE.has(str[start])) start++;
  while (end >= start && WHITESPACE.has(str[end])) end--;
  return str.slice(start, end + 1); // note: end + 1 — the classic off-by-one
}

Second, the obvious regex str.replace(/^\s+|\s+$/g, "") is a ReDoS-shaped pattern: on "a" + " ".repeat(50000) + "b", the \s+$ alternative retries at every interior whitespace position and degrades to O(n²) — the shape behind Cloudflare's 2019 outage. Knowing that anchored \s+$ on untrusted input is a DoS risk — and offering the linear scan instead — is worth more than the implementation. (​ zero-width space is not whitespace and native trim leaves it; over-trimming it is a common mistake.)

How to approach a polyfill in the interview

1. State the behavior first, edge cases included — that framing structures the whole answer.
2. Derive, don't recite. The code should fall out of the behavior you just described.
3. Name the modern built-in / trick-free alternative — Reflect.apply over the Symbol trick, spread over apply, structuredClone over hand-rolled deep clone (with its limits).
4. Name what your polyfill can't do — frozen objects, strict-mode this, structuredClone's inability to clone functions. Honesty about limits reads as seniority.

Common traps across the family

• context || globalThis instead of context == null.
• String temp-keys (collision) or enumerable Symbol keys (observable) instead of a non-enumerable Symbol.
• delete outside finally — leaks on throw.
• Forgetting the return value under pressure.
• Hardcoding the whitespace/edge-case set and missing the Unicode or empty-input cases.

Where to go next

Start with the this-binding family, then the parsers:

1. call & apply → bind → new → instanceof.
2. reduce · Object.assign · Object.is · typeof.
3. JSON.stringify → JSON.parse → string tokenizer.

Foundations: the this keyword and prototypal inheritance.