105 道问答题，一道一卡105 questions, one card each

In one line: “first class” means functions have the same standing as any other value — you can assign one to a variable, pass one as an argument, return one, and store them in arrays and objects.

This is a property of the language, not of a particular function. “JavaScript has first class functions” is correct; “this is a first class function” sounds wrong.

Why it matters: first class functions are the precondition for callbacks, higher order functions, closures and functional programming. You can only write arr.map(fn) because fn can be an argument in the first place.

Follow-up: the next three come as a set — first class (works as a value) → first order (touches no functions) → higher order (takes or returns a function). Get those three terms apart first.

In one line: an ordinary function that takes no function as an argument and returns no function either.

(a, b) => a + b is first order. arr.map(fn) is not — it takes a function.

The term almost never gets asked on its own. It exists to give “higher order” something to contrast with. Answer it in one sentence, then move on to higher order functions yourself — that shows you know these three questions travel together.

In one line: it takes a function as an argument, or it returns one — either one on its own makes it a higher order function.

You use them every day: map / filter / reduce / forEach / sort (they take a function), setTimeout / addEventListener (they take a function), and bind (it returns one).

The returning kind is what gets tested, because it is the shared foundation under currying, debounce and throttle, and React HOCs:

Follow-up: “Write a debounce” — the most common live-coding task there is, and at heart it is just “return a function and let the closure remember the timer”. Watch out for clearing the previous timer and forwarding this; plenty of people drop those.

In one line: two conditions. ① the same input always produces the same output; ② no side effects (it does not touch outer variables, mutate its arguments, fire requests, write to the DOM, or log).

Where impurity usually creeps in: Math.random(), new Date(), reading or writing globals, an arr.push() on the array you were handed, and console.log.

Why interviewers like this one: pure functions are easy to test (give input, assert output, no setup), easy to cache (same input, reuse the result — that is memoization), and easy to run concurrently (no shared state means no races).

Straight into React:

