शैडोइंग अभ्यास: Senior Frontend Developer Interview Questions - वीडियो के साथ अंग्रेजी बोलना सीखें

Hi folks, Dharos here from Le Senior Dev and today together with Bogdan, we're going to go to a bunch of senior front-end interview questions.

These are real interview questions that we've got ourselves in senior front-end interviews, but also our mentees.

Number one, we're going to start talking about tooling.

And the first question is, can you tell me about your experience using Webpack?

What is it used for?

Webpack, it's a module bundler.

So we basically use it to put several JavaScript files into a single one.

That used to be necessary because in the browser, you basically, in order to add JavaScript, you need to place a script tag for every JavaScript file you have.

And when you have a big application with hundreds of files, that's just not practical.

So Webpack will kind of bundle all that.

It will parse all of them based on your imports and exports and put them all together into a single bundle.

And then we can apply different optimizations.

I worked a lot with Webpack in the past, basically setting up projects from scratch and doing all kinds of configurations.

Nice, Bogdan.

Are you familiar, talking about Webpack and module bundlers, are you familiar with the term tree shaking?

Tree shaking as in Webpack, it's basically what Webpack will do when we ship our bundle to production.

And it will basically try to find that code, sorry, modules that maybe we imported in our code, but we're not really using or parts of modules.

and it will basically try to eliminate them.

So our bundle is as small as possible and we get the best web performance.

Amazing.

Have you used tree shaking professionally in production at any stage?

Can you give me an example of that?

Yes.

As far as I know, in version 5, it comes by default.

So every time we use Webpack, it will try to tree shake our code.

One thing you want to be aware of is that it only works with ES6 static imports.

So if you have any module in your dependencies or you're using common JS imports with require, then Webpack cannot really tree shake that.

So you got to be careful because yes, Webpack ships with it by default.

But if we don't use those kind of modules, then it's not capable of really understanding if it should remove that code or it's not being used.

Which modules were?

So year six static imports are the ones that do allow Webpack to do tree shaking.

and common JS, you know, the old require notation, those ones cannot be tree-shaped because they are dynamic and they are evaluated at runtime.

So they're basically functions and Webpack cannot really use them to build this dependency tree and figure out, okay, what's going on in there?

Can I drop any of that code until it gets executed in the browser?

Excellent.

Seems like you know quite a bit about Webpack.

Now, what is, still talking about Webpack and tooling and module bundles,

you know what is a dependency graph and what is it used for in Webpack?

The dependency graph in Webpack is basically what Webpack builds from our entry point.

So to basically take our first file and then figure out

and go down all those import statements we have at the top

and from that it will keep going down until it reaches basically the end

and that's basically a tree structure that it forms

and that's how it stores basically all our modules and then it's using that to transverse it,

to go through it and find out if there's any modules we need to drop or which ones are in production.

So it's kind of the main abstraction in Webpack

and it will always be used to go from individual files to a single bundle.

Cool, now we're going to move on with a question about CSS in JS.

Basically, can you explain what CSS in JS is and can you give me an example?

What are some use cases for CSS in JS?

Yeah, sure.

So CSS in JS appeared because we're writing all this JavaScript

and we have a lot of interactivity

and we basically want to change CSS styles when a certain state or certain variable changes.

And CSS in JS allowed us to basically have dynamic CSS where you click a button and some CSS changes immediately.

You could do that with classes like you would assign the different class to an element

but it's just a lot easier if you could just swap colors

or directly do things with javascript variables inside css that wasn't

that was not possible before because you had static css files

and with css in jess we write our css inside javascript files

and then webpack will basically somehow extract that and build different classes and and attach them to the HTML DOM at runtime,

but we don't need to worry about that.

So it basically allows you to write your CSS in JavaScript and leverage a lot of dynamic styles.

So you have the dynamic language like JavaScript, but you can do styling with it.

Awesome.

