277 JavaScript Frontend Developer Interview Questions & Answers

JavaScript passes every argument by value. With a primitive such as a number, JavaScript copies the primitive value, so changing the parameter does not change the original variable. With an object, JavaScript copies the reference value. Both references can point to the same object, so mutating a property through the parameter can change that shared object. Reassigning the parameter to another object still does not change the caller variable.

The practical rule is simple. A number gives a function its own copied value. Changing that local value does not change the number outside the function. An object works differently because the copied value tells JavaScript where the same object is stored. This means the function can change something inside that shared object. However, if the function makes its local name point somewhere else, the outside name stays unchanged. This difference matters because object changes can be visible in other parts of an application that use the same object.

1. Should I show both changing the parameter itself and changing a property inside the object?
2. Should I include a nested property to demonstrate that the same object is shared?

JavaScript always passes function arguments by value. The important detail is what that value contains.

For a primitive such as a number, the value itself is copied. If count is 10 and we call a function with count, the function receives its own value of 10. If the function later assigns 99 to its parameter, only that local parameter changes. The original count remains 10.

For an object, the value being copied is a reference to the object. A reference is a value that lets JavaScript reach the object. The caller variable and the function parameter therefore contain separate copies of a reference that points to the same object.

This explains two different behaviors. If the function changes person.details.score, it changes the shared object, so the caller can see the new score. If the function instead assigns a completely new object to its parameter, only the local parameter receives the new reference. The caller variable still points to the original object.

The same rule applies during normal assignment. Assigning one primitive variable to another copies the primitive value. Assigning one object variable to another copies the reference value, not the whole object.

This matters in frontend code because shared objects are common in application state, configuration, and data passed between functions. Accidental mutation can create unexpected changes. A shallow copy such as object spread creates a new outer object, but nested objects can still be shared. A deep copy requires a separate operation such as structuredClone when the data is supported. JavaScript is not pass by reference. It is pass by value in both cases.

The example uses one number and one object with a nested details object. The number parameter is reassigned, but the original number stays unchanged because the primitive value was copied. The object parameter is also reassigned, and that reassignment does not change the caller variable because only the local copied reference changes. Before that reassignment, the function changes details.score. That mutation is visible outside the function because the copied reference and the caller reference point to the same object.

A common mistake is saying that objects are passed by reference. JavaScript passes the reference value by value. Another mistake is assuming that assigning a new object to a function parameter replaces the caller variable. It does not. Developers also sometimes think an object spread automatically copies every nested object. It makes a shallow copy, so nested objects may still be shared.

Start with the sentence that JavaScript always passes arguments by value. Then explain that a primitive value is copied directly, while an object reference value is copied. Use one example to separate parameter reassignment from object mutation. That distinction is the key point the interviewer is testing.

A JavaScript object is a value that stores properties. Each property has a string or symbol key and a value. A property value can also be a function, which is commonly used as a method. Objects are mutable, and variables can hold references to the same object, so changing that object through one reference can be visible through another. I use plain objects when I want to represent related data with meaningful property names.

A JavaScript object is a way to keep related information together. For example, a user can have a name, an age, and an action that creates a greeting. Each piece of information has a name so the program can find it. The program can read a value, change it, add another value, or remove one. Two variables can also refer to the same object, so a change made through one variable can be seen through the other. Objects work well for records with named information, while other structures are better for ordered lists or specialized key and value storage.

1. Would you like me to compare an object with a primitive value, an array, a Map, and JSON text?
2. Would you like me to explain references, prototypes, property ownership, and enumeration with a small example?

A JavaScript object stores properties. Every property key is a string or a symbol. If another type is used as a normal object property key, JavaScript converts it to a string unless it is already a symbol. A property value can be any JavaScript value. A function used as a property value can act as a method.

An object literal is a common way to create an object. For example, { name: "Maya", age: 30 } creates two own properties. We can read them with user.name or user["name"]. We can change a property with user.age = 31.

Objects are mutable. This means their properties can change after the object is created. JavaScript always passes values by value. For an object, the value being copied is a reference to the object. If two variables contain references to the same object, mutation through either reference affects that same object. Reassigning one variable does not change the other variable.

Objects can also inherit properties through a prototype chain. If a property is not found directly on an object, JavaScript can look for it on the object's prototype and continue through the chain. Object.hasOwn() checks whether a property belongs directly to the object.

