쉐도잉 연습: 10 JavaScript Interview Questions You HAVE TO KNOW - 영상으로 영어 말하기 배우기

If I was going to give you a JavaScript focused interview, would you be able to answer these 10 questions?

Let's talk about it.

There has almost never been a more important time to be prepared for your interviews than right now, with layoffs and searching for next jobs.

Being able to go in and nail a technical interview is incredibly important.

So I found this article on 10 interview questions every JavaScript developer should know in 2024.

I have a link to the full article you can go and read from Eric Elliott.

But what I'm going to do is just kind of walk through these 10 and talk about them a little bit, and then give you a little bit of my perspective of whether

or not these are things you should take super seriously and how deep of knowledge you should have into each one.

Now, before we get into this, I do want to share that I'm working on building a template

and a mini course on how to do better in your tech interviews.

So if you're interested in updates on what I'm working on, sign up for my newsletter at JamesQQick .com and scroll all the way to the bottom.

All right, let's start with number one.

And this is what is a closure?

Now closures are kind of interesting because it's not something that I think about all that often.

It's not a term that I use very often.

But it is one of those core like tricky parts of JavaScript questions that I feel like you see a lot.

So what is a closure?

Well, a closure is basically defining a function inside of some parent scope.

And that function is going to continue to have access to the things that are defined or inside of its parent scope.

So let's see an example here.

We have a function called createSecret.

It takes a parameter of secret and this function returns an object, which then has two functions, a getter and a setter for that secret.

Now, the whole key to closures is that these inner functions that are returned will still have access to this original parameter.

from its parent scope, which is the containing function.

So if we call create secret, we get back the my secret object, and then we can call its functions like get secret, and it will return that original thing that was that was passed in.

Now, again, this is not something...

I think about a lot.

This is not something that comes up in my code, but there is one key implication here that I think you need to know.

And that is that these variables are live references to the outer scoped variable, not a copy.

What that means is if you were to then inside of this return function, change that original value, that value is changed associated with that that variable,

and it's not a copy of it.

So we'll change the original one.

So that's something interesting to note.

Common use cases here.

You'll see this in data privacy, basically encapsulation.

so that people can have access to a counter, but not necessarily have direct access to the properties inside of it.

So you won't have a direct reference to the count property.

You will have a reference to these functions that then have a reference to this.

Now, again, this is not something that I've used very often, but it is something that comes up a lot when you're building libraries in JavaScript or something like that.

So anyway, this is definitely a core topic for you to know and explain.

This is another really good one.

This is a pure function.

And basically the answer to this is fairly simple.

When you call this function and pass in the same parameters, you should get the same results each time.

So that is the word there is deterministic.

So same input means same output.

And it also means no out, outside effects.

And that means don't change state anywhere else in the application

when you call this function only work with the things that are inside of the function itself.

So an example of non -deterministic functions, one would be a random number generator.

You call random number generator, it's going to give you a different answer every time.

That's kind of the point.

And then examples of side effects, modifying an external variable global state, for example.

And they also mentioned on here logging to the console.

I personally wouldn't consider that to be a side effects.

I'm not like changing state anywhere.

I'm just logging to the console.

That may be up for debate.

I don't really know.

But there's a couple of different, a couple of different examples in here for side effects.

So, Deterministic, same input, same output, and no side effects.

If you get into something like Redux, all the reducers there must be pure functions.

So if you've done Redux, which I've done very little, then you're probably pretty used to that pattern.

Now the next question is, what is function composition?

Function composition is something I never think about.

It's not a term that I use.

I've never defined this for anyone, but it is an interesting concept in JavaScript.

based on the next two questions that we'll talk about, because it is relevant to that.

But function composition is basically taking multiple functions and putting them together and returning a function that leverages those original functions.

So in this case, we have compose, it takes two functions, And then we return a function.

that calls the inner function first and then the outer function with the result of the inner function.

Now, again, I don't I don't see myself like writing this type of code.

almost ever.

It's not something I've really done.

I don't really expect that to come up much in interviews.

but could be relevant to these next couple of questions.

So what is functional programming?

This is core to what people think about JavaScript being.

But I do think there's one important thing that you may not know is JavaScript can be a functional language.

It also can be an object -oriented programming language.

So it can be used as either one of these, although we mainly associate JavaScript with a functional programming language.

So functional programming language basically uses functions as the unit of composition.

Again, function composition, that being relevant in the functional programming world.

I So they have a few different key aspects here.

Immutability, this is a big one in JavaScript.

Immutability says don't change the original thing.

but assign that basically to a new one.

So if you think about array functions, those are typically immutable or arrays are typically immutable,

where the array functions don't mutate the actual array itself.

Now, that's not the case for every function.

So you have to actually pay attention to which functions do mutate the original array and which ones don't.

But in general, we look for ones that don't.

We also have higher order functions, a function that accepts a function and returns a new function.

and then not having a shared mutable state.

So going back to the idea of pure functions, you don't have this, broader state that you can go and change.

And if we think about in React, this actually comes up when we use the use state hook.

You can't just change that state because React won't know about it.

React only knows about a change to that state

if you call the set state function and give it a brand new state.

100

So instead of updating existing state, you take that state, you use it to create a new state and then you set the new state.

101

Now, this one is probably the most important one on this list, and it's what is a promise?

102

And I would go even deeper.

103

to what is asynchronous programming, how does asynchronous JavaScript work, whatever combination of that you want.

104

And so it's interesting

105

or it's essential to be able to understand a promise from the perspective of the state of a promise pending fulfilled rejected.

106

It's important to know how to handle that from a dot then dot catch, etc. It's important to talk about chaining promises together.

107

And then I would even go into more modern syntax with async await.

