277 JavaScript Frontend Developer Interview Questions & Answers

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.

undefined usually means a value has not been provided or assigned, while null usually means the application deliberately represents an empty value. JavaScript produces undefined for cases such as a declared variable without a value, a missing object property, a missing argument, or a function that finishes without returning another value. typeof undefined is "undefined", but typeof null is "object" because of a historical JavaScript behavior. I normally use strict equality because null === undefined is false, even though null == undefined is true.

undefined and null both describe the absence of a useful value, but they usually communicate different intentions. JavaScript often gives you undefined automatically when no value was supplied. A developer usually writes null deliberately to say that a value is empty. This difference helps people understand whether something is missing naturally or was intentionally cleared. They can both appear where an application has no useful value, but they are not the same value. Choosing one clear meaning for application data makes code easier to understand and reduces unexpected behavior.

1. Should I explain both strict equality and loose equality?
2. Would you like examples from object properties, function arguments, and API data?

undefined is a primitive value that JavaScript commonly produces when a value is absent. For example, after let value; runs, value is undefined. Reading an object property that does not exist also returns undefined. If a function parameter has no matching argument, that parameter is normally undefined. A function with no return statement, or a bare return, also returns undefined.

null is also a primitive value, but developers normally assign it deliberately. For example, an application might set selectedUser to null to mean that no user is currently selected.

There is an old JavaScript behavior that often appears in interviews. typeof undefined returns "undefined", while typeof null returns "object". The result for null is a historical language behavior. It does not mean that null is an object.

Strict equality keeps the values separate. null === undefined is false. Loose equality treats them as equal to each other, so null == undefined is true. However, null == 0 and null == false are both false. In production code, strict equality is usually clearer when the exact value matters.

A useful convention is to let undefined represent omitted or not yet supplied values and use null when the application intentionally needs an empty value. This is a convention, not a JavaScript rule. The most important production rule is consistency with the data contract. This matters especially when sending JSON because object properties whose values are undefined are omitted by JSON.stringify, while properties whose values are null are included with the value null.

A common mistake is saying that null is an object because typeof null returns "object". null is a primitive value. Another mistake is treating null and undefined as identical because loose equality says null == undefined is true. Strict equality shows that they are different values. Developers may also use both values randomly for the same application state, which makes data contracts harder to understand. Another mistake is assuming an object property with value undefined behaves exactly like a property that does not exist. Reading either can produce undefined, but the property can still exist when it was explicitly assigned that value.

Start with the practical distinction. Say that JavaScript often produces undefined for a missing value, while developers usually use null to represent an intentional empty value. Then give one example of each, mention the unusual typeof null result, and finish with strict equality and consistent production use.

Spread and rest both use three dots, but they do opposite jobs. Spread expands values from an array or object into another place. Rest collects several values into one array or object. I use spread for tasks such as copying an array, merging plain objects, or passing array values as function arguments. I use rest for collecting function arguments or remaining values during destructuring. One important point is that object spread creates only a shallow copy, so nested objects are still shared.

Spread and rest use the same three dots, but the job changes based on where the dots appear. Spread opens a group of values so they can be placed somewhere else. Rest does the opposite. It gathers several values and keeps them together. This matters when copying lists, combining simple objects, sending several values into a function, receiving many function inputs, or taking some values while keeping the remaining ones. A key detail is that copying an object this way does not make new copies of objects stored inside it.

1. Would you like examples for both arrays and plain objects?
2. Should I also explain what happens when the data contains nested objects?

Spread syntax expands values. For an array, [...numbers] creates a new array and places each value from numbers into it. This is useful when you want a new outer array without changing the original array.

Spread also works with plain objects. {...user, active: true} copies the own enumerable properties from user into a new object and then sets active. If the same property appears more than once, the later value wins.

Spread can also pass values from an iterable as separate function arguments. For example, Math.max(...scores) passes each score as its own argument.

Rest syntax collects values instead of expanding them. In a function parameter such as function sum(...values), the remaining arguments are collected into a real array named values. A rest parameter must be the last parameter.

Rest also works in destructuring. With const [first, ...others] = numbers, first receives the first value and others becomes a new array containing the remaining values. With object destructuring, rest collects the remaining own enumerable properties into a new object.

The main limitation is shallow copying. If an object contains another object, spread copies the reference to that nested object. Changing the nested object through the copy can therefore also be visible through the original. Spread is convenient for normal frontend state updates and data transformation, but it is not a deep cloning tool.