Enumeration means visiting properties. Object.keys() returns own enumerable string keys. It does not include symbol keys or inherited keys. Object.getOwnPropertySymbols() can retrieve own symbol keys.

A primitive value is not a mutable collection of properties. An array is an object with special behavior for indexed elements and its length property. A Map is a dedicated key and value collection that accepts keys of any JavaScript value type. JSON is a text format, not a live JavaScript object. JSON.parse() converts valid JSON text into a JavaScript value.

For records with known named fields, a plain object is usually simple and natural. For dynamic key and value storage, especially when keys are objects or other non string values, Map can be a better choice.

The example creates one object literal with string keyed properties, a symbol keyed property, and a method. It reads and changes properties, then copies the object reference into another variable to show that both variables refer to the same object. It uses Object.hasOwn to distinguish an own property from a property found through the prototype chain. It uses Object.keys to enumerate own enumerable string keys and Object.getOwnPropertySymbols to retrieve the symbol key. It then contrasts the object with an array, a Map, and JSON text.

A common mistake is saying that JavaScript passes objects by reference. JavaScript always passes values by value. For an object, the copied value is a reference to the object. Another mistake is assuming that assigning an object to another variable creates a new object. It only copies the reference value. Developers also sometimes use an object when an array is better for an ordered sequence or when Map is better for dynamic keys. Another mistake is treating JSON text as if it were already a JavaScript object. JSON.parse() is needed to convert valid JSON text into a JavaScript value. It is also incorrect to assume that Object.keys() includes symbol properties or inherited properties.

Start by saying that an object stores properties with string or symbol keys. Give a small object literal example. Then explain mutation, copied reference values, prototypes, ownership, and enumeration. Finish by briefly comparing objects with primitive values, arrays, Map, and JSON text. This shows both JavaScript knowledge and practical judgment.

A copy is shallow when only the outer object is new while nested objects still refer to the same objects as the original. Object spread and Object.assign make shallow copies. structuredClone is a browser API that creates independent nested values for supported data and preserves relationships such as two properties pointing to the same cloned child. A JSON round trip can create independent plain data, but it changes or loses some JavaScript types and cannot handle cycles.

A shallow copy gives you a new outer container, but some values inside it still belong to the original data. If a nested list or child object changes through one copy, the other can see that change too. A deep copy creates separate nested values, so later changes do not affect the original. The choice matters when data contains dates, maps, repeated references, cycles, or functions, because each copying method handles these values differently. The key question is whether nested values keep sharing the same underlying objects or become independent copies.

1. Should the copied value support cycles and shared references?
2. Do Date and Map values need to keep their original types?
3. Should functions be copied, rejected, or kept by reference?

Object spread and Object.assign copy the source object's own enumerable properties into a new outer object. Primitive values are copied directly. For an object valued property, the copied value is a reference to the same nested object. That is why the result is shallow.

Suppose the source contains a nested array, a Date, a Map, and one child object referenced by both left and right. After using object spread or Object.assign, the outer object has a new identity, but the nested array, Date, Map, and shared child still have the same identities as in the source. left and right still point to the same child.

In evergreen browsers, structuredClone is a browser API that uses the structured clone algorithm. It creates new nested objects, arrays, Date values, and Map values for supported data. A Date remains a Date. A Map remains a Map. If left and right originally reference the same child, both properties in the clone reference the same new cloned child. The clone does not share that child with the original. Cyclic references are also preserved. Ordinary functions are not supported, so structuredClone throws a DataCloneError when it reaches one.

A JSON round trip using JSON.stringify followed by JSON.parse can create separate nested plain data, but it is not a general deep clone. Date values become strings. Map values normally become empty plain objects unless custom conversion is provided. Repeated references lose their shared identity because each occurrence is serialized separately. Cycles make JSON.stringify throw a TypeError. Function valued object properties are omitted during serialization.

In production, object spread or Object.assign is useful when only the outer level needs to change and nested sharing is intentional. structuredClone is useful when supported nested data must be independent. A deep clone can take more time and memory because it must visit and allocate nested values.

The example creates one source object containing a nested array, a Date, a Map, and one shared child referenced by two properties. Spread and Object.assign create new outer objects but keep the original nested identities. structuredClone creates independent supported nested values while preserving the fact that left and right refer to one shared child inside the clone. The JSON round trip creates separate plain data, converts the Date to a string, turns the Map into an empty plain object with normal serialization, and does not preserve the shared child identity. Separate checks show that structuredClone supports cycles but rejects ordinary functions, while JSON serialization rejects cycles and omits function valued object properties.

