ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: Senior Frontend Developer Interview Questions
กำลังสร้างบทเรียน...
1
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.
2
These are real interview questions that we've got ourselves in senior front-end interviews, but also our mentees.
3
Number one, we're going to start talking about tooling.
4
And the first question is, can you tell me about your experience using Webpack?
5
What is it used for?
6
Webpack, it's a module bundler.
7
So we basically use it to put several JavaScript files into a single one.
8
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.
9
And when you have a big application with hundreds of files, that's just not practical.
10
So Webpack will kind of bundle all that.
11
It will parse all of them based on your imports and exports and put them all together into a single bundle.
12
And then we can apply different optimizations.
13
I worked a lot with Webpack in the past, basically setting up projects from scratch and doing all kinds of configurations.
14
Nice, Bogdan.
15
Are you familiar, talking about Webpack and module bundlers, are you familiar with the term tree shaking?
16
Tree shaking as in Webpack, it's basically what Webpack will do when we ship our bundle to production.
17
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.
18
and it will basically try to eliminate them.
19
So our bundle is as small as possible and we get the best web performance.
20
Amazing.
21
Have you used tree shaking professionally in production at any stage?
22
Can you give me an example of that?
23
Yes.
24
As far as I know, in version 5, it comes by default.
25
So every time we use Webpack, it will try to tree shake our code.
26
One thing you want to be aware of is that it only works with ES6 static imports.
27
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.
28
So you got to be careful because yes, Webpack ships with it by default.
29
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.
30
Which modules were?
31
So year six static imports are the ones that do allow Webpack to do tree shaking.
32
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.
33
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?
34
Can I drop any of that code until it gets executed in the browser?
35
Excellent.
36
Seems like you know quite a bit about Webpack.
37
Now, what is, still talking about Webpack and tooling and module bundles,
38
you know what is a dependency graph and what is it used for in Webpack?
39
The dependency graph in Webpack is basically what Webpack builds from our entry point.
40
So to basically take our first file and then figure out
41
and go down all those import statements we have at the top
42
and from that it will keep going down until it reaches basically the end
43
and that's basically a tree structure that it forms
44
and that's how it stores basically all our modules and then it's using that to transverse it,
45
to go through it and find out if there's any modules we need to drop or which ones are in production.
46
So it's kind of the main abstraction in Webpack
47
and it will always be used to go from individual files to a single bundle.
48
Cool, now we're going to move on with a question about CSS in JS.
49
Basically, can you explain what CSS in JS is and can you give me an example?
50
What are some use cases for CSS in JS?
51
Yeah, sure.
52
So CSS in JS appeared because we're writing all this JavaScript
53
and we have a lot of interactivity
54
and we basically want to change CSS styles when a certain state or certain variable changes.
55
And CSS in JS allowed us to basically have dynamic CSS where you click a button and some CSS changes immediately.
56
You could do that with classes like you would assign the different class to an element
57
but it's just a lot easier if you could just swap colors
58
or directly do things with javascript variables inside css that wasn't
59
that was not possible before because you had static css files
60
and with css in jess we write our css inside javascript files
61
and then webpack will basically somehow extract that and build different classes and and attach them to the HTML DOM at runtime,
62
but we don't need to worry about that.
63
So it basically allows you to write your CSS in JavaScript and leverage a lot of dynamic styles.
64
So you have the dynamic language like JavaScript, but you can do styling with it.
65
Awesome.
66
So you already mentioned some of the advantages, right, of having JavaScript control variables inside your styling,
67
but what are some disadvantages of using CSS in JS?
68
Well, one of the main disadvantages is that because your styles are now in JavaScript files,
69
you cannot really extract them and do certain optimizations you can do to CSS.
70
And one of the things is you cannot really cache your CSS files.
71
So if your CSS didn't change back in the days, you could have the user storing that in the browser side browser side
72
because you attach a cache policy with HTTP headers to it, like cache control, and they would store that.
73
And in a subsequent visit, they wouldn't have to download all your CSS.
74
But now all that CSS, it's inside our JavaScript file, JavaScript bundle.
75
It's all together, which makes our bundle bigger.
76
It's a bit harder to parse, but it's also non-cacheable.
77
You can actually counterfact that by extracting with Webpack your CSS at the runtime and ship it separately,
78
but it's still not as easy as it used to be when you had your CSS separated from your JavaScript.
79
It's also harder to debug your CSS because, again, those classes that Webpack generates, they're unique hashes,
80
and all of a sudden it's not as easy as it
81
used to be to understand why a certain element looks a certain way.
82
There is some tooling that CSS in JS usually brings on to make that debugging easier.
83
One thing we haven't chatted about is the performance.
84
How does CSS in JS affect performance?
85
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.
86
And yeah, you might also have a a lot of cumulative layer shift
87
because your CSS gets now applied when the JavaScript bundle gets parsed.
88
So in the critical rendering path, we usually evaluate CSS first and we apply it.
89
And that ensures the fact that there's no flash when you load the page.
90
But now because we evaluate this CSS at the end, you might have cumulative layer shift when the user loads the page.
91
Things by move around and you got to be careful
92
and sometimes split your CSS and ship CSS in JS for the dynamic parts
93
and then still use plain old CSS for most of your grid elements so you have a stable page.
94
And the other thing is because we are creating new components, for example, I use style components in React,
95
every time we style a heading or a native React element, we end up creating another component.
96
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,
97
which is always a disadvantage because it makes debugging harder.
98
And of course, a bigger component tree is also harder for React to re-render all the time.
99
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.
📺 ช่องเดียวกัน
✨ วิดีโอแนะนำ
C11
49 ประโยค
Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions
University StudentsBusiness English+2
C11
245 ประโยค
QA Automation Interview Questions and Answers
University StudentsBusiness English+2
B23
11 ประโยค
full audio online video cutter com
University StudentsBusiness English+2
C16
324 ประโยค
Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)
University StudentsBusiness English+2
C14
200 ประโยค
10 JavaScript Interview Questions You HAVE TO KNOW
University StudentsBusiness English+2
C12
239 ประโยค
Excellent 2 Years AWS DevOps Engineer Mock Interview with Questions and Answers | Cloud | Docker
University StudentsBusiness English+2
B23
63 ประโยค
How To Land Your First Junior Dev Role
University StudentsBusiness English+2
C12
405 ประโยค
Netflix product manager mock interview and tips (with ex-Netflix Lead PM)
University StudentsBusiness English+2
C11
674 ประโยค
FULL Data Science Mock Interview | SQL, Statistics, Business
University StudentsBusiness English+2
B21
199 ประโยค
The Essential UX Interview Questions (And How To Answer Them!)
University StudentsBusiness English+2
C13
26 ประโยค
🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts
University StudentsBusiness English+2
เกี่ยวกับบทเรียนนี้
คุณกำลังฝึกภาษาอังกฤษกับ "Senior Frontend Developer Interview Questions" ด้วยเทคนิค Shadowing — วิธีที่พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ
ฟังทีละประโยค สังเกตการเน้นเสียงและการเชื่อมเสียง แล้วพูดตามดังๆ อย่างมั่นใจ ฝึกวันละ 15–30 นาทีจะเห็นผลลัพธ์ที่ชัดเจน
เทคนิค Shadowing คืออะไร?
Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