The example shows the opposite roles clearly. Array spread copies array elements into a new array. Object spread merges plain objects into a new object, with later properties replacing earlier properties that use the same key. Function call spread expands array values into separate arguments. A rest parameter collects separate arguments into one array. Array destructuring rest collects the remaining array values. The nested object example shows the shallow copy limitation because both outer objects still refer to the same nested object.

A common mistake is thinking spread and rest are different operators. They use the same three dot syntax, and the surrounding syntax decides whether values are expanded or collected. Another mistake is assuming object spread performs a deep copy. It copies the outer object, but nested objects keep the same references. Candidates also sometimes place a rest parameter before another parameter, but a rest parameter must be last. Another mistake is expecting object spread to merge nested objects recursively. If two objects contain the same property, the later property replaces the earlier value rather than deeply combining it.

Start with the simplest contrast: spread expands and rest collects. Then show one short example of each. Mention array copying, object merging, function call spread, function parameter rest, and destructuring rest. Finish by stating that object spread creates only a shallow copy. That final point shows practical JavaScript understanding.

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 closure lets a function keep access to variables from the scope where that function was created. For example, createCounter can create a private count and return a function that changes it. The count stays available between calls even after createCounter has returned. Each call to createCounter creates separate state, so two counters do not share the same count. This is useful for small pieces of private frontend state, such as state used by an event handler.

A closure lets a function remember information from the place where it was created. This is useful when one part of a program needs to keep a value between calls without exposing that value directly to other code. A counter is a simple example. You give it a starting number, and each later call increases the remembered number. If you create two counters, each one remembers its own number. This pattern can help keep small pieces of page behavior separate, private, and easier to control.

1. Should the counter return the new value after each call?
2. Should I show that two counters keep separate state?
3. Would you like a frontend example using an event handler?

In JavaScript, a closure happens when a function keeps access to variables from the lexical scope where that function was created. Lexical scope means that which variables a function can use is determined by where the function is written in the source code.

For example, createCounter creates a local variable named count. It then returns another function. That returned function reads count, increases it, and returns the new value. After createCounter returns, its normal execution has finished. However, the returned function still refers to count. Because that variable is still reachable through the returned function, JavaScript keeps the required lexical environment available.

If createCounter is called twice, each call creates a separate count binding. Each returned function closes over the count from its own call. Calling the first counter does not change the second counter.

This is useful when a small function needs private state. A frontend event handler can capture information that it needs between events without putting that information in a global variable. Outside code cannot directly access the local count variable through the counter function.

Closures are not always the best choice for shared application state. If many unrelated parts of an application need to read or update the same state, a more explicit state design can be clearer. Closures also keep captured values reachable while something reachable still refers to the closure. Capturing large objects unnecessarily can therefore keep more memory in use than needed. When the closure and its captured environment are no longer reachable, that memory can become eligible for garbage collection.

The example calls createCounter with a starting value. Each call creates its own count binding and returns a function that captures that binding. Calling counterA increases only the count created for counterA. Calling counterB changes a different count created for counterB. The output shows that the captured state remains available after createCounter returns and that the two closures keep independent state.

A common mistake is saying that a closure copies the captured variable. In this example, the returned function keeps access to the count binding created by its own call to createCounter. Another mistake is thinking all counters share one count. Each call to createCounter creates a separate count binding. It is also incorrect to say that count disappears as soon as the outer function returns. The required lexical environment remains reachable through the closure. Finally, capturing large objects without a need can keep those objects reachable longer than expected.

Start with the practical idea that a closure lets a function remember variables from where it was created. Then show createCounter, explain why count remains available after createCounter returns, and prove that two counters have separate state. Finish with one frontend use and one memory consideration.

JavaScript is a programming language standardized through ECMAScript. In frontend development, browsers commonly run JavaScript so a page can respond to users, change page content, and communicate with remote services. JavaScript works with HTML and CSS through browser APIs such as the DOM, but those browser APIs are not part of the JavaScript language itself. JavaScript is also different from Java, Node.js, and frontend frameworks such as React.

JavaScript is the language that gives a web page behavior. HTML usually describes what is on the page, and CSS controls how it looks. JavaScript can react when a person clicks a button, types text, submits a form, or performs another action. It can also change what the person sees without loading a completely new page. It can request information from a remote service and use the result on the page. The same language can also run outside a web browser when another program provides an environment for it.

1. Would you like me to focus mainly on JavaScript in the browser?
2. Should I also explain how JavaScript differs from Node.js and frontend frameworks?