108

I only use async await when I work with promises.

109

So this is something I would use all the time.

110

Now, if you want to know like a little hack to get better at understanding how promises work, The hack is to go and build a promise yourself,

111

which I think a lot of people don't actually take the time to do.

112

So if you want to better understand how promises work, go and do this as an exercise.

113

Build it yourself, and then you'll learn more about how you actually work with promises

114

because you understand how they work as a whole.

115

Now this is number six is probably the second most important topic on here and that is what is TypeScript.

116

TypeScript is becoming so so popular.

117

If you look at jobs for React or any other framework you're probably seeing TypeScript be associated with that as well.

118

So my recommendation for people after you have.

119

decent JavaScript knowledge, you've worked with a framework, now go into TypeScript.

120

That's the next layer of something that I think is almost essential in the workforce now.

121

getting into jobs with JavaScript.

122

So you can give kind of the stereotypical definition.

123

It's a superset of JavaScript, blah, blah, blah.

124

Basically, the big thing is it gives you static typing or strong typing for your variables.

125

It also then gives you more support in your IDE from IntelliSense and auto completion documentation,

126

etc. You can also specifically use this word, transpiled, TypeScript is transpiled into JavaScript,

127

which allows it to run in any browser.

128

You could talk about a lot of different things in here.

129

What I would want you to do is talk about how you've used TypeScript and what you thought about it, how it helped you.

130

So make sure you actually have a project that you've used it on.

131

so that you can talk about it intelligently.

132

Now, number seven is kind of, to me, up for debate, which is what is a web component.

133

I've never specifically used web components, I see people talk about them,

134

but they haven't gotten the level of usage that I would expect to make this a common question.

135

Now, the caveat to this is if the company that you're interviewing with uses web components, you should be going and researching what web components are.

136

But if you don't have that specific knowledge, Web components is something I would probably skip over a little bit.

137

I don't think this is as important.

138

I think there's other topics that are more important.

139

So I would probably skip that one.

140

Now if you're doing something in the React ecosystem, this is an absolute essential, which is what is a React hook.

141

So I would give examples of what are some of the ones you've used, useState and useEffect.

142

Those are by far the two most common.

143

I think extra points goes to people that have used additional ones like contacts like ref reducer, et cetera.

144

I think going a little bit deeper there is super important.

145

And I think writing custom hooks and being able to explain those is also really important.

146

And then maybe you could take it one step further

147

and talk about creating a custom hook inside of the react context API, so that you can access this from different components across your application.

148

I think that would be a great example to go a little deeper into.

149

I think One additional thing to know is what are the potential negative implications with use effect?

150

How do you get into infinite loops, for example?

151

Have any example that you can talk about with that I think would be really good as well.

152

Now this next question, how do you create a click counter in React?

153

If you're applying for something with React or you say you have experience with React, This to me seems way too basic.

154

I would expect you to be able to do a lot more, even if it's live coding.

155

than just this piece right here.

156

This is like this, the Hello World component that you see in every framework.

157

I would expect you to be able to go a lot farther and deeper into this.

158

So although this is like, yes, you should be able to do this, I think don't just set the bar that low.

159

You should be able to do a lot more and talk about much.

160

bigger, deeper, impactful components that you've worked on in your applications.

161

Now, the last one here is test driven development.

162

And I do think testing is important.

163

I think that's something that a lot of companies are looking for.

164

I also think test -driven development is some people love it.

165

Some people hate it.

166

I think it's kind of a 50 50 thing, and I don't think I wouldn't expect the majority of companies to be looking for experience in test driven development.

167

But that said, I think you should be able to talk about what it means and what the pros and cons are.

168

So in this case, they talk about the benefits, code coverage, improved API design, fewer bugs, better code quality, etc. The flip side of this,

169

though, is I think the only way you get those benefits is if everyone is fully on board.

170

If you have people writing code that are not doing TDD on your team, you're kind of messing it up for everyone.

171

So culturally, everyone has to be on board for this to work.

172

So we talk about the steps here, write a test first, write the implementation and then make sure that the test passes.

173

It's not that hard.

174

And I don't think you have to, to be able to answer this question.

175

I wouldn't say you have to have hands on experience doing TDD.

176

Just know what it is and what the concept is.

177

I think this is key to all of these questions.

178

If they ask you, why would you use or what are the benefits of blah, blah, blah?

179

I would also have prepared.

180

What are the challenges with this thing?

181

Or what are the downside?

182

Because there's always trade offs. with everything.

183

And I think this is a good call out here to what are the challenges with TDD, specifically the learning curve.

184

It's time consuming because you're writing more tests, et cetera.

185

So I think focusing on both the pros

186

and the cons for any question that you want to be able to answer is super, super important.

187

So anyway, those are 10 questions that you should consider for your next JavaScript developer interview.

188

But the most important thing is, and the number one thing you should do is go and do your research first as to what to expect.

189

before you then come back and look at this list.

190

So if you have any upcoming interviews, make sure you ask what to expect and backtrack and prepare based on that.

191

But that said, how did you feel about this list?

192

What do you think was missing?

193

What are some of the essentials in JavaScript that you should be able to answer in your technical interviews going forward?

194

Let me know in the comments below.

195

If you're interested in getting better at your tech interviews, I am working on a template worksheet and a mini course or ebook I haven't decided.

196

So if you want to follow along check that out at James Q.

197

Quick updates.

198

Check that out at James Q.

199

Quick updates.

200

Check that out.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

쉐도잉 연습: 10 JavaScript Interview Questions You HAVE TO KNOW - 영상으로 영어 말하기 배우기

이 수업에 대해

주요 어휘 및 구문

연습 팁

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법