So you already mentioned some of the advantages, right, of having JavaScript control variables inside your styling,

but what are some disadvantages of using CSS in JS?

Well, one of the main disadvantages is that because your styles are now in JavaScript files,

you cannot really extract them and do certain optimizations you can do to CSS.

And one of the things is you cannot really cache your CSS files.

So if your CSS didn't change back in the days, you could have the user storing that in the browser side browser side

because you attach a cache policy with HTTP headers to it, like cache control, and they would store that.

And in a subsequent visit, they wouldn't have to download all your CSS.

But now all that CSS, it's inside our JavaScript file, JavaScript bundle.

It's all together, which makes our bundle bigger.

It's a bit harder to parse, but it's also non-cacheable.

You can actually counterfact that by extracting with Webpack your CSS at the runtime and ship it separately,

but it's still not as easy as it used to be when you had your CSS separated from your JavaScript.

It's also harder to debug your CSS because, again, those classes that Webpack generates, they're unique hashes,

and all of a sudden it's not as easy as it

used to be to understand why a certain element looks a certain way.

There is some tooling that CSS in JS usually brings on to make that debugging easier.

One thing we haven't chatted about is the performance.

How does CSS in JS affect performance?

So that's one of the main things is because you cannot cache your CSS, you're loading it and it will decrease the performance.

And yeah, you might also have a a lot of cumulative layer shift

because your CSS gets now applied when the JavaScript bundle gets parsed.

So in the critical rendering path, we usually evaluate CSS first and we apply it.

And that ensures the fact that there's no flash when you load the page.

But now because we evaluate this CSS at the end, you might have cumulative layer shift when the user loads the page.

Things by move around and you got to be careful

and sometimes split your CSS and ship CSS in JS for the dynamic parts

and then still use plain old CSS for most of your grid elements so you have a stable page.

And the other thing is because we are creating new components, for example, I use style components in React,

every time we style a heading or a native React element, we end up creating another component.

And in a big component tree that will create a huge component layer, which is always a huge component tree, a very deep component tree,

which is always a disadvantage because it makes debugging harder.

And of course, a bigger component tree is also harder for React to re-render all the time.

Even if React is very effective, you want to keep it as small as possible.

100

Awesome, Bogdan.

101

Then we're going to move on to the next question.

102

And we will talk about JavaScript frameworks, specifically React.

103

Have you worked with React in production so far?

104

Yes, I've worked with React for the last, pretty much since 2015.

105

So that will be around pretty much since it came out.

106

Awesome.

107

Then you're probably going to fly to these questions.

108

First question is, what is a pure component in React?

109

Pure component in React.

110

Well, I think, so pure components used to be when we had class components and you wanted to avoid re-renders.

111

you use one of those because it would compare the incoming props with the existing props.

112

And if they are the same, it would skip the render.

113

You probably don't need it today because we use hooks.

114

And hooks are by default memorized.

115

So whenever you do a set state, React already checks if you are updating the state to the same value.

116

And if that's true, it does not render the component.

117

So it kind of comes by default.

118

But back with class components, we had to use pure components.

119

Cool.

120

Another type of component question is, what is an error boundary component?

121

What is it used for?

122

Why do we have error boundaries components in React?

123

Yeah, sure.

124

So basically, error boundaries help you limit the impact of an error.

125

So if you have a data fetching error in some component, you can wrap it with an error boundary, and that will at some level localize the error

126

so it doesn't go up the component key

127

and you don't show the whole thing the whole application broken

128

but you can actually show a placeholder for that one component

129

that something went wrong so it allows you to localize

130

and have a much better predictable UI and also have no layout shift

131

when you have the servers they can totally destroy the UI if they're not managed.

132

Awesome very well now still talking about react in this case we will focus on React hooks.

133

And the hook that we are talking about is, you know, are you familiar with the use effect hook?

134

Tell me more about how is it used?

135

You know, what would be some advantages and disadvantages of using use effect?

