Question 1

What are pure functions and immutability, and why do they matter in JavaScript apps?

Accepted Answer

Pure functions always return the same output for the same inputs without side effects; immutability avoids in-place mutation so data flow stays predictable. A pure function does not read/write external mutable state, perform I/O, or mutate its arguments. Immutability means updating data by creating new objects/arrays (or using structural sharing libraries) instead of changing existing ones. Benefits: easier testing, safer concurrency mentally, reliable memoization, and predictable UI rendering (e.g. React change detection). JS does not enforce purity — discipline and linting help. Prefer spreading/slicing carefully for shallow copies and know their limits with nested data.

Question 2

Explain map, filter, and reduce and when a simple for loop is better.

Accepted Answer

map transforms, filter selects, reduce aggregates; use loops when you need early exit, complex multi-accumulators, or hot-path performance. array.map(fn) returns a new array of mapped values; filter(predicate) keeps matching elements; reduce(fn, init) folds to a single value. Chaining them is expressive but can create intermediate arrays — sometimes reduce once or a for loop is clearer/faster. Prefer declarative methods for readability in business logic; prefer loops when profiling shows overhead, when breaking early, or when transforming large typed data. Avoid reduce abuse for simple maps/filters.

Question 3

What is a higher-order function? Write a simple withRetry example.

Accepted Answer

A function that takes functions as arguments and/or returns a function — used to abstract control flow and behavior. HOFs enable reusable policies: retry, debounce, authorization wrappers, middleware. They rely on closures to capture configuration. In interviews, implementing a small HOF shows API design skill. Discuss error handling, async vs sync, and preserving this/function names when wrapping. Too many nested HOFs can obscure stack traces — name wrappers and limit depth.

Question 4

Compare currying and partial application in JavaScript. When is each useful?

Accepted Answer

Currying transforms a multi-arg function into a chain of unary functions; partial application presets some args and returns a function of the rest. Currying: f(a)(b)(c) style enables compositional pipelines and point-free style. Partial: partial(f, a) returns (b, c) => f(a,b,c). JS functions are not auto-curried (unlike some FP languages); libraries (lodash/fp, Ramda) add tooling. Use partial for configuring callbacks (bind is a form of partial for this/args). Use curry when building many specialized functions from one generic. Trade-offs: curried APIs can confuse teams unused to FP and hurt ergonomics with TypeScript overloads. Prefer clarity for most product code.

Question 5

How far should a team push functional programming style in a large JavaScript/TypeScript product?

Accepted Answer

Adopt purity, immutability, and small HOFs where they reduce bugs; avoid deep point-free style and exotic abstractions that hurt onboarding and debugging. Pragmatic FP in JS: immutable updates for shared state, pure domain logic, declarative transforms, careful use of compose/pipe. Avoid: mandatory currying everywhere, replacing all loops religiously, or introducing category-theory types without team buy-in. Establish lint rules (no-param-reassign), choose an immutable strategy (structural sharing vs immer), and standardize error handling (Result types vs exceptions) — mixing styles is worse than either alone. Measure: review cycle time, bug rates in state logic, and new-hire ramp. Prefer TypeScript types that encode invariants over clever runtime FP tricks.

Functional Programming JavaScript Interview Questions

Other JavaScript interview topics