Functions

In JavaScript a function is not just a block of code but a full value and, at the same time, an object: you can assign it to a variable, pass it to another function, return it, and store it in a collection. Almost everything else in this topic grows out of that one property — callbacks, higher-order functions, function factories, and the module pattern.

Three function-related mechanisms reliably trip candidates up. First is the closure: a function remembers the variables of the scope where it was created, even after that scope has finished. Second is this binding: it is decided by how the function is called, not where it was written. Third are arrow functions, which have no own this or arguments. Work through each mechanism in the layers below — along with call/apply/bind, bound functions, and the historical IIFE.

Topic map

• First-class functions — a function as a value: assign, pass, return, store.
• Higher-order functions — functions that take or return other functions, and why map/filter/reduce are examples.
• Closures — a function bundled with its lexical environment, private state, and the loop-capture bug.
• this binding — the four rules that resolve this by call site, and their precedence.
• Arrow functions — concise syntax with no own this, arguments, new, or prototype.
• call, apply, bind — setting this explicitly: immediate call versus deferred binding.
• Bound functions — what bind actually returns and how new overrides the bound this.
• IIFE — the immediately invoked function expression and its private scope before let/const and modules.

Common traps

Interview relevance

Functions are a base block of the JavaScript interview, and depth shows fast. A candidate who says "this is decided by the call site, and an arrow takes it lexically" is instantly ahead of one who memorised "an arrow is just short function syntax".

Typical checks:

• What "first-class function" means and how callbacks and higher-order functions follow from it.
• Defining a closure as a live reference to a lexical environment, not a copy; the loop-capture bug and how let fixes it.
• The four this rules and their precedence; how an arrow differs from a regular function.
• The difference between call/apply/bind and what bind returns.

Common wrong answer: "a closure is a snapshot copy of the variables at the moment the function was created". In fact a closure holds a live reference to the environment: changes to outer variables are visible to the inner function, which is exactly why a loop with one shared var binding produces the capture bug.