136

Yeah, sure.

137

So we basically use effects to trigger what they call a side effect in React.

138

That would mean when a state variable changes, maybe imagine we want to do something else like we want to make a call to our analytics system

139

and to tell something changed or write into local storage, for example, that would be an ideal case for effects.

140

I know when they came out, myself included and all the community kind of abused effects and we're using them for everything.

141

So we would use effects to change a different, when one state variable change, we use effects to change the difference variable.

142

But the thing with effects is that they run after the component re-render and they trigger another re-render.

143

So if you're not careful and you abuse them, you'll end up having so many re-renders in your component.

144

And of course, re-renders of a parent will cause re-render of a child component.

145

So that will really, it can end up affecting your application if you're abusing them performance-wise.

146

Second question about useEffect hook, it's why can't we use an async function as a callback to useEffect?

147

Well, probably because an async function returns by default a promise.

148

and the return of the useEffect hook should always be a cleanup function that allows us to,

149

if we, for example, in the effect attach something to the on scroll effect to remove that handler, because if we don't remove it and we end up re-rendering,

150

we keep attaching handlers to that event and we might bloat the browser.

151

So React allows you to return that cleanup function, but when you use a sync, you're always returning a promise and React doesn't know what to do with promise

152

because it's not it's it expects a function

153

so that's why uh you get this linter here i think most of the times

154

that tells you hey you cannot uh you cannot use an

155

uh an sync function here yeah awesome totally makes sense we

156

are going to move on with a question about state okay

157

and i want you to imagine

158

that we have a simple front-end application with the following state

159

okay number one we will be fetching some data from the backend right then we perform some user authentication

160

and set some general user settings

161

that will affect those those user settings will affect the whole application

162

and my question is you know

163

when we have to deal with such requirements on the client

164

side what would be the best solution to handle state management in this application

165

and why uh sure okay

166

so we have back end we have data we get from the back end We have authentication state

167

that you mentioned and some global settings, right?

168

Yes.

169

Okay.

170

So I'll probably place those differently because of the requirements on them.

171

So usually, from my experience, data that comes from the backend can stay in component state unless it's needed by two

172

or three components where you could usually just lift it up and you have a bit of problem dealing, but it should be manageable with that kind of data.

173

When you have authentication state, you usually want that to be globally available to any component

174

because some components might need it to see the user roles and permissions.

175

That's why I'll probably use something like React context because it's very useful to broadcast the state to the whole component tree.

176

And for the settings, it looks like there might be some non-trivial state transitions in the settings.

177

Usually if you have maybe complex transitions like a user can be premium

178

or not and that will change many different settings across the app.

179

At least that's what I worked with in the past.

180

In that case you might look at the state machine or you might need the reducer pattern.

181

You can of course use something like Redux for that

182

or a smaller like a Zustand library but you do need a reducer pattern when you have these complex state transitions.

183

You can use use reducer with context that also works.

184

So that's how I would distribute state these three different ways.

185

Cool.

186

Now still sticking with state, one question about

187

essential and derived state specifically could you explain the difference between essential

188

and derived state uh the difference between essential and derived state uh

189

so basically essential state would be state that um changes by itself changes independently

190

and you cannot use it any further

191

and the life stated state you could calculate based on the essential state

192

so just to give an example if you had a component

193

that displays like a breakdown of a shopping cart all the different items

194

that you are there they're probably essential state but the total

195

and the vat amount they are derived state because you can compute

196

that based on all the other items so that would be an example

197

and usually you want to keep as little state as possible

198

so you want to have only the essential state in your state hooks in React.

199

Amazing, cool.

200

Now final question about state and React, you know what would be the disadvantages of placing state inside React context?

201

I'd say number one is that if you lift state so far up,

202

anytime that state changes, every component that will be connected to that context will also change.

203

So if you have state that really changes independently

204

and it's consumed by different components you could also split it in two different react contexts to different providers