A common mistake is thinking that a new outer object means every nested value is also new. Another is calling object spread or Object.assign a deep copy. Some developers also use a JSON round trip as a universal clone and forget that Date, Map, shared identity, cycles, undefined values, and functions do not behave like ordinary JSON data. Another mistake is assuming structuredClone is part of the ECMAScript language or that it can clone every JavaScript value. In browsers it is a Web API, and ordinary functions are not supported.

Start by comparing identity. Say that spread and Object.assign create a new outer object but reuse nested object references. Then explain that the browser structuredClone API creates new supported nested values and preserves internal relationships. Finish by explaining why a JSON round trip is only suitable for simple JSON shaped data.

A JavaScript array is an ordered object designed to hold a sequence of values. Its positions start at index 0, and its length usually tracks one more than the highest index. I can read or replace values by index and use methods such as push, pop, map, filter, and slice. Arrays can contain any JavaScript value, including other arrays. Because an array is an object, assigning it to another variable copies the reference value, so both variables can refer to the same array.

A JavaScript array is useful when I need to keep several values in a clear order. Each value has a numbered place, beginning with 0. I can look up a value, replace it, add new values, remove values, or go through the values one by one. An array can hold numbers, text, records, or other arrays. Some actions change the original collection, while others make a new collection. This matters because changing shared information can also affect another part of an application that uses the same collection.

1. Would you like me to explain common array methods as well as the basic definition?
2. Should I compare arrays with other JavaScript collection types?

A JavaScript array is an Array object designed for an ordered sequence of values. Its normal array indexes start at 0. An array index can range from 0 through 4294967294. The length property is automatically maintained and is one greater than the highest existing array index when that index determines the end of the array. Setting an element beyond the current end increases length. Reducing length deletes elements whose indexes are no longer inside the new length.

I read or write an element with syntax such as items[0]. Arrays are dynamic, so their length can change. Methods such as push, pop, splice, sort, and reverse mutate the original array. Methods such as map, filter, slice, concat, and toSorted return a new array instead of changing the original array. These new arrays are shallow results. If an element is an object, the new array can still contain a reference to that same object.

Arrays can also be sparse. For example, assigning a value to items[5] on an empty array makes its length 6, but indexes 0 through 4 can remain missing. A missing position is not the same as an existing element whose value is undefined. Some array methods skip missing positions, so sparse arrays can produce surprising behavior and are usually best avoided in application code.

Nested arrays are simply arrays that contain other arrays. They are useful for data such as rows and columns or groups of values.

JavaScript always passes arguments by value. For an array, that copied value is a reference to the array object. Assignment between variables works the same way. Mutating the shared array is visible through every reference to that object, but reassigning one variable does not reassign another variable.

Use an array when order and numeric indexes matter. Use a plain object for named properties, Set for unique values, Map for keyed entries, and a typed array when you need a fixed numeric element type and binary data.

This example creates an ordered array, reads and writes indexes, adds a value, creates a filtered array, demonstrates a nested array, and shows reference behavior. The alias variable receives a copy of the reference value, so pushing through alias changes the same array referenced by scores. The array created with slice is a different outer array. Slice makes only a shallow copy, so if the elements were objects, those object references would still be shared between the two arrays.

A common mistake is thinking an array is completely separate from objects. In JavaScript, an array is an object with special indexed behavior and a length property. Another mistake is assuming assignment copies all array elements. Assignment copies the reference value, so both variables can refer to the same array object. Developers also sometimes confuse a missing position in a sparse array with an existing element whose value is undefined. Another mistake is expecting every method to leave the original array unchanged. Methods such as push, splice, sort, and reverse mutate it. Finally, a shallow copy does not deeply copy objects stored inside the array.

Start by saying that an array is an ordered, zero indexed object for a sequence of values. Then explain length, index access, mutation, and reference behavior. Mention one mutating method and one method that returns a new array. Finish by briefly comparing Array with Object, Set, Map, and typed arrays.

A function declaration can normally be called before its source line because JavaScript creates and initializes that function binding before the script starts running its statements. A function expression assigned to const cannot be used before the const declaration runs because that binding is still in its temporal dead zone. Function expressions may also have their own name, which can make stack traces and debugging clearer.