• A component’s render function must be pure — the same props and state have to produce the same UI. That is why StrictMode renders twice on purpose and catches things (see #332).
• A Redux reducer must be pure — otherwise time-travel debugging and replay do not hold up (see #352).
• Immutable updates are a hard rule precisely because mutating the array you were given makes the function impure.

Follow-up: “So where do the side effects go? ” — useEffect in React, middleware (thunk or saga) in Redux. Keeping pure logic and side effects apart is the core of that design.

In one line: it switches on strict mode — a batch of things that used to fail silently now throw, and some historical baggage is banned outright.

It covers four things; two or three of them are enough to answer:

• No implicit globals. x = 1 with a forgotten let quietly lands on window in sloppy mode, and throws ReferenceError in strict mode. This is its biggest single win.
• this inside a plain function is undefined instead of window — so a forgotten bind throws right there.
• Assigning to a read-only property, or deleting one that cannot be deleted, throws instead of failing silently.
• with is banned, duplicate parameter names are banned, and arguments no longer tracks the parameters.

Follow-up: “Do you still type it by hand?” — almost never: ES modules and class bodies are strict automatically. You only write it for old-style <script> tags or CommonJS. Saying so shows you know where things stand today.

One real connection worth adding: this is why writing to an object after Object.freeze throws — in sloppy mode it just fails silently. Our comment-tree exercise leans on exactly that to verify immutability.

In one line: four — global, function, block and module.

• Global — the outermost level. In a browser, a var declared here lands on window.
• Function — the territory of var and the parameters, visible anywhere in the function body.
• Block — any pair of {}. It only binds let / const / class; var ignores it completely.
• Module — every ES module file gets a scope of its own, so top-level declarations do not pollute the global scope.

One that people forget: the e in catch (e) has its own scope too.

Follow-up: “Give me an example of function scope against block scope” — a var declared inside an if is still readable after the if; a let is not. That is the thing you break most often when converting old var code to let.

In one line: during compilation the engine scans the code first and registers the declarations in the scope, so referring to something before its line does not always throw — but only the declaration is hoisted, never the assignment.

Four cases; keeping them apart is enough:

“let is not hoisted” is a common mistake. It is hoisted — otherwise an inner let x would not shadow an outer x. It is just marked uninitialised, so reading it throws. Correcting this scores well.

Follow-up: “What about function declarations against function expressions?” — function f(){} is hoisted whole; var f = function(){} hoists only f (whose value is undefined), so calling it early gives you TypeError: f is not a function. Note the two errors are different — that detail is how they tell recitation from understanding.

In one line: to resolve a variable, JS looks in the current scope, then one level out, and keeps going until the global scope; if it is still not there you get a ReferenceError. That inside-out path is the scope chain.

Two properties that matter:

• It only looks outward, never inward. An outer scope cannot see an inner one’s variables.
• The chain is fixed where the function is defined, not where it is called — this is lexical (static) scoping. That one sentence is what the question is really testing, and it is how closures work.

Follow-up: “Does this behave the same way?” — no, and this is the easiest thing to mix up. Variable lookup is lexical (where it was written), this is dynamic (how it was called). An arrow function’s this feels “variable-like” exactly because it does not define a this of its own and walks the scope chain outward to find one.

In one line: a function remembers the scope it was defined in — even after the outer function has finished, the variables inside are still alive, because that function is still referencing them.

Why does that happen? Because the scope chain is wired up at definition time (#297). Once the outer function returns, its variables would normally be collected, but garbage collection leaves them alone as long as some function still references them.

Four real uses — the interview wants uses, not the definition:

• Private state — counters, caches. Nothing outside can reach the variable; it can only go through the methods you expose.
• Debounce and throttle — the closure holds the timer.
• Currying and partial application — remembering the arguments received so far (#299).
• Every React Hook rests on it — the setState returned by useState, and the callback inside useEffect, are closures that captured the values of one particular render. The “stale closure” bug is the flip side of that.

Two follow-ups to expect:

① setTimeout inside a loop (see #282). With var there is one i for the whole loop and all three closures share it; let creates a new binding per iteration, so each closure remembers its own.

② Can a closure leak memory? It can — if the closure stays alive (hanging off a global, or an event listener you never removed), the entire scope it references cannot be collected. The fix is to unsubscribe in time, which is one of the reasons a React useEffect needs its cleanup function.

In one line: take a function that receives n arguments at once and reshape it into one that takes one at a time and returns a new function, only computing once they are all in.

add(1, 2, 3) becomes add(1)(2)(3). The implementation rests on a closure remembering the arguments received so far.

What it is good for — do not just say “showing off”:

• Reusing arguments — const log = level => msg => console.log(`[${level}] ${msg}`), then const warn = log("WARN").
• Deferred execution — nothing runs until every argument has arrived, which suits configuration-style APIs.
• Function composition — composition wants every function to take a single argument, and currying reshapes multi-argument functions into exactly that.

Follow-up: “What is the difference between currying and partial application?” — currying is strictly one argument at a time; partial application fixes a few now and takes the rest later (bind is partial application). This distinction comes up a lot.

They will also ask you to write a generic curry — the idea is: if you have enough arguments, call the function; if not, return one that keeps collecting.

In one line: an Immediately Invoked Function Expression — defined and called on the spot, in order to create an isolated scope.

Why the extra parentheses? Because a statement that starts with function is parsed as a function declaration, and a declaration cannot be called directly. Wrapping it in parentheses (or putting !, + or void in front) turns it into an expression.

What it solved back then: ES5 had no block scope and no modules, and every <script> shared one global namespace. An IIFE was the only way to isolate anything — jQuery plugins and UMD bundles are all written that way.

Follow-up, and this is the point of the question: “Do you still need it?” — mostly not: block scope plus let isolates variables, and an ES module has a scope of its own already.
Two situations are left: ① you need await at the top level and the environment does not support it, so you wrap a (async () => { … })(); ② inside output generated by a bundler.
The (async () => {…})() inside useEffect in our fetch variant exercise is case ① — an effect cannot be async, so an IIFE opens an async scope for it.

In one line: bundle data together with the methods that act on it, and organise the program around objects.

Four pillars — memorise these:

• Encapsulation — hide the internals, expose only the interface callers need. In JS you get it from closures or #private fields.
• Inheritance — a subclass reuses what the parent can already do.
• Polymorphism — same method name, different behaviour per object.
• Abstraction — you care what it can do, not how it does it.

What makes JS different, and this is the real question: it is prototype-based, not class-based. class is syntax sugar added in ES6; the prototype chain is still underneath — class A extends B compiles down to setting A.prototype.__proto__ = B.prototype.

The prototype chain in one line: read a property, and if the object does not have it the lookup walks up __proto__ one level at a time until null. Same idea as the scope chain — one looks up variables, the other looks up properties.

Follow-up: “Why did React move from classes to function components?” — because UI is easier to describe as “input → output” than as an object with a lifecycle. On top of that, this binding and code split by lifecycle instead of by concern were real, daily pain (see #322).