205

because the components that will subscribe to those will be different you'll have overall less re-renders

206

so that's one of the biggest problem when you leave state in general

207

but especially when you lift it to context it will end up causing re-renders

208

and as a general rule i try to keep state

209

or we should all try to keep state as close to where it's being used.

210

Yeah.

211

Amazing work then.

212

Yeah, we have a bunch of questions, two more categories I will be asking about.

213

We're going to start with testing, right?

214

And specifically, you know, how would you go about testing a React application?

215

Yeah, what, you know, if any, let's think about a mid-sized application, not too big, not too small.

216

There are no tests, the development team was pretty crazy.

217

They've written no tests.

218

It usually happens.

219

We've seen that in companies, but they stitch together a bunch of components.

220

There's data fetching, there's authentication, there's all the kind of functionalities that you find on a client-side application built with React.

221

How would you go?

222

You're hired to bring that up to implement some best practices and that one specifically testing.

223

How would you go about testing this kind of application?

224

Okay, so we have a React application that haven't been tested.

225

I would probably inspect the code base and try to decide either we want to do unit,

226

start with unit test or integration test or end-to-end test, which is the typical testing pyramid.

227

I probably, in my experience in the front end, one of the best tests to have are end-to-end tests because you test the features,

228

which is very clear, and then it allows you to refactor your code behind it without changing the tests.

229

And if we have any components that we're reusing, like imagine we might have input fields that are being reused

230

or buttons or any kind of component that has ideally some logic and is being reused, like a drop down.

231

In that case, I would write some unit tests on them.

232

I'm not a fan of unit testing everything just because in React, you didn't get a lot of value for testing pure components, like just if an image renders.

233

We could do that.

234

Some people do that in order to hit the code coverage.

235

but I would say having some good end-to-end tests, having unit tests on reusable components, and strategically choose some integration tests should be the way to go.

236

And how do you strike the perfect balance between end-to-end tests, unit tests, and integration tests in the front end?

237

That's a very good question.

238

I would say you need to understand, if we write a lot of end-to-end tests, but we have, imagine, no unit tests and integration tests,

239

What will happen is that when your end-to-end test fails, it's good you know that it's a bug, but it will be extremely hard to go to the code and find exactly where it is.

240

So the more you need an integration test you have, the easier it is when you find a bug to localize the,

241

when you make root cause analysis to localize the bug boundary and really eliminate all the other sides of the application.

242

If you only write end-to-end tests, you will have coverage for your features, but when something breaks, it will still take you hours to debug.

243

So I would say I would be smart about it, smart about it and understand your application and then have a certain balance.

244

I cannot give you exact numbers, but I would write a lot of unit tests

245

and a lot of entry-in tests to cover the features and strategically some integration tests on the critical features, like if you have login or if you have payments.

246

You've got to see also what's more critical in your product.

247

You did mention the word code coverage when you were talking about unit testing.

248

Can you tell me more about code coverage?

249

Like just shortly what it is and what would be the appropriate amount of code coverage

250

in your opinion in a front-end application?

251

So yeah, code coverage it's the amount of code that executes when we run the test basically.

252

So people say it's the amount of code we cover in we covered with tests

253

but it's actually the amount of code that actually executes when you're on the test.

254

In the front end I would say it's a bit more

255

tricky than in the back end where it's a bit easier

256

but I would try to keep it all the way up to 60% whenever possible.

257

If you go under 60, then it will be quite unpredictable and the tests are unusable because you can't really trust.

258

There's a lot of code that's not tested, so the test might fail, but you don't really know why we're failing.

259

So 60 to 70% would be good.

260

I think going over 80 to 90, it's a bit of an overkill and you then get a lot of value from those marginal tests.

261

In your last team or company, what was the code coverage you were aiming for?

262

and you know did you have any anecdotes anything that you can tell us how did it went for you

263

um yeah sure

264

