Covering these topics makes you a Javascript Interview Boss - Part 1

You graduated from a Boot Camp or started taking CS classes, you find this thing in you for Web Development, and you knew that JS is the language of the web.

You've been working for almost a year as a Frontend Developer, everything is good, JS is a little scary, you have a bug, you go to StackOverflow "which by the way, what does this even mean?" you say to yourself, you've successfully put your pieces together and it's working fine now. You're asking yourself: When will I have the confidence, to work, and get through a JS interview in a bigger company like a boss?

Covering these topics, even knowing for now that they're there, means you're in a good direction, not just for your daily job's sake, but for sexy interview questions that one may say the interviewers are using them just to show off.

1. Scopes:

A Scope is just the variables that you can access and use depending on where you're standing now in your code.
Your scopes are built on top of each other, like a stack of plates. When you start a JS file that's a scope, you may call it global scope, now you defined a function, this has a local scope, and a plate is added on top of the stack.

An instruction "ex: console.log()" that lives in the function's local scope "AKA on top of the stack" can access what's beneath it in the global scope, but if you defined a variable inside your function, you can only access it from the function's scope.

If you have a function inside a function, and you requested a variable's value, JS will first search in your current scope and if not there will move down in the stack one plate by another back to the global scope, if it didn't find your variable it will through "Uncaught ReferenceError: ... is not defined", that's what we call Scope Chain.

2. Hoisting:

JS works like magic, well, it doesn't, like any programming language, it has steps to do, a compiler that reads your code and turns it into machine code.

JS runs through phases, it creates a copy of all your variables declarations without values, gives it "undefined" for now, then there's an execution phase where variables are given values, that's why variables in JS are value typed, var could be a number, a string, an object, or any other type.

You can visualize hoisting as if each time you write: "var foo = 5;" you will have "var foo;" on the top of your page then you will assign it to 5 later, that's why you can write "console.log(foo);" before the line and it won't through "ReferenceError: foo is not defined". It will just say it's "undefined", which means it doesn't have a value yet.
Function declarations hoist to the top too, test it by running a function with a "()" before you declare it, it will work.

3. Var vs Let vs Const:

Now that we were introduced to Scopes and Hoisting concepts, we can go to one sexy JS interview question you can get asked, What's the difference between Var & Let & Const for a variable definition?
Let's break it first to var vs let & const:
var is the classic way, that was there from the beginning before let and const were introduced in ES2015 "AKA ES6", the updates that happen to our lovely JS each year.

So what's the difference? var does hoist, if you called a var variable before defining it, it will be undefined, while let & const will through the ReferenceError. That's one part, luckily we got through hoisting first!

Another difference is that var is function "or local" scope, a great example to show that is if you have a function and a for loop inside of it,
if you define your iterator "i" with "var i = 0;" in the for loop head, you will find that you can still get "i" as "undefined" if you called it outside the for loop.
let & const don't behave that way, they're block-scoped, means every curly bracket, including ones in for loops or conditionals like if/else, is a scope that you can't call these variables outside of it.

Now that we covered the differences between the two teams, why let vs const?
"let" lets you define a variable with a name first then assign a value to it later, even if with a value you can change it later, the thing that "const" prohibits you from doing.
It gives you the functionality of having a constant that can't be overwritten later, very handy if you forgot while coding a big file that you already named a variable with this name before, and spending your day asking why your variable has a different value.

I hope this was helpful for you, don't hesitate to reach me out for feedback or any question.

To be continued...