The practical difference is when each function becomes ready to use. With the first form, JavaScript lets you call the function before the line where you write it. With the second form, when the function is stored in a constant variable, you must wait until that line has run. Calling it too early causes an error. The second form can also give the function its own useful name. A clear function name makes error reports easier to read when something goes wrong.

1. Should I explain the behavior in a normal browser script rather than a module?
2. Should I also explain how function names appear in stack traces?

In a classic browser script, JavaScript prepares declarations before it starts executing statements. A function declaration is created and initialized during this preparation step. Because the function value already exists, code can call it before the declaration appears in the source.

A const declaration is handled differently. JavaScript creates the const binding before execution, but it leaves that binding uninitialized until execution reaches the declaration. The time before initialization is called the temporal dead zone. Reading the binding during that time throws a ReferenceError. The function expression is therefore not available through that const variable before its declaration runs.

For example, calling declaredFunction before its declaration works. Calling expressedFunction before const expressedFunction = function namedExpression() {} throws a ReferenceError. After the const declaration runs, expressedFunction can be called normally.

A function expression can be anonymous or can include its own name. For example, function namedExpression() {} gives the function an explicit name. An anonymous function assigned directly to a const variable will also normally receive an inferred name from that variable in modern JavaScript. Meaningful names are useful because browser stack traces can show them when an error occurs. An explicit name can also be useful inside the function itself.

In production code, choose declarations when calling a function earlier in the file improves organization and the early availability is intentional. Choose const assigned expressions when you want the function to become available only after that declaration runs. Performance and memory differences are usually not useful reasons to choose between these forms.

The example uses a classic browser script. It first calls declaredFunction before the declaration appears. That call succeeds because the function declaration is initialized before statement execution starts. It then tries to call expressedFunction before its const declaration. Accessing that binding throws a ReferenceError because the const binding is still in its temporal dead zone. The error is caught so the rest of the example can continue. After initialization, expressedFunction runs normally. The expression uses the explicit name namedExpression so debugging output and stack traces can show a meaningful function name.

A common mistake is saying both forms are hoisted in the same way. They are not. A function declaration is initialized before statement execution, while a const binding exists but remains uninitialized until its declaration runs. Another mistake is saying the function expression itself causes the temporal dead zone. The temporal dead zone belongs to the const binding. Candidates also sometimes say anonymous function expressions never have useful names. When an anonymous function is assigned directly to a variable, modern JavaScript can infer a name from that variable. An explicit function expression name can still provide a clear identity for debugging and for references from inside the function.

Start with the visible behavior. Say that a function declaration can be called before its source line, while a const assigned function expression cannot. Then explain declaration initialization and the temporal dead zone. Finish by mentioning that meaningful function names help make stack traces easier to understand.

A callback is a function that I pass to other code so that code can call it when needed. For example, I can pass handleClick to addEventListener, and the browser calls it when the click event is dispatched and supplies an Event object. I can also pass a callback to map, and map calls it once for each array element. Passing handleClick gives the function itself. Writing handleClick() calls it immediately and passes its return value instead.

A callback is a piece of work that you give to something else so it can run that work at the right time. On a web page, I might give one piece of work to a button. The browser runs it when a person clicks the button. I might give another piece of work to a list operation. That operation runs the work once for each item. The important idea is that I give the work itself. I do not run it while I am setting things up.

1. Would you like me to show both a browser event example and an array method example?
2. Should I explain which arguments each caller gives to the callback?

In JavaScript, functions are values. This means a function can be stored in a variable, passed as an argument, and later called by other code. A function passed for another piece of code to invoke is commonly called a callback.

For a browser example, suppose I define handleClick and pass it to button.addEventListener. I write handleClick, not handleClick(). The browser keeps the listener function. When the click event is dispatched to the button, the browser invokes handleClick and supplies an Event object that describes the event.

An array method works in a similar way, although map normally invokes its callback synchronously. If I call numbers.map(doubleNumber), map invokes doubleNumber once for each array element. On each call, map supplies the current element, its index, and the original array. The callback can ignore arguments it does not need.

Passing handleClick means passing the function value without executing it. Calling handleClick() executes the function immediately. Its return value is then passed as the listener argument. If handleClick returns undefined, no usable callback function is passed, so the intended click handler is not registered. This is different from passing handleClick itself.