so at least in some of my roles i worked in

265

the finance industry where they they may it was general for

266

the company to have around 95 of code coverage uh we ended up writing a lot of tests

267

that made literally no sense um you you have a lot of files

268

that sometimes are just explicitly declared types you had to exclude all those

269

and it was pretty much of a hard measure everybody was saying they do tdd

270

but in the end everybody go test before pushing their pr um

271

so i'll be really careful with these measures

272

because in the end people say they would do it and

273

so on but uh but yeah i had

274

that experience i've also been in teams

275

that didn't go to any test at all to be very honest there was uh chaos

276

that was a disaster

277

and i'll say the perfect balance is in the front end 60 to 70 in the back

278

and i would go a bit more up 90 to 80 80 to 90, 95, it's still doable because the backend again,

279

it's a bit more functional and it's sometimes much easier to unit test

280

or to modularize things than it is in the front end.

281

Cool, now let's start finally, final category, we will talk about web performance,

282

right, and the question here is

283

can you explain fcp okay what are the causes of a bad fcp score okay

284

so fcp fcp would be the first contentful paint

285

which is basically the time it takes since the user hits

286

the the enter button in the browser to display something and to display anything to them

287

and usually it's really bad if you ship a lot of javascript

288

that is client-side rendered so it takes a lot of time to parse all this react bundle

289

and interpret it for the browser to show something

290

or you don't use a cdn so maybe the assets are not compressed

291

or they're not cached and

292

so it literally just takes a lot of time to to do that

293

or you have a lot of css uh css css in

294

the header uh has to be all interpreted before we move on to javascript

295

and finally start incrementally rendering the html um so

296

if you have a lot of that it will also take a long time

297

so these are three courses that I've seen in the past.

298

That's the first thing I would look at.

299

Let's suppose you take charge of a front-end application, you run your analysis, whatever tool you use, Lighthouse for example, and you realize that the FCP,

300

it has a very low FCP score.

301

How would you go about fixing it?

302

So okay, so we saw that the FCP is low on Lighthouse.

303

I'll definitely run a couple of analysis just to make sure the score is legit

304

and once we have

305

that I probably as I mentioned look first into the CDN it's usually the easiest thing to do

306

and gets a lot of benefits if there is not one set

307

and then probably I would use something to inspect the bundle

308

and see if we can remove any part of the javascript that's not being used

309

and if that doesn't still work I'll look into code splitting

310

and really only load the javascript

311

that you need for a specific page I'll probably talk to the product managers

312

and see which are the pages that are more critical for us to load fast.

313

Usually it's not all the pages

314

and I would focus on those ones in code split to make sure

315

that we really load as little JavaScript as possible and maybe defer some of the JavaScript or sync load it.

316

You can do that with Webpack, with react.lazy also you can split your component tree.

317

So basically code splitting would be one of the biggest things I would do after we add the CDN

318

and we make sure we have caching and compression in place.

319

So number one, CDN, caching compression.

320

Number two, remove whatever libraries that you can remove that are adding way too much JavaScript to the bundle.

321

Number three, code splitting and shipping different chunks of JavaScript as you need them, right, to make that lower.

322

Have you considered and when do you consider something like server-side rendering.

323

Let's suppose this is a React client-side rendered application

324

and you've went with all the optimizations and still because of the size of the application, the application is too big and the FCP is way too slow.

325

Would you consider server-side rendering?

326

Would that improve the situation or not?

327

Server-side rendering, when done well,

328

it will definitely improve by basically removing by basically yeah showing instantly we ship the render html to the client

329

so they will get something immediately they'll see something uh it does add however complexity to your code base

330

so i know in some use cases where people rushed into server side

331

and then they had to roll it back i would definitely look at our product

332

and if the product is very sensitive to loading speed

333

or sensitive to seo then you'll get a lot of benefits from server side getting

334

but if it's not if it's like a sas application where it's like a accounting software, then there's usually no value in server-side rendering.

