Please note TS only provides IDE level type safety. There is no compile time or runtime type safety. Meaning? Type checking errors will only occur if you are using an iDE that has linting or has basic type checks. Since TS still allows dynamic variables it has lots of type unsafe stuff allowed. When it is transplied into JS, even static type checks are gone and Runtime type checking also doesn't exist.
Literally perfect timing man. I’m waiting to hear back if from my first interview and I’ll be assigned to pair program with a dev at the company. I’m quite knowledgeable but there are areas where I could brush up on. Thanks so much!
So nearly 50% of these are for if you’re interviewing for a react job. It’s likely you are, but it’s so important that you understand larger JavaScript concepts. There is one question about scope in this list, and it’s something juniors trip up on constantly. If you can tell me what a react hook is, but you don’t know what hoisting means, or the difference between const and let, then something went sideways at some point.
How I see it is, try explain why looping 0,1,2 is my preference bad practice doing in js. Because we would've prefer to have something more [0,1,2] for a loop. Using var would give 333 and let gives 012 when looped i>3.. Now react we use useState, for reposnive data n design. So instead of having the computer loop 1, 2, 3. We have set it n it loops that sequence. This is all important , especially with creating typewriter effects and how bugs can occur. Why bugs can occur etc
Actually, console.log DEFINITELY counts as a side effect, RE pure functions. So does printing to the screen, or saving to a file. This is slightly different than how you are still allowed to print in a Java function declared as "void", because that ONLY applies to (not) returning data, rather than to all mutation.
I think this is a pretty good list based on my extensive experience in Javascript. The video gave me a few ideas of things to look into for my next interview. Thank you for putting this together.
Console logging can be considered a side effect in specific situations; one of which is if you use stdin/stdout to pass values into buffers of different subprocesses. An unexpected console log can mess this up
Thanks for making that video! I always assumed I would BOMB tech interviews and thought I'd struggle through this video. But I watched all of it, paused right after seeing the question and did my explanation. I think I nailed 9 out of 10 questions - the first one (closures) being the one I am not capable of explaining fluently. I know what closures are, but have a hard time explaining why they're important and useful. Everything else I feel like I could talk confidently about, and wouldn't be worried about digging a bit deeper if necessary. Closure, I felt like I was bullsh#tting my way through the explanation lol
Love this! It's interesting how we can understand how things work but struggle to explain them sometimes. Thanks for watching and sharing your thoughts!
The issue I see most with people understanding promises is what actually happens during the “async” part. Most inexperienced developers don’t understand the event loop, which causes problems especially in unit testing and mocking.
I never liked the Closures or Function Composition questions. Everything else for the most part seem more relevant to modern development. I suppose the first questions are more for core/library development.
Thanx for the cool video. I was maybe missing the new features we got in the modern ECMA-Script world, object oriented programming in JavaScript, classes vs. prototypes, maybe deeper functional things like currying and stuff. I personally do not like those kind of questions. I like a more pragmatic approach.
My answers for the JS Interview: 1. What is a closure ? Unsafe and Unreliable scope 3. Composition, isnt that just nesting ? 5. Whats a promise ? Its own thread. 6. What is typescript ? a LSP linter and transpiler. 8,9 What is a React ? Its a JS library. 10. TDD ? Wasted effort not getting things done. Testing Prod ready code is diffrent story. Please let me know if those answers feel right.
3. No, it means returning functions from other functions, using closures to change the resulting function. Think of it like the opposite of inheritance: instead of “bird” inheriting from “flying animal”, you would pass the “bird” function to the “makeFlyingAnimal” function that would return a flying bird. This way, it’s easier to create for example a phoenix, because you could just pass your bird to a “resistFire” and a “reviveForever” function.
@@UliTroyoI apreciate your help but ... after a little research my statement holds truth. It is function nesting, nothing more. And I consider it bad practice since you have to rewrite the code, in order, every time one step goes wrong. Not for me. Id rather do each function in its own line.
React should not even be on a top 10 of JS, due to it's very nature kind of does most of the heavy lifting for Devs. If you know the company uses a framework/library like React then learn it and it should have it's own top 10. Things that are more important and have seen newer Devs to JS in general fail on. - Primitives, Objects and Arrays - you will get some of this I think from number 4 (do not remember which number) - Testing as a whole - meaning explain the type of testing you like and if the company does something else you could pick it up - Big O(n) and why you might use for, forEach, map, set, etc... Minor most of the time (in actual coding) but when it matters it matters. Loved for interview questions though
If we rarely encounter these types of questions in day-to-day coding, why are they so common in interviews? It feels like they’re designed to make life harder rather than genuinely evaluating practical skills. 😭
To be honest, quite weak list of items. I’d add for JS: - context/scope in js; - concept of prototypes/classes; - callbacks vs async/await vs generators+iterators - loops: while/for vs prototype-based(to implement own reduce/filter/map) - closures: 1. function recurring - as another way to do loops 2. Module pattern 3. HOF/HOC - data structures in JS - Map/Set/Array/Object and custom such Tuple etc - of course XHR For React: - premature optimization - knowing when and how to use and more importantly when not to use: useCallback, useMemo, memo; - to understand React.FC life cycle(in comparison to React.Component class) - react context Whole bunch for TS: - type vs interface; why better not use interfaces😂 - generics + infer + extend + never - why not to use enums 😂 List is not complete but I believe it covers more important topics than the list in the video and it is more close to real world interview 😏
I just rejected a project because they don't use Typescript. I can't understand why the hell you would use JS in production in 2024, especially working in team. It's just a lot of pain.
Yeah they do!! I was interested in how to call functions without brackets!! And another thing I learned is they don’t ask very _real_ questions that would apply to real life!!
var is in global scope so every time the settimeout function is called the var i get updated, lastly when i = 4 then loop condition is false and delay is there for settimeout, after the timer ends one by one values will print i.e. i= 4 let is in block scope, which is not under window object or global scope, so every time let i is coming in loop serate memory is created for let i, so in the separate memory i will have the values 1, 2, 3 and when the condition is false and timer also ends then this value will get printed i.e 1 2 3 to understand this thing more visually you can write a script with HTML and this code then go to inspect then source there you can see your code and put a debugger there, then you can understand the code efficiently. you can use var to get the result 1 2 3, for that you need to use closure, you can check this code below. I have done it with closure and used var. function x () { for(var i=1; i{ console.log(i) // 1 2 3 }, 1200) } y(i) } } x()
TypeScript does NOT help you, unless you're a bad programmer. The whole point of strong typing is that dim bulbs get confused with loose typing and write bugs they can't later find.
Funny how you said that you don't do function composition or use it often when that's literally all you do with react. Interesting that people don't even know that.
Yeah, it’s unintuitive for people, but everyone who uses anything in the JS ecosystem uses it all the time. I think it’s fine; knowing the details helps, but people get adequate intuition just from using things. Kind of like music theory.
This is the problem with a language that relies too much on 3rd party libraries + frameworks to do things that should probably be built into the language. JS isn't even a real OOP language. Maybe it is nowadays, I'm not sure but when I started learning years ago, it was called "Object Based" rather than "Object Oriented". I guess TS makes it feel like OOP though. My point is that it is difficult for most devs to get below the surface of the layers and layers of libraries and frameworks so I think it is understandable if they don't know they are using something like "composition" in some project already.
I've never, and will never consider JS to be a functional language. If you want functional, go with Haskell, Erlang, or Elixir. It has functional components to it as mentioned, but using JS in a pure functional way is restricting yourself from leveraging the full power of the language.
The questions related to functional programming concepts need a deep dive slash correction. I'm gonna assume that you know the principal ideas, but you seem a little lost in the vid. Calling JS a functional language, confusing deterministic and pure, calling logging *not* a side effect and a closure a nested function would have you lose the interview big time with serious corporations. And you really have to know your TDD, or you ain't get hired (even if companies don't use it to the letter). These questions are meant for you to fall in the trap of subtleties between the functional world and the imperative world, and you fell for the trap with eyes wide open. If you want, you can contact me, and I'll help you get the facts straight in a follow-up video.
@@TokyoXtreme More like the illusion that they're hiring those that can. 10 years in the industry and every dev that's made an impression on me did so based on foundational knowledge. But I guess that article was probably directed towards juniors that are just task rabbits.
What a shitty list. All of the "functional" stuff has nothing to do with javascript, and makes numeruous unfounded assertions about the superiority of functional programming. (This is a fad by the way, later we'll here about how obect oriented is actually better).
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
Please note TS only provides IDE level type safety. There is no compile time or runtime type safety.
Meaning? Type checking errors will only occur if you are using an iDE that has linting or has basic type checks. Since TS still allows dynamic variables it has lots of type unsafe stuff allowed. When it is transplied into JS, even static type checks are gone and Runtime type checking also doesn't exist.
Literally perfect timing man. I’m waiting to hear back if from my first interview and I’ll be assigned to pair program with a dev at the company. I’m quite knowledgeable but there are areas where I could brush up on. Thanks so much!
Yeahhh! So glad to hear that!
So nearly 50% of these are for if you’re interviewing for a react job. It’s likely you are, but it’s so important that you understand larger JavaScript concepts. There is one question about scope in this list, and it’s something juniors trip up on constantly. If you can tell me what a react hook is, but you don’t know what hoisting means, or the difference between const and let, then something went sideways at some point.
Spot on,
How I see it is, try explain why looping 0,1,2 is my preference bad practice doing in js. Because we would've prefer to have something more [0,1,2] for a loop. Using var would give 333 and let gives 012 when looped i>3.. Now react we use useState, for reposnive data n design. So instead of having the computer loop 1, 2, 3. We have set it n it loops that sequence. This is all important , especially with creating typewriter effects and how bugs can occur. Why bugs can occur etc
I say var n let, because we have to learn how js reads code, line by line, or asynchronous
James is an AI machine 😂 dude hit a infinite loop glitch the last 10 seconds 😂😂😂
Actually, console.log DEFINITELY counts as a side effect, RE pure functions.
So does printing to the screen, or saving to a file.
This is slightly different than how you are still allowed to print in a Java function declared as "void", because that ONLY applies to (not) returning data, rather than to all mutation.
Thanks for the review! A pure function should not write to a file, because the file could indirectly affect state and therefore affect the result.
Yeah if it's being read by another. True. Good point.
Hey James, where can I follow along for updates?
Wow, I guess I know a lot more about JS than I thought. I still have a ways to go but this is pretty encouraging.
I think this is a pretty good list based on my extensive experience in Javascript. The video gave me a few ideas of things to look into for my next interview. Thank you for putting this together.
Console logging can be considered a side effect in specific situations; one of which is if you use stdin/stdout to pass values into buffers of different subprocesses. An unexpected console log can mess this up
Also if you use next.js server components then using a console log can cause the side effect of slowing your whole site down 😅
bahaha this is great!!
Thanks for making that video! I always assumed I would BOMB tech interviews and thought I'd struggle through this video. But I watched all of it, paused right after seeing the question and did my explanation. I think I nailed 9 out of 10 questions - the first one (closures) being the one I am not capable of explaining fluently. I know what closures are, but have a hard time explaining why they're important and useful. Everything else I feel like I could talk confidently about, and wouldn't be worried about digging a bit deeper if necessary. Closure, I felt like I was bullsh#tting my way through the explanation lol
Love this! It's interesting how we can understand how things work but struggle to explain them sometimes. Thanks for watching and sharing your thoughts!
The issue I see most with people understanding promises is what actually happens during the “async” part. Most inexperienced developers don’t understand the event loop, which causes problems especially in unit testing and mocking.
Lol, there's a mess-up with the audio at the end
It's the brainwashing technique to give you no choice but "check that out on James Q Quick updates" 😅
Trippin me out maaaaan 😆
Yooo I have no idea what happened there lol
I knew them all!! I'm 3.4yrs into teaching myself. I'm currently hoping between JS, TS, GO & Rust... mainly JS/Rust atm.
Yeahhh! Love to hear it!
I never liked the Closures or Function Composition questions. Everything else for the most part seem more relevant to modern development. I suppose the first questions are more for core/library development.
That rap sequence at the end 😂🔥🔥
I don't know what the heck happened there lol
Confirmed he's a cyborg.
Thanx for the cool video. I was maybe missing the new features we got in the modern ECMA-Script world, object oriented programming in JavaScript, classes vs. prototypes, maybe deeper functional things like currying and stuff. I personally do not like those kind of questions. I like a more pragmatic approach.
thank you so much for these questions.
My answers for the JS Interview:
1. What is a closure ? Unsafe and Unreliable scope
3. Composition, isnt that just nesting ?
5. Whats a promise ? Its own thread.
6. What is typescript ? a LSP linter and transpiler.
8,9 What is a React ? Its a JS library.
10. TDD ? Wasted effort not getting things done. Testing Prod ready code is diffrent story.
Please let me know if those answers feel right.
3. No, it means returning functions from other functions, using closures to change the resulting function. Think of it like the opposite of inheritance: instead of “bird” inheriting from “flying animal”, you would pass the “bird” function to the “makeFlyingAnimal” function that would return a flying bird. This way, it’s easier to create for example a phoenix, because you could just pass your bird to a “resistFire” and a “reviveForever” function.
@@UliTroyoI apreciate your help but ... after a little research my statement holds truth. It is function nesting, nothing more. And I consider it bad practice since you have to rewrite the code, in order, every time one step goes wrong. Not for me. Id rather do each function in its own line.
That’s not what a promise is, async doesn’t mean multi-threaded
@@cotyhamiltontrue, but what would be the diffrence then ?
JS is single threaded.
Wow James what are the odds with me having a 2 hour coding challenge coming up and you make this video. Thanks
Pretty high that someone would :)
I do small projects never feel like need to use Typescript...
React should not even be on a top 10 of JS, due to it's very nature kind of does most of the heavy lifting for Devs. If you know the company uses a framework/library like React then learn it and it should have it's own top 10.
Things that are more important and have seen newer Devs to JS in general fail on.
- Primitives, Objects and Arrays - you will get some of this I think from number 4 (do not remember which number)
- Testing as a whole - meaning explain the type of testing you like and if the company does something else you could pick it up
- Big O(n) and why you might use for, forEach, map, set, etc... Minor most of the time (in actual coding) but when it matters it matters. Loved for interview questions though
If we rarely encounter these types of questions in day-to-day coding, why are they so common in interviews? It feels like they’re designed to make life harder rather than genuinely evaluating practical skills. 😭
To be honest, quite weak list of items.
I’d add for JS:
- context/scope in js;
- concept of prototypes/classes;
- callbacks vs async/await vs generators+iterators
- loops: while/for vs prototype-based(to implement own reduce/filter/map)
- closures:
1. function recurring - as another way to do loops
2. Module pattern
3. HOF/HOC
- data structures in JS - Map/Set/Array/Object and custom such Tuple etc
- of course XHR
For React:
- premature optimization - knowing when and how to use and more importantly when not to use: useCallback, useMemo, memo;
- to understand React.FC life cycle(in comparison to React.Component class)
- react context
Whole bunch for TS:
- type vs interface; why better not use interfaces😂
- generics + infer + extend + never
- why not to use enums 😂
List is not complete but I believe it covers more important topics than the list in the video and it is more close to real world interview 😏
I just rejected a project because they don't use Typescript. I can't understand why the hell you would use JS in production in 2024, especially working in team. It's just a lot of pain.
With all the transpilers out there, coding directly in JS is just a risk.
This was so helpful! More please!
the most important thing is to make sure you have fun
learned a lot! thanks for the video!
These chapters are marked wrong.
What is the output of a URL on a browser for SPA vs MPA
3:54 that was first thing what triggered in my mind after hearing the word "side effect".
Typescript is a linter for Javascript
Been looking for a video like this for a while!! And the answer is I would not
What do you think about these questions? Good fit?
Yeah they do!! I was interested in how to call functions without brackets!! And another thing I learned is they don’t ask very _real_ questions that would apply to real life!!
for(var i = 1; i {
console.log(i);
}, 1200);
}
Output is
4
4
4
&
for(let i = 1; i {
console.log(i);
}, 1200);
}
Output is
1
2
3
Why??
var is in global scope so every time the settimeout function is called the var i get updated, lastly when i = 4 then loop condition is false and delay is there for settimeout, after the timer ends one by one values will print i.e. i= 4
let is in block scope, which is not under window object or global scope, so every time let i is coming in loop serate memory is created for let i, so in the separate memory i will have the values 1, 2, 3 and when the condition is false and timer also ends then this value will get printed i.e 1 2 3
to understand this thing more visually you can write a script with HTML and this code
then go to inspect then source there you can see your code and put a debugger there, then you can understand the code efficiently.
you can use var to get the result 1 2 3, for that you need to use closure, you can check this code below. I have done it with closure and used var.
function x () {
for(var i=1; i{
console.log(i) // 1 2 3
}, 1200)
}
y(i)
}
}
x()
me writing tests after i've made the implementation with different test values :))
I just realised that I failed my JS interview
Thanks
What are the problems you have using React?
That's 7 JS questions
TypeScript does NOT help you, unless you're a bad programmer.
The whole point of strong typing is that dim bulbs get confused with loose typing and write bugs they can't later find.
Great
Funny how you said that you don't do function composition or use it often when that's literally all you do with react. Interesting that people don't even know that.
Yeah, it’s unintuitive for people, but everyone who uses anything in the JS ecosystem uses it all the time. I think it’s fine; knowing the details helps, but people get adequate intuition just from using things. Kind of like music theory.
This is the problem with a language that relies too much on 3rd party libraries + frameworks to do things that should probably be built into the language. JS isn't even a real OOP language. Maybe it is nowadays, I'm not sure but when I started learning years ago, it was called "Object Based" rather than "Object Oriented". I guess TS makes it feel like OOP though. My point is that it is difficult for most devs to get below the surface of the layers and layers of libraries and frameworks so I think it is understandable if they don't know they are using something like "composition" in some project already.
Yeah my point is it's not something I think about. React gives a structure for doing that. It's not a decision I make or think about.
Nope, but I got the job anyway 😉
lmaooo love that!
I've never, and will never consider JS to be a functional language. If you want functional, go with Haskell, Erlang, or Elixir. It has functional components to it as mentioned, but using JS in a pure functional way is restricting yourself from leveraging the full power of the language.
lmao
You can make functions in Javascript…?!
What would consider JS then? A hybrid?
@@kiranpillai876yes it’s multiparadigm
Calling JS a functional language is a bit like calling myself a vegetarian just because I’m capable of eating a salad every now and then.
The questions related to functional programming concepts need a deep dive slash correction. I'm gonna assume that you know the principal ideas, but you seem a little lost in the vid. Calling JS a functional language, confusing deterministic and pure, calling logging *not* a side effect and a closure a nested function would have you lose the interview big time with serious corporations. And you really have to know your TDD, or you ain't get hired (even if companies don't use it to the letter).
These questions are meant for you to fall in the trap of subtleties between the functional world and the imperative world, and you fell for the trap with eyes wide open. If you want, you can contact me, and I'll help you get the facts straight in a follow-up video.
13:32 So what are you trying to say?
Don't Do Cocaine please
pls give questions first not answers thanmsks
Damn, was hoping to see some fun nuances and idiosyncrasies of vanilla Javascript but was returned Typescript/React crap. Catfished.
I guess businesses and hiring managers aren't interested in esoteric JavaScript nuances, rather they want developers who can build projects as a team.
@@TokyoXtreme More like the illusion that they're hiring those that can. 10 years in the industry and every dev that's made an impression on me did so based on foundational knowledge. But I guess that article was probably directed towards juniors that are just task rabbits.
What a shitty list. All of the "functional" stuff has nothing to do with javascript, and makes numeruous unfounded assertions about the superiority of functional programming. (This is a fad by the way, later we'll here about how obect oriented is actually better).