Callbacks are common in browser event handling and array operations. A callback can also use values from its surrounding scope. This behavior is called a closure when the function keeps access to that surrounding state. In production code, callbacks should stay focused, use the arguments supplied by their caller correctly, and avoid unnecessary work inside frequently triggered events. A callback is not automatically asynchronous. The caller determines when it is invoked.

The example creates a button and registers handleClick by passing the function itself. The browser invokes handleClick when the click event is dispatched and supplies the Event object. The example also calls map with doubleNumber. The map method invokes doubleNumber once for each number and supplies the current value, index, and original array. The code intentionally does not write handleClick() during registration because that would execute the function immediately and pass its return value instead of passing the callback function.

A common mistake is writing handleClick() when registering an event listener. That calls the function immediately instead of passing the function for the browser to invoke. Another mistake is assuming the callback decides which arguments it receives. The code that invokes the callback decides what arguments to supply. Developers also sometimes assume every callback is asynchronous. Array callbacks such as the callback passed to map normally run synchronously during the map call, while an event listener runs when the matching browser event is dispatched.

Start by saying that a callback is a function passed to other code for that code to invoke. Then give one event listener example and one array method example. Clearly name who calls each callback and what arguments it supplies. Finish by explaining that handleClick passes the function, while handleClick() executes it immediately.

A higher order function is a function that accepts another function, returns a function, or does both. In JavaScript, functions are values, so we can pass them around like other values. This is useful for reusable behavior. For example, a filter helper can accept a predicate function, while a formatter factory can return a function that remembers its configuration through a closure.

A higher order function lets one piece of code receive or create another piece of behavior. Instead of putting every rule inside one function, we can give the function a rule to use. We can also create a new function that remembers a setting for later. This makes code easier to reuse because the main function controls the process while another function controls the changing behavior. JavaScript supports this naturally because functions can be stored in variables, passed to other functions, and returned as results.

1. Would you like me to show both a function that accepts another function and one that returns a function?
2. Should I also explain how a returned function remembers values from the function that created it?

A higher order function is any function that accepts a function as an argument, returns a function, or does both.

Consider a function called selectItems. It receives an array and a predicate. A predicate is a function that returns true or false for a value. selectItems passes each item to that predicate and keeps the items for which the predicate returns true. selectItems is higher order because it accepts another function.

JavaScript array methods use the same pattern. Methods such as filter, map, and some accept callback functions that define what should happen for each array element.

A function can also be higher order by returning another function. For example, createFormatter can receive a prefix and return a formatter function. The returned function can still access that prefix later. This works because the returned function forms a closure. A closure means the function keeps access to bindings from the lexical scope where it was created, even after the outer function has finished running.

This pattern is useful when the main process stays the same but one part of the behavior needs to change. Frontend event utilities use the same idea when they accept callbacks or create configured event handlers.

The main tradeoff is readability. Too many nested functions can make control flow harder to follow. A closure can also keep captured objects reachable while the returned function remains reachable. In production code, capture only the values that are actually needed and prefer clear named functions when several callback layers would make the code difficult to understand.

The example shows both forms of a higher order function. selectItems accepts a predicate function and uses it to decide which array values to keep. createFormatter returns a new formatter function. That returned function keeps access to the prefix binding from the lexical scope where it was created. The example selects active users and then formats their names with the same saved prefix.

A common mistake is thinking a function is higher order only when it returns another function. Accepting a function as an argument also makes it higher order. Another mistake is confusing a closure with a higher order function. A closure describes how a function keeps access to bindings from its surrounding lexical scope. Higher order describes a function accepting or returning functions. Developers can also create deeply nested callbacks when simpler named functions would be easier to read. Another mistake is capturing large objects in closures without needing them, which can keep those objects reachable longer than necessary.

Start with the definition. Then show one function that accepts another function and one function that returns another function. Explain that JavaScript functions are values. Then explain that the returned formatter keeps access to its prefix through a closure. Connect the idea to filter, map, and event handlers to show practical frontend use.

A JavaScript function is a callable object that groups statements so I can run them when needed. It can accept parameters and return a value. I can create one with a function declaration, a function expression, or an arrow function. Creating a function does not run its body. I call it separately when I want the code to execute. Functions can also be stored in variables or objects, passed to other functions, returned from functions, and used as callbacks.