335

So you would stick to CSR still because it's not?

336

Yes, probably in e-commerce, in something like e-commerce or the media where you have a newspaper, they want to load very fast and they're very sensitive to SEO, they're probably most of them using server-side rendering.

337

Asim Bogdan, this was it for today.

338

We covered a lot of topics from CSS and JS to React, React Hooks, to Webpack, to tooling,

339

to testing, and now on to performance.

340

I hope you folks enjoyed this.

341

We're going to publish some more series on this.

342

Thank you, Bogdan, for this one, and we will see you in the next one.

343

See you in the next one.

📺 उसी चैनल से

✨ अनुशंसित वीडियो

200 वाक्य

10 JavaScript Interview Questions You HAVE TO KNOW

Business EnglishInterview EnglishUniversity Students

11 वाक्य

full audio online video cutter com

Business EnglishInterview EnglishUniversity Students

239 वाक्य

Excellent 2 Years AWS DevOps Engineer Mock Interview with Questions and Answers | Cloud | Docker

Business EnglishInterview EnglishUniversity Students

100 वाक्य

How to Answer Situational Questions for Product (PM) Behavioral Interview | Framework + Solution

Business EnglishInterview EnglishUniversity Students

245 वाक्य

QA Automation Interview Questions and Answers

Business EnglishInterview EnglishUniversity Students

63 वाक्य

How To Land Your First Junior Dev Role

Business EnglishInterview EnglishUniversity Students

49 वाक्य

Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions

Business EnglishInterview EnglishUniversity Students

324 वाक्य

Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)

Business EnglishInterview EnglishUniversity Students

674 वाक्य

FULL Data Science Mock Interview | SQL, Statistics, Business

Business EnglishInterview EnglishUniversity Students

72 वाक्य

Interview Question: “What Are Your Weaknesses?” And You Say, “...”

Business EnglishInterview EnglishUniversity Students

26 वाक्य

🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts

Business EnglishInterview EnglishUniversity Students

इस पाठ की शब्दावली और बोलने के सुझाव

यह C1 स्तर का स्पीकिंग पाठ वीडियो “Senior Frontend Developer Interview Questions” पर आधारित है। सबसे ज़्यादा दोहराए गए शब्द ये हैं: component, css, test, react, code। इस वीडियो में शैडोइंग के लिए 343 वाक्य और 4623 शब्द हैं। बोला गया हिस्सा 25:52 लंबा है। वक्ता लगभग 179 शब्द प्रति मिनट की स्वाभाविक गति से बोलता है, जो रोज़मर्रा की बातचीत के करीब है। 83% शब्द अंग्रेज़ी के 3,000 सबसे आम शब्दों में से हैं; बाकी शब्द अभ्यास से पहले देख लेना अच्छा रहेगा।

इस वीडियो की मुख्य शब्दावली

वीडियो के 15 सबसे कठिन शब्द, उच्चारण और अर्थ के साथ:

शब्द	उच्चारण	अर्थ
bundle संज्ञा	/ˈbʌn.dl̩/	गठरी, गड्डी
module संज्ञा	/ˈmɑd͡ʒul/	मॉड्यूल
dependency संज्ञा	/dɪˈpɛndənsi/	निर्भरता
static विशेषण	/ˈstæt.ɪk/	गतिहीन, अचल
inspect क्रिया	/ɪnˈspɛkt/	जाँचना, जाँच करना
interpret क्रिया	/ɪnˈtɜː.pɹɪt/	निर्वचन करना, अर्थ लगाना
graph संज्ञा	/ɡɹæf/	लेखाचित्र, ग्राफ़
abstraction संज्ञा	/æbˈstɹæk.ʃn̩/	अमूर्तन, भावानयन
stitch संज्ञा	/stɪt͡ʃ/	सिलाई
trivial विशेषण	/ˈtɹɪv.i.əl/	नगण्य, तुच्छ
assign क्रिया	/əˈsaɪn/	निर्दिष्ट, आवंटित करना
pyramid संज्ञा	/ˈpɪɹ.ə.mɪd/	पिरमिड, पिरामिड
scroll संज्ञा	/skɹoʊl/	पुस्तक
calculate क्रिया	/ˈkælkjʊleɪt/	गणना करना, हिसाब रखना
consume क्रिया	/kənˈsum/	उपभुक्त

