Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow JavaScript mastery study plan Practice more JavaScript interview questions

Truthy/falsy, pass-by-value vs reference, and strict equality: practical use caseFrontend interview answer

HighIntermediateJavascript

By FrontendAtlas Team · Updated Apr 10, 2026

Interview focus

This JavaScript interview question tests whether you can explain JavaScript bug combo: falsy defaults, == coercion, and shared mutation, connect it to production trade-offs, and handle common follow-up questions.

JavaScript bug combo: falsy defaults, == coercion, and shared mutation explanation without falling back to memorized docs wording
Truthy Falsy and Strict Equality reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview quick answer

This page is about a common production bug combo: falsy defaults overwrite valid values, loose equality coerces unexpectedly, and shared mutation leaks state back to the caller. Strong answers separate those failures while showing one integrated helper bug.

Full interview answer

Why interviewers combine these topics

Because real frontend bugs usually combine them: a fallback breaks 0/false, a loose comparison silently passes, and a helper mutates shared state behind the caller's back. The debugging skill is separating those three failures without pretending they are the same bug.

Topic	Bad habit	Safer habit
Truthy/falsy defaults	`value \|\| fallback`	`value ?? fallback`
Equality checks	`==` on unknown input	Parse first, compare with `===`
Object handling	Mutate input object	Clone/return new object unless mutation is intentional

Three rails that prevent many production bugs.

JAVASCRIPT

const retries = 0;
const enabled = false;

console.log(retries || 3);   // 3   ❌ loses valid 0
console.log(enabled || true); // true ❌ loses valid false

console.log(retries ?? 3);    // 0   ✅
console.log(enabled ?? true); // false ✅

JAVASCRIPT

console.log('0' == 0);  // true  (coercion)
console.log('0' === 0); // false

const qty = Number('0');
console.log(qty === 0);  // true ✅ explicit conversion first

JAVASCRIPT

function normalize(input) {
  const cfg = { ...input }; // avoid mutating caller
  cfg.retry = cfg.retry ?? 3;
  if (cfg.total === 0) cfg.status = 'empty';
  return cfg;
}

const original = { retry: 0, total: 0 };
const out = normalize(original);

console.log(original); // unchanged
console.log(out);      // normalized safely

Integrated real-world bug (before/after)

One helper can fail in three different ways at once: it overwrites a valid falsy value, it relies on coercion, and it mutates caller-owned state.

JAVASCRIPT

// ❌ buggy
function prepare(cart) {
  cart.retry = cart.retry || 3;            // loses valid 0
  cart.sendReceipt = cart.sendReceipt || true; // loses valid false
  if (cart.total == 0) cart.status = 'empty';  // coercion surprise
  return cart;                             // mutates caller object
}

const source = { retry: 0, sendReceipt: false, total: '0' };
const broken = prepare(source);
console.log(source.retry);        // 3 ❌ caller object changed
console.log(broken.sendReceipt);  // true ❌ valid false lost

// ✅ safer
function prepareSafe(input) {
  const cart = { ...input };
  cart.retry = cart.retry ?? 3;
  cart.sendReceipt = cart.sendReceipt ?? true;
  const total = Number(cart.total);
  if (Number.isNaN(total)) throw new Error('Invalid total');
  if (total === 0) cart.status = 'empty';
  return cart;
}

Separate the failures when debugging

The falsy-default bug asks: why was 0, false, or '' overwritten?
The coercion bug asks: why did the condition pass with the wrong type?
The shared-reference bug asks: why did caller-owned state change after the helper returned?

Production review habit

When you review a helper that handles user input or config defaults, ask three questions in order:

Can 0, false, or an empty string be valid here?
Am I comparing parsed values of the same type, or relying on coercion?
Will this function mutate caller-owned objects and create hidden shared-state bugs?

This one checklist catches a surprising number of frontend incidents.

Test checklist
Always include cases for 0, false, empty string, string-number input, and "original object unchanged" assertions.

Still so complicated?

Think of this as three guardrails: default correctly, compare strictly, and protect shared state.

Summary

Use ?? when 0/false/'' are valid.
Use === after explicit parsing.
Avoid mutating caller-owned objects by default.