JavaScript for coding interviews

When JavaScript is the right pick

If most of your recent experience is frontend or full-stack JavaScript/TypeScript, interviewing in the language you actually think in usually beats switching to Python for the interview alone — the cost of translating your mental model into an unfamiliar language's idioms under time pressure typically outweighs whatever syntactic convenience the other language offers. The reverse is also true: pick whichever language you write fluently day to day, not whichever one a blog post says interviewers prefer (in practice, neither is preferred — see Python for coding interviews for the mirror-image version of this page).

Idioms interviewers expect

# The direct analogues, for comparison — see /interview-prep/python
from collections import Counter
counts = Counter(nums)

groups = defaultdict(list)
for word in words:
    groups[key(word)].append(word)

// Counting occurrences — Map, not a plain object, avoids prototype-chain gotchas
const counts = new Map();
for (const n of nums) {
  counts.set(n, (counts.get(n) ?? 0) + 1);
}

// Grouping — a Map of arrays, built with the same "check then push" idiom
const groups = new Map();
for (const word of words) {
  const k = key(word);
  if (!groups.has(k)) groups.set(k, []);
  groups.get(k).push(word);
}

// Destructuring instead of manual indexing
const [first, ...rest] = nums;
const { length } = nums;

Using Map/Set instead of plain objects for general-purpose lookups, and destructuring instead of manual indexing where it reads more clearly, are both small, idiomatic choices that add up across an interview the same way they do in Python.

Array-method complexity gotchas

• array.includes(x) and array.indexOf(x) are O(n) — the same trap as Python's x in list. Use a Set for O(1) average-case membership testing.
• array.shift() and array.unshift() are O(n) — they reindex every remaining element. For queue-like behavior in a tight loop, this can silently turn an intended O(n) solution into O(n²); consider using two pointers into a fixed array or a proper deque structure instead.
• Chaining .map().filter().reduce() is idiomatic and fine for readability, but each call is a separate O(n) pass — three chained calls is 3n operations, still O(n) overall but worth being able to state precisely if asked, rather than waving at "it's fast."
• array.sort() defaults to converting elements to strings and sorting lexicographically — sorting numbers without an explicit comparator ((a, b) => a - b) is a well-known, easy-to-make bug that silently produces the wrong order for anything beyond single digits.

Common pitfalls

• Loose equality (==). Prefer === everywhere in interview code; =='s type-coercion rules (0 == '0', null == undefined) are a well-known source of subtle bugs and using it unprompted can read as unfamiliarity with the language's sharp edges rather than a stylistic choice.
• NaN and floating-point comparisons. NaN === NaN is false — use Number.isNaN(x) to check. Also worth knowing: floating-point arithmetic has the same precision caveats as every language, so exact equality checks on computed decimals are fragile.
• Object key ordering assumptions. Plain-object key iteration order is mostly insertion order in modern engines but has integer-key-ordering exceptions that are easy to forget — a Map has no such exceptions, another reason to prefer it for anything order-sensitive.

Narrating JavaScript code out loud

A chained, point-free style (arr.filter(Boolean).map(f).reduce(g, 0)) is idiomatic JavaScript but can read as opaque if typed silently — the same trade-off Python's comprehensions carry. State the intent of a chain before or while writing it ("filter out falsy entries, then transform each remaining one, then combine into a single total") so the interviewer follows the reasoning rather than parsing the chain after the fact. See Thinking Out Loud for the general version of this skill, independent of language.