दोहराने लायक वाक्य

वीडियो के छोटे, पूरे वाक्य जिन्हें आप रोज़ की बातचीत में इस्तेमाल कर सकते हैं:

Can you give me an example of that?
Tell me more about how is it used?
Can you tell me more about code coverage?
How would you go about fixing it?
Would you consider server-side rendering?

इस वीडियो का व्याकरण

वक्ता जिन संरचनाओं का सबसे अधिक प्रयोग करता है, वीडियो के असली शब्दों के साथ:

संरचना	वीडियो में
शर्त वाले वाक्य if + उपवाक्य, will/would + क्रिया — शर्त और उसका नतीजा	if they are the same, it would skip · if that doesn't still work I'll look
“used to” used to + क्रिया — बीती आदत या स्थिति जो अब नहीं है	used to be
Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी है	haven't chatted · I've worked · They've written
Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता है	are evaluated · are derived · will be connected

ध्यान देने योग्य उच्चारण

वक्ता 66 बार संक्षिप्त रूपों का प्रयोग करता है, जैसे we're, you're, don't। इन्हें वैसे ही छोटा बोलें जैसा आप सुनते हैं।

“sh” और “zh” की ध्वनियाँ: cache /kæʃ/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, optimization /ˌɑptəmaɪˈzeɪʃən/, compression /kəmˈpɹɛʃ.ən/, abstraction /æbˈstɹæk.ʃn̩/
लंबे शब्द — बलाघात सही रखें: disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, dependency /dɪˈpɛndənsi/, optimization /ˌɑptəmaɪˈzeɪʃən/, asynchronous /eɪˈsɪŋ.kɹə.nəs/

इस वीडियो से अभ्यास कैसे करें

पहले बिना बोले पूरा वीडियो एक बार सुनें और जो शब्द नहीं आते उन्हें लिख लें।
0.75× गति से शुरू करें, एक-एक वाक्य की शैडोइंग करें, और सहज लगने पर सामान्य गति पर लौटें।
अपनी आवाज़ रिकॉर्ड करें और मूल से तुलना करें, ख़ासकर bundle, module, dependency जैसे शब्दों पर ध्यान दें।

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।

शैडोइंग तकनीक: पूरी चरण-दर-चरण गाइड पढ़ें →

शैडोइंग अभ्यास: Senior Frontend Developer Interview Questions - वीडियो के साथ अंग्रेजी बोलना सीखें

how AI broke the SWE Career Ladder

Backend Interview Questions (Junior & Mid)

FullStack Interview Questions (Junior & Mid)

10 JavaScript Interview Questions You HAVE TO KNOW

full audio online video cutter com

Excellent 2 Years AWS DevOps Engineer Mock Interview with Questions and Answers | Cloud | Docker

How to Answer Situational Questions for Product (PM) Behavioral Interview | Framework + Solution

QA Automation Interview Questions and Answers

How To Land Your First Junior Dev Role

Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions

Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)

FULL Data Science Mock Interview | SQL, Statistics, Business

Interview Question: “What Are Your Weaknesses?” And You Say, “...”

🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts

इस पाठ की शब्दावली और बोलने के सुझाव

इस वीडियो की मुख्य शब्दावली

दोहराने लायक वाक्य

इस वीडियो का व्याकरण

ध्यान देने योग्य उच्चारण

इस वीडियो से अभ्यास कैसे करें

शैडोइंग तकनीक क्या है?