The most critical JavaScript question you will get asked in most interviews is: What is a Closure?

To answer that, we need to go back to fundamentals because not knowing those concepts is what stops you from getting the JavaScript job you deserve. And what’s crazy is that you are using these concepts every single day without even realizing it.

Once you discover those fundamentals, you will be able to pass 90% of the JavaScript interviews from the back of your head, from junior to senior level, without memorizing anything before the interview.

So in this article, I will show you the Top JavaScript Interview Questions in 2022 and how to answer them, so you can finally pass them interview and get that highly paid JavaScript developer job you deserve.

If you prefer to watch instead of reading, check this article as a video on youtube.

Back to closures.

A Closure allows a function to access things that are outside of itself. To truly understand closures, we need to understand another core JavaScript concept.

Scope.

If you are looking for a fancy definition, the scope defines the accessibility of variables. The bag of variables that we have access to at any given point of the code.

There are different scopes.

We have global, block, function, and module scope.

The global scope contains variables that everyone (all the other scopes) has access to. When the code runs in the browser, the global scope is the famous window object. The block scope represents variables inside a code block. The function scope contains variables inside the function block. And the module scope contains variables, functions, and classes defined inside a certain module.

Normally we have access to the global scope and our local scope (the block or function scope around us). What closures do is that they give us access to a different scope.

Accessing the enclosing scope via Closure
In its origins, the word “Closure” comes from enclosing. A concept from functional programming refers to sticking functions together with other things. They allow us to access the things around our functions, the surrounding scope (also called the lexical scope).

Even though you might now have used closures in your everyday coding, they come in handy in many use cases. Closures are helpful when using private variables, callbacks, and handling events.

What is the disadvantage of using closures?

Every function that accesses the “surrounding scope” via closures carries this information around. Like a ball and a chain, this puts a lot of pressure on our memory until JavaScript decides is no longer helpful (garbage collection). If you want me to write an article specifically on closures, let me know in the comments :)

Accessing the enclosing scope via closures can put pressure on the memory in JavaScript.

Now let’s move on to the following core fundamental concept often asked in JavaScript interviews… Hoisting.

So what is “hoisting” in JavaScript?

Hoisting is defined as lifting our declarations to the top of a function or global scope. That is a bit of a simplistic definition.

In reality, variables and function declarations are not moved anywhere.

They are simply visited and registered in the environment before any code is executed. So the JavaScript Engine checks functions and variable declarations before executing the code.

This brings us to the next question…

How are var, let, and const hoisted?

Simply put, they are all housed to the top of their scope. Yet, let, and const are not initialized, while var variables are initialized with undefined. At the same time, remember, var and let can be declared without being assigned a value, while const must be assigned a value while declared.

Talking about global scope, have you ever wondered…

What do we use this for in JavaScript?

This question drives developers crazy and makes JavaScript a bit of a funny language. In modern programming languages like Java, Python, or C#, the word this, or self inside a function, refers to the object that called that function.

In our bellowed JavaScript, the word “this” depends on how the function is being called, not necessarily on who called it. That’s what we call the function context.

The context in JavaScript is the “how we call” the function. The thing with context is that it can be different each time a function is called. (unless we use the bind() method to enforce it if you want me to write an article on the bind and apply method, let me know in the comments).

Long story short: We use this to access properties of the global or surrounding scope depending on how the function has been executed. Alone, “this” refers to the global scope where the code is being executed. In an object, “this” refers to the object’s properties. In a function, “this” refers again to the global scope.

And this brings me to the next question…

What is the main benefit of using arrow functions?

Besides being easier to write and read… isn’t that arrow just super cool?

Named Arrow Function (Source: Mozilla MDN)

Besides the easy syntax, the main benefit of arrow functions is that they remove the uncertainty of what “this” refers to. In an arrow function, this always refers to the lexical context (scope) in which is being called. So no more confusion about the “context”.

Now let’s go a bit back in time with our next question.

What is the difference between “var” and “let” keywords?

This question is a bit 2010ish, but you might still get it today. The major difference between var and let is that the scope of a variable declared with let is local and only exists in the current code block. A variable declared with var exists in the global scope.

By now, you are probably aware that one interesting concept comes up repeatedly. You guessed it, the scope. All these questions are testing your understanding of how the JavaScript Scope works. Together with “prototypal inheritance,” which I will explain in a few seconds, are two of the fundamental pillars in JavaScript.

