Wow. just wow. So many questions. When i had interview for junior role the q's were: Tell about react, why it's good, what's the problem with it? What's react native? Tell about node, js and docker. And that was it :D
Probably because of the role and responsibilities. You might have had a junior position where the team expected just assistance, here they might be looking for the guy to replace someone who was owning the responsibilities of a tool or just they want to filter out more folks.
I know right? As a beginner I really wonder how many of the interviewers didn't know the answers to all those questions when they were applying for their first junior roles themselves 😅
you explained the arrow function vs function part so well. i used to not really understand it that much (watched fireship) but you broke it down really nicely
I'll throw in another tidbit: Javascript is weird because in nested functions, the "this" keyword no longer refers to the outer function, but now the current function. Arrow functions are a native way from ES6 to where JS now knows the "this" keyword is referring to the outer function. Before ES6, some frameworks, for example Dojo, uses methods like "lang.hitch" which handled passing in the "this" keyword to sub-functions. Had a code review and devsecops team said we had to fix their linter warnings of "potential misuse of 'this' keyword" (or something like that). Even though the lang.hitch method was already covering that, the linter didn't recognize it and I had to swap it to arrow functions to remove the warnings.
As a complete beginner to JS 1.5 yrs ago, I'm happy to say I can answer most, if not all, of these questions. Went from a fresh college compsci grad to a confident full stack web dev in under 2 years. Still a LONG way to go, but I'm glad I feel a little bit less of the imposter syndrome we all suffer from.
@@invictuz4803 I do full stack including some dev ops. React JS with typescript (some jQuery on the older stuff) frontend, Java/Postgres backend, dockerized applications. No clue how many jobs I applied to before getting a job (it was a lot), but it took me 1.5-2 months to get one fresh out of school with a bachelor in compsci. Currently working as a govt contractor. So far it's been awesome but I might transfer to public sector in the next 3-5 years depending on how contracting pans out. I haven't had to deal with it personally, but from what I've heard from my leads, there's a lot of red tape and it sucks to deal with.
@@ibritoo No worries. If you have any further questions feel free to post here and I'll do my best to answer. If you comment and it's been a sec, post another one so it pops up in my notifications. Good luck to you.
About to be a newly grad here in December. Been having a ton of trouble getting any internships for the summer. Any tips you’d give yourself back when you were about to graduate?
I think this is quite wild for a junior interview! I've been working as a junior frontend dev (mostly Angular) in for almost a year now. Never had any of these kind of questions during the interviews (thank god for me, lol). I just showed some of my code (mainly React back then), explained why I liked coding so much, and had to do quite a simple code challenge. Furthermore just a very relaxed conversation and just seeing if I would be a good fit to the team and vice versa. Most of the subjects you'll learn on the job anyway (at a very fast rate, trust me). Of course, some basic understanding is good. But, in my opinion, knowing how to use the technology is more important than to be able to exactly explain how/what it does. Great video, good explanation. Great refresher for me :D
depends where you're interviewing. I can tell you that at my job, we ask fairly advanced language/domain questions in addition to the usual algo stuff even for interns (which are usually converted to juniors as we rarely recruit new grads)
Really enjoyed this and a great refresher for things we just take for granted. I feel like interviewers asking these questions more focused on the older stuff generally open themselves up further questioning about their code base, i.e. - are they asking me this because they have a lot of legacy code / will I be working on a lot of legacy code? I do wish that interviewers would ask more about patterns or even get your thoughts on problems. Usually ends up in a better engagement on both sides.
yeah, I wouldn't find much value in asking these specific questions, I rather ask someone to build something that might require a closure and not even say the keyword closure. If they can solve it and happen to use a closure, they know what a closure is and how to use it without understanding the definition of it, and that's good enough imo. Ask them to write a function and see if they put `var` everywhere or if they put const on things that don't change and let on things that don't change. No need to ask them to define this stuff, just watch them code for 5 minutes and you'll find out fast what they actually know.
I got asked the same question too. I felt like it was unfair question because in our bootcamp we were simply told to 'avoid class-based components like it's the plague' and that was it
This is a junior role for a top tech company, which isn’t really THAT junior. Kickstarters, financial companies, digital marketing agencies etc. will not go into this much detail. I’ve interviewed with all of those and got a job at each one without answering any of these questions and got accepted to all of them. To new newbies, do not stress the technical stuff, they know you’re new, just describe and convey the passion you have for coding and that will be good enough. Show excitement and ambition when you are talking about coding and they will love it.
yeah asking like react and mbox stuff for a junior role is quite a bit over the top (react is something you learn in a couple of weeks anyway) guess having a good knowledge of plain JS and other front end stuff like CSS and HTML is more important. Many things people do in javascript can be done with CSS / HTML only instead of overloaded JS files with dozens of event listeners.
If you don't know how to code in an interview, you can get really far just by writing psuedocode. Knowing the process is 80% of the battle, and simply being able to explain how you would do something goes a long way. (The other 20% is syntax, efficiency, readability etc.)
@@dillon1012 Yep totally agree. For the jobs I was interviewing for they were really looking to see my thought process and HOW I approach a problem that I don’t know how to deal with yet or haven’t seen. Basically they’re looking for adaptation and ability to improve, plus your excitement for coding. You’re spot on.
These are the most easy and basic questions and should be answered by anyone who has read at least one JS document/book. A serious company will make you do complex tasks for hours on end.
Tbh. I can answer most of the questions after a two weeks of studing React. Most of the questions are the basics. They havent even touched context or redux. Also, I know JS only from React but the questions about JS are very common for all the programming langauges basically. "This", mutability, references and scopes are universal concepts. Some of the questions are confusing tho but most of them are very easy especially if you took some time for prepare.
9:15 to put this section in more simple terms, classes are containers for methods(functions) and members(variables). Objects are instances of those classes. The class merely defines the object(s), while the object itself is what is used in the program. There can also be multiple objects (separate instances) of a class.
24:21 The easiest way to create a closure, at least in JS, is to literally start a closure with { and end it with }. You don't need a function to create a closure, functions just come with closures.
27:15 What you said completely encapsulates how I feel about tech interviews today. It's like, I know how to use the technology they are asking about, but I cant explain it perfectly. But often times (at least nowadays) I feel that if you can't communicate a near-perfect answer then it reflects extremely poorly on your skills as a developer in the interviewer's mind.
Yea its unfortunate that companies follow the trend of using recruiters who are only good at scouting personalities, rather than primarily focusing on their skills and only then to be supported by personality. We get it, you want someone pleasant to work and deal with, but that is also how you miss out on these hard working and talented people who are more focused on their craft rather than too much socialising. The ideal way would add someone who really know the tech to interview alongside the recruiter, but that would be too idealistic too if the company is still a green one or lacking in staff. Oh how complicated life is!
Just a little note (I might be wrong in some details): Immutability IN JS is that you cannot change the data in the same region of memory. i.e same label, the name of a variable and same address but different data. When you change a the value of a primative, as they call it in JS, you're not "changing"/"mutating" data in the same memory; you're allocating/creating a new memory space with a new address and then pointing the label's reference to a new memory. So, all primative, whether you use let or const, are immutable in JS.
it's all nomenclature. it's technically called a constant if the variable can never change it's reference or value, but that's also considered an immutable variable. but in regards to the question they probably wanted to hear why react choose immutable state
let a = 5; a is a mutable variable, which contains an immutable value. We need to be careful about whether we are talking about the mutability of the variable, or the value here, since those can differ. Similarly: const b = {}; Now we have an immutable variable with a mutable value. You cannot do `b = 5`, but you absolutely can do `b.asd = 5`
@@Yotanido Well, as Cody said "it's all nomenclature", this whole talk is mostly about the theory; I don't know why you would not use "lower-level" words. And, to be honest, I don't even know what "variable" means in your context. To me, variable is just a label for an address, so if you don't mean the address you might refer to the label, in which case you're wrong because the label is still called "a".
9:00 - the difference between a class and a object is: a class defines the data and methods belonging to the data within a single encapsulation construct, an object is a specific instance.
Great video, Lately I have the feeling that in interviews there are many questions related to things that in the end will not even be implemented, I understand that there are filters but there are things that seem more like trick questions than really something that helps to find the right one candidate, many of those filters even fire good developers for even somewhat absurd things
yeah some of these questions seem silly to ask, just ask them to design a rest API and if they can do it, they probably understand how http and restful apis work, how request methods work, etc.
I had a really great interview question the other day. "Given a delimited string of numbers, output a HTML table." The catch was that it was grouped by column, with each pair of 2 numbers being the row and value at that row (in the grouped column). This wasn't it exactly, but as an example, "1,2,5,3/C1*1,5,5,2/C2", which would translate to {"1": {"1": "2", "2", "5"}, "5": {"1": "3", "2": "2"}} in json (accessed like data[row][col]). It's great because it's a collection of things that you would normally be asked to do over the course of a job, but not usually all at once, and not usually in that format. It was really fun to solve, and even though I didn't get the job I honestly feel like I'm a better programmer for having worked my way through that.
best way to describe this: this is an object reference built into every class that references the currently instantiated object. For example, if you declare two instances of class cat, namely cat1 and cat2, the "this" keyword will reference the object itself. There will be 2 "this" defined here, one for cat1 and one for cat2. This allows you to differentiate which object you're talking about if you just so happen to be working with variables from the same object.
IMHO, the best way to talk about "this" is that every time run a non-arrow function, in addition to its arguments, there are a couple of "hidden" variables that will be available within the function's body: "this" and "arguments". When you call a function as a method to an object, the value of "this" will be set to the object automatically, but this behaviour can be overriden by using either of the following methods of the Function object: bind, call and apply. All of these methods let you explicitly set the value of "this" to whatever the hell you want it to be.
21:31 - reassigning a let variable is not an example of mutability because you're not changing the value itself, you're changing what the variable is pointing to. Unlike with objects where the variable points to the same object but the properties of the object do get changed.
yeah, that's probably a more accurate description, but a constant is a form of immutable variables. If you go to the wiki on "immutable object" you'll see a section on immutable variables. The interview question was asking about what types of variables are mutable vs immutable. but yes, a better description of immutable objects is my freeze example I talk about directly after that part right?
Man, I hate companies that evaluates possible employees like that... Are they contracting to be a teacher or something? Because if not, most of all that knowledge is unnecessary to make things happens. You don't need to be able to explain to have a overall grasp and be capable of using or doing something, plus questiones like "Explain getPrototypeOf/setPrototoypeOf" that's literally something no ones uses or recommend using seriously.
Agreed our industry needs training for interview processes. I think many interviewers fail to understand what is important or not so they just use a preset collection of questions to judge future employees. I work with many highly skilled individuals who would struggle giving a solid definition of a closure, but they can successfully ship well tested features to prod weekly.
I kinda disagree disagree. If you can't articulate how something works, you don't understand it. Even if that isn't true, it's a good skill to have as you'll need to explain why something should be written one way versus another.
I think this is a really misunderstood take. I get that your point is you don't need to have EVERYTHING memorized but you need to make sure you understand most of these questions. You can't look up how to do something on stack overflow and waste an hour of time or ask a fellow employee to do it as you were assigned a specific task. I have been programming since elementary school and just got to college and realized the only reason I have gotten so much attention as a freshman is because my level of "understanding" is higher than that of my peers. You aren't just trying to get a job, you're trying to beat everyone else to it. They expect you to be prepared for any situation, including not knowing how something works (in which case they are usually asking hyper specific questions so you take the time to go "I don't know the answer, what is it?" Instead of "I don't know the answer"). Everyone underestimates the hiring process but it is extremely refined. I learned this at TRUIST. It is important they vet out the worst and only get the best.
@@LM-cc7qz If you really wanted to know someone is whether or not capable of doing something, you wouldn't make a question about how does X thing work, you'll just see their projects or give them a test to ascertain such thing. It still unlogical to make such questions, *specially* about things no one uses nor ad recommended to be used like getPrototypeOf/setPrototypeOf. Even *professionals* who knows what is doing eventually forget the nitty gritties of how things they do work. That's enough reason to consider asking a Jr in the area for specific answers for everything dumb.
I think something also important to note about the difference between resolving promises with then vs async/await is javascript executes in a more synchronous way when you await. It will not execute the next line until the promise resolves. While then chaining will execute in the background, more asynchronously, and the rest of the function or block will execute.
Hard agree with this. It's much easier to handle concurrent requests using raw promises and promise.all/promise.race. In fact, I'm not sure how I'd go about making multiple fetch requests without waterfalling components and slowing down app performance.
I won't say much, because I've been writing a response for over 30 minutes, but I wouldn't consider async/await as a separate thing from Promise. (why are we even putting async/ in front? Promise is also async but we don't say async/Promise) async/await is more of an enhancement rather than a replacement, it uses the same exact system as Promise, but in a syntactical way When chaining multiple async functions, using .then is more clear and easy to write, and ontop of that you can even await the entire chain of .then Since .then returns a Promise ;(await (await fetch("")).json())["item"] *vs* await fetch("").then(r => r.json()).then(r => r["item"]) tell me, which do you prefer? Dunno about you, but having to write "await" a bunch of times on the same line is not pleasant, it also means that I have to nest each promise in parenthesis And it also means that I might have to insert a semi-colon at the start of the line, because of the parenthesis and JS assuming it is a function call to the previous line. Anyways, I don't know, I feel like you are comparing apples to oranges, but in reality you are comparing apples to green apples. PS: Which type of apple do you prefer? Personally I prefer green apples since they are more tasteful; not necessarily tasty :^)
@@arjix8738 I get what you're trying to say but there are real differences. Await pauses execution until that promise resolves while .then continues execution. For example consider the following two blocks useEffect(async () => { const sidebar = await fetch('/get-sidebar'); const issue = await fetch('/get-issue'); const comments = await fetch('/get-comments'); }, []) useEffect(async () => { const [sidebar, issue, comments] = await Promise.all([ fetch('/get-sidebar'), fetch('/get-issue'), fetch('/get-comments') ]) }, []) In the first example each fetch requests needs to wait for the previous one to respond before the next is fired off. In the second block each promise is fired "in parallel" and all resolve to a single promise so it's far more performant.
@@twothreeoneoneseventwoonefour5 I work as a consultant in Sweden and most of my clients are companies with existing dev-teams, so usually we set up an interview where I talk to product owners and devs. They usually want to talk about past experience, which includes frameworks and general tech discussions. Pretty much the exact same that I have with employers.
Also arrow funtions are basicly lambda/anonimous functions. So thats why their context is autobinded to parent context, thats why you have no separate scope on them
I've started JavaScript now more than a week ago and I can answer most of the questions except for those react ones and some of the last ones which I didn't get to yet Update: after 5 months of learning how to code I learned HTML and CSS to a level I can build simple websites, learned JavaScript to a level I could answer all the general JS questions from this video confidently, and now I started to learn React as my Front-End framework. Really happy with my progress and after I get a good understanding of React I will try my luck applying for jobs
I'm learning so much! I always thought the arrow function is calling the constructor of the class and pointing to what you want to reference in the class. Lol.
New to the channel, I use JS/TS for work on a daily basis but I have to say watching this video was nice I really wish I had vids with such easy to understand explanations and clarity very good clarity. Love when people teaching a content explains why it works and not just shoves the answer straight to you the thing I hate the most is when fellow programmers cant explain something they show me I understand sometimes things just work and that's nice but its nice to understand the reason it works.
Great video, starting to apply for my first job in the field soon and felt generally able to answer most of these questions which is promising hopefully 🤣
Back in my day (2014), entry level college-grad interview: "Hey, so, we're getting a new office building. You cool with that? Also, describe your ideal workday. Also how much water can you fill into a room? How many tennis balls?" My second job wasn't that simple.
Great video. I would say prototype is still important because underneath JS is still a prototypal language and classes are just sugar. Prototypal inheritance allows things that aren't generally allowed in typical OO languages. For instance, extending things in a much more generic way, as well as composing objects in a much more generic way. It is hard for most devs to understand who come from OOP. And when debugging vanillajs in the sources tab or console, knowing how the prototypal chain works is still useful.
Yeah if you are on a project that used a lot of OoP in JavaScript, prototype is important for sure. I think a lot of apps can get away with not writing a single class keyword, so it depends on the project and team
Hey Cody, great video as always. Do you think you could do a video on general security for sites/forms? For example, how to build apps that handle sensitive data securely (is passing data over HTTPS in headers/body and TLS good enough?, what does it look like in production, etc.)
I think https is secure enough, and maybe use a post. You don’t want any sensitive data in a query string that someone might accidentally bookmark. Also never log the data on your backend logs if it’s super sensitive, that just provides another attack vector to leak that info. Reduce who has access to the machines that might receive those api requests to reduce internal attack vectors. Encryption at rest on the db to reduce the chance of someone taking the physical hard disk and reading your data (probably rare to occur but might be required based on country laws and what you are storing)
A short and easy definition of closure is essentialy the capability of an inner function to access a variable declared in an outer function scope even after its execution has finished.
The reason they're asking about prototypes and things such as var could be that they have a lot of legacy code so they need someone that understands how older features of the language work
Great video. As a somewhat experienced dev, I'd make two changes: 1. I would _not_ avoid using `this`, as it's far too ubiquitous in the modern JS ecosystem (especially in OOP). The best explanation I can give, to echo you, is that `this` refers basically to whatever calls the method/function or whatever the method/function "lives" on, unless otherwise explicitly modified (e.g., something funky like `.bind()`) 2. I think it's incredibly important to point out that while asking maybe 1/3 to 1/2 of these questions would be okay, asking all of these would be too much (and would be a red flag for any interviewee that the company doing the interview does not have their act together to ask decent questions). I also _really_ don't like the "explain everything about " style questions, as they're basically free reign for the interviewer to go "Hah, but you missed A, B, and C!". Knowledge-check style questions, IMHO, should not be as blatantly open-ended.
using promise can be superior, since async blocks the containing function. eg. if you have a function that needs to fetches from multiple sources and then do something, you could do them with await, but it'd be literally be doing them one at a time... instead if you take the promises and use a Promise.all promise, the fetches can happen asynchronously instead - this can significantly affect load times of apps!
Currently learning Python at the moment but it's good to see the kind of questions people get in interviews. Especially coming from someone outside of the industry.
Regarding prototype. What it you don't have the class definition. Prototype is meant to deal with the problem of adding custom methods to already defined classes. It's not really a matter of old syntax or preference but rather a really useful feature that gives JS class definitions the ability to be extended
I guess the block scoped questions aims to the call stack and garbage collection. After the call stack of any function is finished the variables are unreachable and will be collected by the garbage collection. Or maybe they just wanted to hear about the chained scope of javascript...
I’m pretty sure it was answered, but arrow functions are an IIFE (immediately invoked function expression) so any reference to *this* is lexically scoped. So it’ll move up the prototype chain until it finds a reference to this (i know you mentioned prototypes are kinda useless, but they make debugging and resolving *this* contexts basically nontrivial). The reason why it fails when you use a regular function is that regular functions are hoisted globally, meaning its context is also global.
the way I look at Arrow functions is that like, unlike normal functions, they have access to the context outside of their own scope. That's why you can use "this" referencing something in the class in that case
I've used a wide array of languages in my career thus far. I'm familiar with all of these concepts, but if asked in an interview setting, probably could not define some of them specifically.
I am in my 4th week of boot camp and its amazing that i actually know the answer to some of these questions. This is coming from someone who has never wrote a single code in their life.
This kind of interview questions are common here at the Philippines when you apply for Junior Position, sometimes they'll be asking you to code complex problems
an important aspect of arrow functions is that their parameter lists are effectively fixed because there is no arguments "context variable". Arrow functions don't support/override the "context variables": this, super and arguments. this is also useful in the reverse - since sometimes we don't want to replace the context variables
4:35 Hoisting also allows for mutual recursion, I believe. Imagine putting call to `hello` inside `b`, and you have a recursion loop. Without hoisting, it wouldn't be possible to make it
I am a frontend architect who interviews on a weekly basis and I can confirm that I use most of those questions during my interviews. I have phased out questions about prototypes, but everything else is valid. I would also add to this list, questions related to functional Arrays methods (map, reduce, etc), modern syntax like destructuring, spread operator and ES modules.
@@WebDevCody I use various methods, including programming excercises (take home or pair programming). Unfortunately there's no straightforward answer on which one is best. Some people do better in the interview part, others in the programming. In addition to that, the region in which we are hiring makes a difference as well. I interview mainly for Europe and Asia and the difference in skill levels between the two is significant. Finally it depends on the individual skill level. I will assess a junior or graduate a lot more lenient and give them a lot more opportunities and hints than a mid-level or senior developer. Because at the end of the day, a junior is an investment. I will be investing time and money into teaching them how to do the job, so I need to make sure that they have the correct mindset. A programming exercise is not enough to judge that in my opinion, you need a combination of things to get a better picture
@@WebDevCody I would like to add that I have hired juniors who could barely answer any of those questions correctly or completely, because of how they reacted to my feedback. They were eager to learn, they were open to criticism and they showed me that they are passionate about this field. That's someone I can work with!
Sounds like HR bullshit. You're not hiring people to be interviewed, you're hiring them to do a job, which is programming. Why would it matter if they are bad at the interview? Just give them a real/mock problem to solve and assess the solution.
@dogoku It seems lime that you are a horseshit. You are asking questions when in reality you can't even explain it properly too, just ask them to make a working code with that functions instead of explaining it. We are not the creators of that functions!
I believe immutability can save your some memory when altering larger data structures such as a tree. You only have to change the parts of the tree - up to the root - that changed and have those reference to the subtrees that didnt change yet. Also, you could create a primitive undo/redo feature with this, by keeping track of previous root nodes and just use those again if the user wants to undo.
(I haven't watched the video, only read the questions) Though i can answer pretty much all of those questions right away, i can say that there are some intermediate questions. For example, i myself had no clue what the difference was between a function and an arrow function. I would only say it's syntatical sugar, but apparently, there is more to it. I have over 6 years of hobbyist experience, but it's definitely enough for a junior position lol
After almost 10 years of practical experience with Javascript I still can not properly explain some of those concepts if asked during an interview (hoisting, closures, prototype inheritance...). Not because I don't understand them, but because I either use them without realizing it or they are being used behind the scenes now (ES6 classes). So don't feel bad if you can't answer some of those questions as a junior developer.
Types of variables are not let const and var those a just keyword to declare variables. The types are : Number String Boolean BigInt Object Symbol Null Undefined (I don't think I forget one ?😅)
This is why I took a 180 degree turn and walked away from the tech industry while I still could 😂 (if I understood radians maybe I'd be able to keep up)
23:11 gotta admit about that "immutability" dogma. It's a non-issue, because you end up having to reassign things anyway. You're still changing stuff eventually somewhere. Saying you don't know where it gets changed just means you've made it way too obscure or you just don't understand the codebase to begin with.
yea the biggest issues i've seen with mutable references is when you pass entire objects around in your code base to functions that don't need them, and then those functions modify the objects somewhere which makes things a bit confusing at times.
i think these questions are not that good. better to let them write something and show the thought process. I dont want to work for a company that asks me about what types of variables there are in JS.. I would just think that they know nothing :D "This company is making the software for travel to Mars, pacemakers and controling nuclear powerplants. Do you know what types of variables there are in JS?.... "
While these questions do make sense in some way, it would still be better learnt on the job rather than some "half-baked answers" during an interview. I think the interviewer failed to understand the concept of recruiting a junior. The questions to ask is what language they worked on, whether they had some reference projects they worked on so one could take a look, if not, propose simple typical development scenarios and have the interviewee go through, while helping them if stuck (as you should be expecting them to be stuck since they are applying for a junior position). What one is looking for in a junior dev is a critical thinker, a team person and ability to persevere or at least provide a good approach/solution to the coding questions. For example, many people can memorize the difference between heap and stack, but 60% probably don't even understand what that actually means unless they work on an issue involving those.
I couldn’t even correctly describe the event loop in javascript. You just don’t end up caring about the lower level details of it. Don’t write long running blocking code and you’ll be ok
CONST is constant and cannot be re-assigned its value. LET will let you re-assign the value. Both const and let are local scoped. VAR is global scoped and will also let you re-assign the value but is rarely used.
I am in it about 15 yrs now. Some of these questions I am not even able to answer, though I could google it and understand in less than a minute. Now does that mean I am a bad developer? Hell no, I worked with many startups and enterprise companies, and had no issues to be in the top performance developers. If a developer knows all the answers, does that mean he is really good at it? Hell no. I worked with so many bragger developers, who knows answer to every single question you drop on them. They mostly (in most cases), performed really bad. So in general, there is no rule of a good developer, regardless if we are talking about junior, medior od senior. Eventually what really matters is did you do the job right or not. Nobody care (unless you work in university), if you know definitions of some thing. MHO
Another youtube programmer who explains hoisting completely wrong. JS engine doesn't rearrange your code, it doesn't move variables and functions to the top of the file. During creation phase of execution context JS engine goes through the code and stores variables into memory and sets them to undefined, and stores body of the functions to the memory. And that's why you can access those (in case of "var" variables) before their line in code during execution phase. Const and Let variables get hoisted as well, but JS engine forbids accesing them sooner than you actualy defined them in your code.
Yeah I'm pretty sure that classes what's the difference between classes and objects question is kind of a gacha because in JavaScript everything is objects if you make a class it's an object