A JavaScript function is a reusable piece of work that runs when it is called. You can give it input values, let it do some work, and receive a result back. This helps avoid repeating the same instructions in many places. JavaScript also lets you store a function in a variable or object, give it to other code, or return it as a result. A function can also remember values from the place where it was created. Creating a function and running that function are separate actions.

1. Would you like me to compare function declarations, function expressions, and arrow functions?
2. Should I also explain closures and callbacks with a small example?

A JavaScript function is a callable object. It contains code that executes when the function is called. A function can receive parameters. Arguments are the actual values supplied during a call. A function can return a value with the return statement. If execution finishes without returning another value, the call produces undefined.

A function declaration uses the function keyword with a name. A function expression creates a function as a value, often stored in a variable. An arrow function is another function form with shorter syntax. An arrow function does not create its own this binding. It uses this from the surrounding lexical scope. Arrow functions also cannot be used as constructors with new.

Creating a function and calling it are different actions. Creating the function makes the callable value available. A call such as add(2, 3) executes its body.

Variables declared inside a function are normally local to that function. A nested function can access bindings from its surrounding lexical scopes. If that nested function is later used elsewhere, it can continue to access those bindings. This behavior is called a closure.

Functions are first class values in JavaScript. They can be assigned to variables, stored in object properties, passed as arguments, and returned from other functions. A function used through an object property can act as a method. A function passed to other code so that code can call it is commonly called a callback.

Functions are used for event handling, calculations, validation, data transformation, reusable logic, and callbacks. Closures are useful for keeping related state. However, a closure can keep referenced data reachable in memory for as long as the closure itself remains reachable.

The example creates addition, subtraction, and multiplication functions using three common function forms. It calls them separately to show that creating a function does not execute its body. The makeCounter function demonstrates a closure because the returned function continues to access the count binding from its surrounding lexical scope. The calculator object shows a function used as a method. The runOperation function demonstrates first class function behavior by receiving another function as a callback and calling it.

A common mistake is thinking that creating a function also runs it. It does not. Another mistake is forgetting that a function with no explicit returned value produces undefined. Developers may also assume arrow functions create their own this binding, but they use this from the surrounding lexical scope and cannot be called with new. Another mistake is confusing parameters in a function definition with arguments supplied during a call. Closures are sometimes described as copying surrounding values, but they actually retain access to lexical bindings. Passing a function as a callback is also different from calling that function immediately.

Start by saying that a JavaScript function is a callable object that can accept parameters and return a value. Then clearly separate function creation from function calls. Briefly compare declarations, expressions, and arrow functions. Finish by mentioning local scope, closures, methods, callbacks, and first class function behavior.

I use arrow functions mainly for callbacks and other cases where I want this to come from the surrounding scope. I use regular functions when the caller should determine this or when I need an arguments object or constructor behavior. Arrow functions do not create their own this or arguments binding, cannot be called with new, and do not have a prototype property for constructing instances. Their concise expression body can make a simple callback easier to read without changing the result.

The practical difference is about how each kind of function gets information and how it can be called. One kind can receive its object context from the call itself. The other keeps the context from the place where it was created. This matters when a function is used as an object method, passed as a callback, or used to create an object. The shorter form is often convenient for small callbacks, but it cannot replace the regular form in every case. Choosing the right form prevents unexpected values and invalid constructor calls.

1. Should the object method use the object as its this value?
2. Should the callback keep this from its surrounding function?
3. Does the function need to support calls with new?

A regular function gets its this value from how it is called. For example, if obj.show() calls a regular function stored as show, this normally refers to obj. An arrow function does not create its own this binding. It reads this from the surrounding lexical scope. Because of that, an arrow is usually a poor choice for an object method when the method needs this to refer to the object receiving the call.

This same behavior is useful for callbacks. An arrow callback can keep the this value of its surrounding function without bind or a saved variable.

A regular function also receives its own arguments object when it is called. An arrow function does not create an arguments binding. If an enclosing regular function has arguments, the arrow can read that outer binding. In modern code, rest parameters such as (...args) are usually clearer when an arrow needs a list of supplied values.

Arrow functions are never constructable, so calling one with new throws a TypeError. They also do not have their own prototype property. An ordinary function declaration or function expression is normally constructable and has a prototype property. However, not every non arrow function is constructable. For example, method definitions in object literals and classes cannot be called with new and do not have a prototype property for construction.