JavaScript is a programming language. Its standard is called ECMAScript. ECMAScript defines the core language, including values, objects, functions, classes, promises, modules, and expressions.

A web browser provides an environment where JavaScript can run. The browser also provides Web APIs. These include the DOM, events, Fetch, storage, and timers. These browser APIs are separate from the ECMAScript language.

For example, HTML can create a button. CSS can control how the button looks. JavaScript can register a function to handle a click event. When the user clicks the button, the browser reports that event and runs the registered JavaScript function. The function can then use the DOM API to change text or other page content.

JavaScript can also call the browser Fetch API to communicate with a remote service. Fetch returns a Promise that represents the future result of the request. JavaScript can process that result and then update the page.

JavaScript is different from Node.js. Node.js is a runtime environment that executes JavaScript outside a browser and provides its own APIs. JavaScript is also not Java. They are separate programming languages. React, Vue, Angular, and Svelte are frameworks or libraries used with JavaScript. They are not the JavaScript language itself.

This distinction matters in production because available APIs depend on the runtime environment. Code that uses the DOM expects a browser environment that provides the DOM. Developers should know whether a feature belongs to ECMAScript, a browser Web API, Node.js, or a framework before depending on it.

A common mistake is saying that JavaScript is a browser. A browser is an environment that can execute JavaScript. Another mistake is treating the DOM or Fetch as part of the ECMAScript language. They are browser Web APIs. Candidates also sometimes confuse JavaScript with Java even though they are separate languages. Another mistake is saying that Node.js is another language. Node.js is a runtime environment that executes JavaScript and provides its own APIs. Frameworks such as React are also not the JavaScript language.

Start by saying that JavaScript is a programming language standardized through ECMAScript. Then explain its practical browser role with one simple example, such as handling a button click and changing the page. Finish by clearly separating JavaScript from browser APIs, Node.js, Java, and frontend frameworks.

Frontend development is building the part of a web application that users see and interact with through their browser. HTML gives the page its structure, CSS controls its presentation, and JavaScript adds behavior and connects the page to browser APIs and backend services. A frontend developer also handles accessibility, responsive layouts, state, network requests, performance, testing, and security. The backend usually stores data and applies server side business rules, while the frontend communicates with it through network requests.

Frontend development means building the part of a website or web application that a person sees and uses in a browser. It includes the page content, its appearance, buttons, forms, menus, messages, and other interactions. The goal is to make the experience clear, usable, fast, safe, and suitable for different screen sizes and users. This work also includes getting information from services, showing loading or error states, remembering what the user is doing, and checking that the experience continues to work correctly as the application changes.

1. Should I explain frontend development at a general browser level or focus more on JavaScript responsibilities?
2. Would you like me to describe how the frontend communicates with backend services?

Frontend development is mainly the browser side of a web application. HTML describes the structure and meaning of the page. CSS controls layout and presentation. JavaScript adds behavior, updates the page, responds to user actions, manages application state, and uses browser APIs.

JavaScript can listen for events such as clicks and input. It can change the DOM, which is the browser representation of the page. It can also use Fetch to send HTTP requests to backend services and receive responses. The frontend then decides how to show loading, success, empty, and error states.

A frontend developer must also consider accessibility so people can use the application with keyboards, screen readers, and other tools. Responsive layouts help the interface work on phones, tablets, and larger screens. Performance matters because large amounts of JavaScript, slow network requests, expensive layout work, or frequent rendering can make the interface feel slow.

Testing checks that important behavior still works. Security means respecting browser protections such as the same origin policy, handling untrusted data safely, and avoiding unsafe DOM rendering.

The backend is different. It normally runs on servers, stores or processes data, applies trusted business rules, performs protected operations, and exposes services. The frontend and backend commonly communicate through HTTP requests and responses, often exchanging data such as JSON.

A common mistake is saying that frontend development only means making pages look good. It also includes behavior, accessibility, data communication, state, performance, testing, and security. Another mistake is treating JavaScript and browser APIs as the same thing. JavaScript is the language, while APIs such as the DOM and Fetch are provided by the browser. Candidates may also incorrectly say that frontend code should directly access a protected server database. In a typical web application, the frontend communicates with backend services, and those services control protected database access, authorization, and server side rules.

Start by saying that frontend development is the browser side of a web application. Then explain HTML, CSS, and JavaScript, followed by accessibility, responsive design, state, network requests, performance, testing, and security. Finish by clearly separating frontend responsibilities from backend services and explain that they commonly communicate through HTTP requests and responses.