2 core Pillars in JavaScript

But before we get there, let’s talk about another difference.

What is the difference between “let” and “const”?

As the name indicates, const tells JavaScript something is a constant. That variable won’t change (it won’t be reassigned). Let tells JavaScript the variable will be resigned. As a rule of thumb, we use let for loops or counters as it also signals that the variable will be used only in the block it’s defined in.

Const, in exchange, can’t be either updated or re-declared (which has enormous implications when using TypeScript). If you want me to deep dive into that, drop me a line in the comments).

Ready for another “differences” question…

What is the difference between “null” and “undefined”?

A variable with value null has been assigned a value, that is null. A variable that is undefined, has been declared but not defined yet. It holds no value yet. Null and undefined are both primitive data types in JavaScript.

Now let’s take a bit of a break and dive into what I consider to be one of the pillars of JavaScript programming, which might make you think about things you got from your grandparents, like your genetics.

That’s right, the next question is...

What is “Prototypal Inheritance” in JavaScript?

Simply said, a prototype is a parent. A parent that you inherit your properties from.

For example, when you create a simple JavaScript array, you will find it has methods like map, reduce, or length. You did not add those methods when creating the array. They come from its parent, the array prototype that is built into JavaScript.

Prototypal inheritance exists in JavaScript with the same purpose as classes in object-oriented languages like Java or C#. They help us re-use properties and functionality quickly and not have to reinvent the wheel.

Anytime you look for a property in an object, if not found, JavaScript will also go and look at its prototype. Everything can have a prototype, and a prototype can have another prototype. That is what we call the prototype chain. It’s a bit abstract, but you can think of it as a set of Matryoshka dolls.

This chain stops only when there are no more prototypes left. You can access the prototype by using the “prototype” property in any object :)

An illustration of the prototype chain.
Congrats, you’ve already grasped two core pillars of JavaScript as a programming language. Scope and Prototypal Inheritance.

We will finish with concepts from another fundamental pillar in the JS world: asynchronous programming, which brings me to the next question.

What is the difference between a callback and a promise in JavaScript?

Before we answer that, if you want more articles like this to help you become a JavaScript master, I don’t have a posting schedule, so make sure you follow me to get them in your feed.

Back to callback and promises.

Let’s start by defining these two first. A call back is a function that is called back after something happened. Is like telling your friend, hey, when you are finished ordering tacos, take this function and run it for me, “call it back”.

We can do that because, in JavaScript, functions are objects. Objects that can be called or invocated. So we can pass them as inputs to other functions. The issue with callbacks is that when you need to nest lots of them, it leads to “callback hell.” Code gets unreadable fast, and remember, we write code for machines and humans.

Callback Hell

So Promises came to the rescue in the ES6 version of JavaScript in 2015.

A promise in JavaScript, like one in real life, is an expectation that we will do something. We can either fulfill the promises we make (which I hope you do) or we can not fulfill them and reject them. Like when you fetch data from the backend, you expect it to arrive. The nice thing is that JavaScript won’t wait until the promise is resolved.

JavaScript will move on and execute other code and come back when this is solved. This is what we call asynchronous programming.

To recap, a callback can be any function that will be passed as an input to another function.

A Promise is a built-in object in javascript that allows us to write asynchronous code beautifully and avoid the call-back hell. I could talk for a few hours about promises, if you want me to, I will do a longer article about the topic. Just let me know in the comments.

Talking about promises…

What is the difference between a Promise and Async/Await?

Well, basically, none. Async/await only makes promises easier to read in a sequential way, one after the other. When you write asynchronous code with promises things can still look a bit nasty. You have all these statements that you don’t know when they close.

Async/Await makes it much easier for you to understand what happens, as you will understand what happens while reading things one by one.

Funny enough, Async/Await is made out of promises combined with another scary concept in JavaScript, generators. For simplicity, we won’t dive into generators right now. Keep in mind, depending on the level you are interviewing for, you might be required to go deeper into these things or not.

Senior JavaScript Developers are expected to understand how things work under the hood, while juniors and mid-levels can get away with much less. These questions are only the first step; to nail your interview, you must first make sure you avoid basic mistakes.

Check out this other article where I go over common mistakes in code interviews and how you can avoid them.

And if you are interested in accelerating your journey to senior and you would love to be part of a community of developers with the same growth mindset, check our free training here.