For a simple expression, an arrow can return the expression without writing return. For example, x => x * 2 returns the calculated value. This changes the syntax, not the result of the calculation. It is useful when the shorter form is easier to read.

The example uses one object to show how this differs, one regular outer function to show an arrow callback keeping the surrounding this value, and constructor checks to show constructability and prototype behavior. The regular object method receives the object as this because it is called through that object. The arrow method does not get a new this binding from the method call. The regular function receives its own arguments object, while the arrow callback uses a rest parameter. An ordinary function declaration can be called with new and has a prototype property. The arrow constructor attempt throws a TypeError and the arrow has no own prototype property.

A common mistake is thinking an arrow function is only shorter syntax for a regular function. Another mistake is using an arrow as an object method and expecting this to refer to the object that made the call. Developers may also expect an arrow to create its own arguments object, even though it can only read an outer arguments binding if one exists. Another mistake is calling an arrow with new or expecting it to have its own prototype property. It is also incorrect to assume every regular looking function is constructable, because object and class method definitions cannot be called with new.

Start with lexical this because it is the most important practical difference. Then mention arguments, new, and prototype. Also point out that ordinary function declarations can be constructors, while object and class method definitions are not constructable. Finish by explaining that concise arrow bodies are mainly a readability choice.

I normally use const by default, use let when the binding must be reassigned, and avoid var in modern code. var is scoped to the containing function, while let and const are scoped to the nearest block. var can be redeclared and reassigned. let can be reassigned but cannot be redeclared in the same scope. const can do neither. All three are hoisted, but let and const stay unavailable in the temporal dead zone until their declaration runs.

The main difference is where a name can be used and whether that name can later point to another value. One form can remain visible across a whole function even when it was written inside a smaller section. The other two stay inside the nearest pair of braces. They also have different rules about creating the same name again and changing what the name points to. These differences matter because they can make code easier to understand or cause surprising errors when a name is used in the wrong place or changed unexpectedly.

1. Should I explain the behavior in a normal browser script rather than a module?
2. Would you like me to include what happens before each declaration is reached?

I would start with the practical rule. Use const by default. Use let when the binding must point to a different value later. Avoid var in new code unless there is a specific reason to work with older patterns.

var has function scope. If it is declared inside an if block or loop inside a function, the binding is still visible throughout that function. At the top level of a classic browser script, a top level var declaration also creates a property on the global object. let and const have block scope. A binding declared inside an if block or loop is only available inside that block.

var allows both redeclaration and reassignment in the same scope. let allows reassignment, but declaring the same name again in the same scope causes a syntax error. const also rejects redeclaration, and its binding cannot be reassigned after initialization. A const declaration must also have an initializer when it is declared.

const does not make an object immutable. It only prevents the binding from pointing to another value. If a const binding holds an object, properties of that object can still be changed unless another technique prevents mutation.

All three declarations are hoisted. This means their bindings are created before normal execution reaches the declaration. The important difference is initialization. A var binding is initialized with undefined, so reading it before its declaration gives undefined. A let or const binding remains unavailable from the start of its scope until execution reaches its declaration. This period is called the temporal dead zone. Reading the binding during that period causes a ReferenceError.

In production code, block scope makes variable lifetime easier to see and reduces accidental reuse. This is why const and let are normally clearer choices than var.

The example uses a classic browser script and one function so the scope rules are easy to see. Inside the function, var is declared inside an if block but remains visible after the block because it has function scope. let and const stay inside that block, so accessing them outside it causes ReferenceError. The loop also shows that a let loop variable is limited to the loop block. The example then shows valid reassignment, object mutation through a const binding, var hoisting, and the temporal dead zone without stopping the rest of the script.

A common mistake is saying that let and const are not hoisted. Their bindings are created before execution reaches the declaration, but they cannot be accessed during the temporal dead zone. Another mistake is saying that const makes an object immutable. It only prevents reassignment of the binding, so an object stored in a const binding can still be mutated. Candidates also sometimes forget that var ignores ordinary block boundaries inside a function, assume that a var declared in a loop is block scoped, or forget that const requires an initializer.

Start with the practical choice: const by default, let when reassignment is needed, and usually avoid var. Then compare scope, redeclaration, reassignment, and access before declaration in that order. Mention that const protects the binding rather than making an object immutable.