A subscriber was asked these interview questions for a junior role
Вставка
- Опубліковано 13 бер 2023
- 🤖 SaaS I'm Building: www.icongeneratorai.com/
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
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
🤣
LMAO how long ago was that interview approximately?
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.
Because it's the most complex time of web development. Separate html/css/js folders are replaced with a new crazy amount of stuff.
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
glad to hear that!
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.
for me React strict mode is very important, because it forces you, from the ground up, to handle the unmount of your component.
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.
Nice man, how'd you get your first job as a JS developer?
@@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.
Thank you i'm graduating college in the summer and doing 2 years of uni after, thanks for sharing
@@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?
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
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.
Dude you're so good at showing on how to do this question, thank you i hope you show more contents like this :D
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 🤣
Thank you for doing this. As a self learner, it's extremely difficult to assess where I am in my path. This helps telling me where I am in my journey.
I feel like I would struggle in an interview like this, I would normally know the answer, but have a blank mind when put on the spot lol
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)
When it comes to vanilla javascript questions I would say these are the most basic questions you would ask for a junior role.
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.
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.
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!
Great video, thanks for posting this!
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.
Design Patterns?
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.
@@Amy_A. that sounds interesting to solve for sure
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)
This video is really great information, thank you
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
I have to say, you complicated the heck out of those explanations.
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.
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.
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.
true, and i might add, as a complete amateur who could be counted on to fuck up a project, i know the answers to nearly all of those questions.
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.
Thank you so much for the video !
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 If by "variable" you mean "address", yes, I couldn't agree more.
@@anasouardini I don't. You don't deal with addresses in JavaScript, all of that is abstracted away.
They are variables, not addresses.
@@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.
Learnt quite a bit from this video, thank you
thanks buddy I got a solid recap of all things i've learned a while back
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.
Thanks for this, would be cool if you posted these question somewhere, maybe a github repo? great content
I think your channel is the best.
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?
@@WebDevCody yeah, the freeze example works but in my opinion the question was probably just about comparison between primitive types and objects.
@@huge_letters yeah could have been
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
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
As a lead/manager who has interviewed many a junior, I'd never expect a junior to know all of this. This list is more suited to a senior role.
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.
I can answer 95% of those questions. Cool. Ty Cody.
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
Great share. You got a good memory.
thanks mate, I've learned a lot
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.
I’m currently learning Python too, if you want to learn together, I guess could be easier, we can talk on discord
very helpful video, thank you
This actually helped me a lot in my final exam from javascript haha
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!
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.
Also the major advantage of immutability is fearless concurrency. If the data cannot change I am not worried about race conditions
@@igboman2860 hm, how do you reconcile the data then? Wouldnt you have create two splits?
"Some people don't really have imagination" - I laughed
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.
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 been working as a frontend dev for 4 years now and no-one ever asked me anything like this. Neither clients or employers.
probably more for junior devs, a Junior Dev will be coming from college and will have more textbook info like this at their disposal.
Why would your clients ask you about Javascript lmao
Makes sense they never did.
Most clients want an interview before setting up a contract.
@@braoha123 makes no sense for a client to ask you Anything about Javascript lmao
What world do you live in?
@@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.
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
When I use Redis, I use it as a database for caching queries & saving a shopping cart sessions.
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
I'm going to consume this content. I know how to answer just a few of these because I decided to start reading the documentation from the start.
26:22 closures are probably more easily understood as private variables from classes.
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.
Types of variables, that should refer to JS type system and data types (bool, number, string, undefined, etc).
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.
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
Thanks ♥️
"This will bind this so that when this is called this will refer to this.
Lol confusing isn’t it
Respect 📈📈
Awesome video!
I know some of these questions were silly, but how would scale these questions (in terms of difficulty) out of 10? just curious.
hard to say, maybe like 2-4? a lot of these questions are about things you'll need to know and will be covered in most javascript tutorials: promises, const vs let, async / await, the questions about classes and prototypes.
we need more react or node tricky interview task
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 also thought about the garbage collector
You're a god damn hero! (
Working as an Angular dev when you've said that 'I'd avoid using ".this"...' I died a little :D
Sometimes you got to work with what you got
When interviewers start asking chatGPT for questions to ask... this is what we end up with 😂
Const usage in relation with an array(or object) does not make it non-mutable it just makes the reference to the array non-mutable.
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.
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
Would be really cool if you check subscribers portfolios
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.
Nice good work!
How was the course?
@@dominicschwartz1917 extremely difficult and satisfying
@@rend1027 you find a job yet?
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.
Why don’t you just ask people to actually build something? There are people who can easily use these things but fail to explain them in detail
@@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'm pretty sure the "types of variables" was about numbers, strings, objects etc.
@@Batwam0 then it would be a poorly worded questions, because variables don't have types in JavaScript.
Then it should be called data types
Good job babe!
thank babe, I love you!
(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
First one for let, you cannot shadow (redefine) a variable with the same name but you can with var
nice one
fun fact you can still do .catch with async await.
The only reason I have trust in this man's webdev skills is that he seems to use semicolons about 50% of the time, this man has experience.
You got to keep the v8 engine on its toes
Had to subscribe off of this bad boi
Good video. Can you also use allsettled for promises?
all settled is for waiting for a collection of promises to settle. Kind of the same as finally I'd say.
@@WebDevCody ah that's right thanks
The company asked the applicant for a lot of knowledge. Regardless of whether he answered the questions correctly, they don't know if he can code...
Knowing what a logarithm is and using it to solve an equation or a problem are two different things.
Agreed. Asking definitions to things proofs very little
Please upload full stack mern with best practices
hey cody, can you post a video on type script error handling in different situations?
not sure what you mean, like what specific error handling are you talking about?
@@WebDevCody for example i get errors like object null or undefined and i dont know how to fix it. i try the reccomended things but it deosnot work
I think this was asked when I applied for accenture. lol.
I can confidently say, after going to a BootCamp for 6 month, and learning FrontEnd Development. I know maybe like 6 of these questions...
In this day and age Salesforce Marketing Cloud still uses ES3 runtime (no, I did not mistype it), when running ssjs code.
So knowing prototyping is kind of needed knowledge there, unless you write a whole dev toolset and compile TS code to es5 and write some polyfill for the remainder.
So I guess it depends on the job if you need that knowledge or not.
They like tech debt I guess?
@@WebDevCody Ohh, I think if you check the definition of that phrase, you will find their name next to it.
@@Ghingis00 😂 it happens
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.
this is 100% somebody's final LOL
❤❤❤❤❤
😂😂😂 the fact that I know and can use most of these concepts but I can't explain them is kind of scary
i subscribed
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.
you can modify an array that is a const
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)
I thought a closure would have been something like a if or else statement inside a function. You have data and closure is when you explain the circumstance after that data is known. Relevance.
I got asked to explain how JS event loop works for a junior role, which i know abit about but some of my mid level friends cant even answer it at all
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
Hey Cody, I don't know if you figure this out further down the video but the block scope vs function scope probably referes to something like this
{
var foo = "foo";
}
function main(){
var bar = "bar";
}
console.log(foo); // "foo"
console.log(bar); // bar is not defined here
var doesn't work with block scope, so I don't think the answer / reason can involve the var keyword. only let and const are applied to block scope