Shadowing Practice: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM) - Learn English Speaking with Video
Kies een oefenmodus
Elke modus opent een volledig scherm oefenruimte.
253 zinnen
Als zinnen te kort of te lang zijn, klik op Bewerken om ze aan te passen.
1
So today we will answer some of the hardest senior
2
React interview questions our M &T's got in real front -end interviews.
3
We are going to deep dive into concepts such as concurrent
4
React, React Fiber, the reconciliation process, and the virtual DOM.
5
Bogdan is going to answer the interview questions, but also give you the mental models and the reasons why behind his explanations.
6
Bogdan, are you ready?
7
Yes, let's go.
8
And let's go with the first question.
9
What is React Fiber and how is it different from the virtual DOM?
10
Perfect.
11
So I'm going to go ahead and share my screen for this one.
12
What is React Fiber and how is it different from the virtual DOM?
13
Well, to put this simply, back in the days we had our React elements
14
that would create a virtual DOM node and then that will be translated into an actual DOM node with reconciliation.
15
But the problem with this is that it's a very synchronous process.
16
That means imagine we have a huge tree of elements.
17
We need to render all of those.
18
I compute the state
19
and with JSX compute the virtual DOM node all done synchrously in one shot and then render the DOM.
20
And what React introduced in version 16 with React asynchronous is the fiber node, which is an intermediate structure that gets created.
21
And basically all the work of rendering component is done by fiber, by this fiber node.
22
So just like you had a tree of virtual DOM nodes, now you have a fiber tree.
23
Whenever we need to re -render, we work on this tree, we compute the new state, we run certain lifecycle methods.
24
And once we are done, we can then compute the virtual DOM from the fiber tree.
25
And the big advantage of having this structure
26
and the why behind it is that differently from the virtual node and traditional rendering, the fiber reconciliation can be paused.
27
So we can actually pause, you know, when we go into the fiber and we have a higher priority update, we could actually pause this,
28
do something else, and then come back to this.
29
And that was not possible before fiber.
30
So that would be the big difference where the virtual DOM, it's only used now to actually compute the differences to the DOM.
31
And the fiber, it's a new intermediate structure that allows us to pause
32
and prioritize the render process to make it asynchronous or what they call concurrent React.
33
Cool, Bogdan.
34
This leads me to our second question today, which is, can you explain the reconciliation process in React?
35
And also, if you can tell me what does the introduction of React Fiber means for the reconciliation process as well?
36
So in the reconciliation, in traditional reconciliation, we had our component.
37
It will trigger a state change, and that will trigger a re -render of the component re.
38
And re -rendering means we would go from the root node, the root component, all the way to the children,
39
all the way to what we call the leaf nodes, the very bottom components, and run the render function recursively.
40
And we would put that in the call stack.
41
So all these things will be into the call stack, all the way to the bottom.
42
Then we would execute them.
43
And finally, from that, we would extract the new virtual DOM.
44
That's what they call the stack reconciler.
45
And this one, it's kind of synchronous in the sense of, imagine we have a huge component tree,
46
we would need to put recursively all those render functions in here, finish them, and then finally render.
47
When we have a huge component tree, you might have what we call a blocking UI.
48
Imagine we're fetching some data and rendering things on the screen.
49
If you are completing a form at the same time as a user,
50
you would perceive that form as non -responsive because the call stack is busy by rendering these components that are being fetched.
51
And so we can't really re -render, for example, the UI.
52
The browser cannot repaint, so maybe you're typing in an input field, but you don't see anything happening.
53
So that was kind of the old reconciliation process.
54
And after that, we had our VDome.
55
We would make our diffing algorithm and finally commit to the DOM, the changes needed.
56
That was how
57
React used to work.
58
With Fiber, things are a bit more complex.
59
So what React does is from the component tree, it will build what we call a fiber tree.
60
And a fiber, it's nothing but, let me zoom in, I think I have a fiber around here.
61
It's a JavaScript object.
62
And inside there's many properties, but probably the most important are the state and the new props, like the props the component has,
63
the memorized props, everything you need about the component, the function that runs it, the siblings and the child are all here.
64
And so React will create a fiber tree with this internally.
65
And it will run the render function for that fiber tree.
66
And from it, it will deduct the virtual DOM.
67
And then the process is just like before.
68
The virtual DOM gets compared with our diffing algorithm and we commit changes to the DOM.
69
So far, nothing changed, but we have this intermediate step.
70
Nice.
71
Now, what I still don't understand by the minute, right now we have the fiber tree, right?
72
As a, in between the virtual DOM and the state changes the plate.
73
And I'm wondering...
74
Why the fiber tree?
75
Why do I need fiber in the first place?
76
Because it adds extra complexity.
77
And I'm wondering, what does fiber allows me to do that the virtual DOM couldn't?
78
You mentioned this asynchronous rendering.
79
Could you expand a bit on that?
80
Because it feels to me like it's adding a lot of complexity.
81
React was already complex.
82
The diffing algorithm was already complex.
83
And now we have a stage in between that's kind of definitely adding another layer of abstraction, of complexity.
84
Is it worth it?
85
Do we really need why? and why do we really need this step, this fiber tree?
86
Yeah, very good question.
87
So what the fiber tree allows us to do is that it works together with a priority queue and a scheduler.
88
And rather than having this process synchronous, like we really, as I explained before about the stack reconcilator,
89
we would go like have to run the whole render in one shot.
90
We can actually pause.
91
We can actually stop at a certain node, pause and do something else and then come back to this render.
92
The way that's done, and I'm going to try to explain it really quickly, is that whenever an update, let's say, imagine a set state happens,
93
an update gets attached to this fiber tree.
94
So let's imagine there's a state change here for this form component.
95
There is an update queue for this form component and that change that will be queued there.
96
And what React will do after that is to copy the current fiber tree in the background and do work on it.
97
That means just go through each node and see
98
if there's any updates and compute the new memoized state and run the render method.
99
But it does all this in the background.
100
And so that means while React does all this, right?
101
Imagine we have a huge component tree.
102
It can actually, it does it asynchronously.
103
It doesn't take all the main thread to do this.
104
Basically, what React does, it goes to our main thread, to the web browser, and calls this function, which is, I do not have it here,
105
but it's called the request idle callback, which basically, it tells the browser, hey, do you have some free time?
106
Are you idle?
107
And the browser says, yes, I am idle, and I will let you do some work for around 50 milliseconds.
108
That's the default in the browser.
109
And then React goes and starts doing this work, right?
110
Ticker, ticker, ticker it doesn't need to finish.
111
It will just do some work.
112
When React finished the frame budget, we call it that way, like the browser says, okay,
113
you've done enough, but now I need to free the main thread to repaint or re -render the UI, then React will pause everything.
114
And this was impossible before.
115
You really needed to finish the render before doing anything else.
116
One follow -up question that comes to my mind is, how can we manage all this in memory?
117
I mean, how can we prevent memory leaks? the whole fiber tree will basically stay somewhere in memory
118
and we're kind of adding changes to those
119
and how can we make sure nothing nothing goes wrong
120
so what react does really well is to reuse a lot of the fiber tree
121
so you see when we create this new work in progress
122
that we're rendering a lot of these nodes are copied especially
123
if react see that they didn't change so
124
if imagine one of those fiber uses the use memo hook or the react .memo and the props didn't change, React will not re -render.
125
It will just maintain a reference to the previous one.
126
So it's very optimized and it tries to use as much as possible of the previous fiber tree.
127
Understood.
128
So it's kind of prepared for that to be as efficient as possible and not use too many resources.
129
You mentioned a high priority update.
130
How does that work?
131
What do you mean by that?
132
What I mean is that imagine we are fetching some data
133
and rendering a huge list of elements that would be a low priority update
134
because it's nothing that we need to instantaneously show to the user.
135
Whereas whenever the user is typing something on an input field
136
and we want to show a focus or an outline on that input field or even an error message, we want to react to user input,
137
then yes, that would be a much higher priority update.
138
So React will pause this low priority render, it will create a new work in progress tree for the high priority update,
139
finish that one, commit, like compute the virtual DOM and commit the changes to the DOM and then go back to the low priority update.
140
That's why it's called concurrent react or synchronous react
141
because you can actually use a priority queue to under the hood prioritize those updates.
142
So for the end user, even if we're doing a lot of background work, the UI feels a lot more fluid.
143
Here's basically the list of internal priorities that the React developers added to the framework.
144
The top priority would be a discrete event, like if they click or they type on an input.
145
The second one would be they scroll, and we need to show something on screen because the user scrolled.
146
A normal priority would be something like data fetch, and a very low priority would be a route change, for example.
147
And all this is internal to the React code base.
148
We don't need to worry about it.
149
But it's important for us to know that this is how
150
React handles now.
151
Again, re -renders in updates.
152
And so that's quite a bit of complexity, I would say, for the average React developer.
153
And I have a follow -up question prepared.
154
But first, let's answer the third question that I have prepared here,
155
which is, what can you tell me about the diffing algorithm and the virtual DOM?
156
So as I mentioned, this render process, it can be paused and asynchronous.
157
But whenever we finish this, we have a synchronous phase, which is the commit phase, which is I know what changes I need to do.
158
And now I'm going to commit them to push them to the actual DOM.
159
So what we do is once we have each fiber tree finished and we have the memory state,
160
we can compute the VDOM, the new virtual DOM.
161
This didn't change much with previous React we will compare the VDome,
162
the new one, with the current feature DOM and try to figure out the differences.
163
Now, traditionally, comparing two trees like that would take, I think the big O for this would be N to the third.
164
So N by N by N, N being the number of elements.
165
So imagine we have a thousand elements.
166
It would take a billion operations to actually compare those trees.
167
Wow. So, yeah.
168
So React has two heuristics, which is it basically assumes that if the type of an element change,
169
so if this form is not a form anymore, then it will discard all the children and try to recompute that.
170
So because that's a lot cheaper, like re -rending that from scratch, it's a lot cheaper than comparing everything.
171
So that's the first one, which is, you know, if different type, then redo.
172
And the second one is assume keys are stable.
173
I'll get in a second into keys.
174
They're stable and unique.
175
So whenever we have a list of elements, we react will ask for that key prop.
176
And it will use that to actually really fast compare those elements.
177
If our keys are not stable, that means they change values all the time.
178
We're pushing a lot of new work.
179
And if they're not unique, react won't be really able to use them
180
because it really tries to identify a leaf tree with the key
181
so imagine here we'd have um 15 inputs it would use
182
that key to differentiate which ones do i need to render
183
which ones i don't have this is why for example
184
you should never use array indexes as keys in a real component because they're not stable right exactly because if you
185
You would delete an element in position five of the array.
186
All the others will shift.
187
And all of a sudden, maybe React doesn't render element number six, even if the actual content or the underlying state has changed.
188
So this is a trail of heuristic.
189
And you need to know this as a developer in order to really avoid having weird issues.
190
So, of course, I have a follow -up question prepared for that.
191
But I just wanted to take a break.
192
And for everyone watching last year, probably watching this video because you are either interviewing right now, and I guess you are a JavaScript engineer,
193
whether it's front -end with React or front -end general, full -stack, even back -end developers interviewing right now, then we have a present for you.
194
So we prepared a free technical assessment for you to understand what your technical gaps are
195
and to also adjust your interviewing process
196
and try to fix those gaps for you to be formed in your next technical interview.
197
It's available for free in the comments.
198
The link is going to be there.
199
And you can go to the CNETF website and take it and I wish you the best of luck.
200
With that being said, my big question right now, after seeing all this stuff, I mean, React was already,
201
you know, the learning curve was quite steep and the framework itself is becoming pretty complex.
202
I mean, you spent a few hours to have this kind of thing on that.
203
This knowledge is also not readily available online.
204
So you have to kind of dig deeper into the source code, the documentation.
205
So the million -dollar question is, how much, how deep should the average
206
React developer go?
207
How much should a mid -level developer know?
208
How much should a React engineer know?
209
I guess to answer that, it very much depends of what kind of developer you are.
210
If you're a senior full -stack developer, a bit more spread out, you cannot really spend so much time in React.
211
And so I would just learn maybe the motivation of the React team behind it and a top -level API.
212
But if you are a senior
213
React developer, what we have seen in the market is that it did became a bit more overcrowded than it used to be.
214
And so this level of technical depth, although daunting, it will really help you stand out in an already overcrowded market.
215
And the good news I have for everybody else is that the data structures that are being used, like queues and priority heaps and trees,
216
they will develop your thinking model and your language.
217
And so you don't really lose by going this deep.
218
If you're a senior
219
React developer, I think you will have to go pretty deep into it because this is your thing.
220
You are a senior React developer.
221
If you're a senior front -end developer also, but if you're a senior full stack, I would just look at the top -level ideas behind it
222
and try to understand the motivation of the React team behind
223
it you will not have to interact with the Fiber directly at any point as a developer.
224
So there's no need to go too deep into it.
225
And if you're a React developer trying to deepen your knowledge about React internal, trying to learn more about Fiber 3, where would you start?
226
I would start with the browser APIs.
227
There are two main functions that they built concurrent
228
React around, which is request idle callback, which is, hey, the browser is free and says, you can give me some work to do.
229
I will do it in the background.
230
And that's when React starts rendering.
231
And I think the other one was a request animation frame, which is the browser saying, I'm going to repaint and re -render the UI.
232
Is there anything really quickly that you want me to do before?
233
And that's when React commits changes to the DOM, high priority changes.
234
So you see them in the next refresh, in the next repaint.
235
If you learn those, first of all, you can use them in other frameworks.
236
And then you'll realize that everything they built into Fiber was to be able to use these APIs in a concurrent mode.
237
And that's why they did a priority queue to it and the whole fiber thing.
238
So I would start there.
239
Which is why, folks, and for the people watching us, you will see this across the whole Synodave channel and across everything we do,
240
but fundamentals are the way to go, right?
241
Because as you can see, whatever frameworks are trying to build upon, it's always upon basic browser functionality and JavaScript fundamentals, right?
242
We talked about basic data structures.
243
We'll talk about the call stack.
244
And as you can see, when Barton was actually explaining and going to the Fibre explanations, he did a complexity analysis.
245
He was always referring to data structures that are agnostic and to JavaScript characteristics that are built into the language.
246
So if you really, funny enough, if you really want to master the advanced features of a framework like
247
React, you actually need to master and strengthen your fundamentals first.
248
If you're interested into strengthening your fundamentals, then you're in the right place.
249
Make sure you subscribe to the channel.
250
Let us know in the comments if there's any other advanced react question, senior level question that you want Bogdan or I to cover,
251
or if there's anything in this video that you want us to go deeper into.
252
And we expect a lot more videos like this coming your way.
253
Bogdan, thank you so much, and we will see you folks in the next one.
App downloaden
Alles wat je nodig hebt om vloeiend te spreken
AI UitspraakScoor elke zin
IPA OefeningBeheers elk geluid
WoordenschatBouw je woordenschat op
WoordenspelLeren terwijl je speelt
Zelfde Kanaal
C13
Backend Interview Questions (Junior & Mid)
Interview EnglishUniversity StudentsWorking Adults
C12
how AI broke the SWE Career Ladder
Business EnglishInterview EnglishUniversity Students
C15
FullStack Interview Questions (Junior & Mid)
Business EnglishInterview EnglishUniversity Students
C1Senior Frontend Developer Interview Questions
Business EnglishInterview EnglishWorking Adults
FOR YOU
Aanbevolen Video
C11
558 zinnen
React Conf 2025 React Native Keynote
Daily ConversationUniversity StudentsWorking Adults
C1101 zinnen
BGP Overview
Daily ConversationUniversity StudentsWorking Adults
C12
185 zinnen
Use these CSS features instead of JavaScript
Daily ConversationUniversity StudentsWorking Adults
C11
180 zinnen
Armchair Architects: Resiliency in the Cloud – Core Patterns
Daily ConversationUniversity StudentsWorking Adults
B21
132 zinnen
Video
Daily ConversationUniversity StudentsWorking Adults
B21
169 zinnen
Can This Vibe Coder Beat a Senior Developer?
Daily ConversationUniversity StudentsWorking Adults
C11
346 zinnen
Trust the Process: How to Design Teams That Actually Work
Daily ConversationUniversity StudentsWorking Adults
C11
78 zinnen
How I deploy serverless containers for free
Daily ConversationUniversity StudentsWorking Adults
C115
23 zinnen
The future unfolds! How to optimize Android apps for adaptive layouts
Daily ConversationUniversity StudentsWorking Adults
C11
184 zinnen
10 Essential React Native Tips Every Developer Must Know
Daily ConversationUniversity StudentsWorking Adults
C11
202 zinnen
Is React Native Dead? Shopify Is Leaving
Daily ConversationUniversity StudentsWorking Adults
Woordenschat en spreektips bij deze les
Deze spreekles is gebaseerd op de video “React Interview Questions Senior Level”. Deze woorden komen het vaakst terug: react, fiber, tree, Dom, render. Deze video bevat 253 zinnen en 3294 woorden om na te spreken. Het gesproken deel duurt 17:15. De spreker praat snel, ongeveer 191 woorden per minuut, dus reken op verbonden en ingeslikte klanken. Slechts 80% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden, dus de woordenschat is pittig.
Belangrijke woorden in deze video
15 woorden uit de video die het leren waard zijn, met uitspraak en betekenis:
| Woord | Uitspraak | Betekenis |
|---|---|---|
| react werkwoord | /ɹiːˈækt/ | reageren |
| render werkwoord | /ˈɹɛn.dɚ/ | veroorzaken |
| virtual bijvoeglijk naamwoord | /ˈvɜɹt͡ʃuəl/ | virtueel |
| priority zelfstandig naamwoord | /pɹaɪˈɒɹɪti/ | voorrang, prioriteit |
| component zelfstandig naamwoord | /kəmˈpoʊ.nənt/ | onderdeel, component |
| developer zelfstandig naamwoord | /dɪˈvɛləpɚ/ | ontwikkelaar, ontwerper |
| element zelfstandig naamwoord | /ˈɛləmənt/ | element |
| stack zelfstandig naamwoord | /stæk/ | stapel |
| pause zelfstandig naamwoord | /pɔːz/ | pauze |
| reconciliation zelfstandig naamwoord | /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/ | verzoening |
| commit werkwoord | /kəˈmɪt/ | toevertrouwen, toewijzen |
| queue zelfstandig naamwoord | /kju/ | rij |
| compare werkwoord | /kəmˈpɛɚ/ | vergelijken |
| framework zelfstandig naamwoord | /ˈfɹeɪm.wɜːk/ | geraamte |
| complexity zelfstandig naamwoord | /kəmˈplɛk.sɪ.ti/ | ingewikkeldheid, complexiteit |
Phrasal verbs die je zult horen
| Woord | Betekenis |
|---|---|
| figure out werkwoord | uitvogelen, er achter komen |
Zinnen om te herhalen
Korte, volledige zinnen uit de video die je in alledaagse gesprekken kunt gebruiken:
- Why do I need fiber in the first place?
- Could you expand a bit on that?
- Do we really need why?
- I mean, how can we prevent memory leaks?
- What do you mean by that?
Grammatica in deze video
De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:
| Structuur | In de video |
|---|---|
| Voorwaardelijke zinnen if + zin, will/would + werkwoord — een voorwaarde en het gevolg | if they're not unique, react won't be |
| “Used to” used to + werkwoord — een vroegere gewoonte of toestand die niet meer klopt | used to work · used to be |
| Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet | will be translated · is done · can be paused |
| Betrekkelijke bijzinnen who / which + zin — extra informatie over een persoon of ding | node, which is · today, which is · function, which is |
Uitspraak om op te letten
De spreker gebruikt 41 samentrekkingen en verkorte vormen, zoals you're, I'm, don't. Spreek ze kort uit, zoals je ze hoort.
- De “th”-klanken: algorithm /ˈælɡəɹɪðm̩/, thread /ˈθɹɛd/, strengthen /ˈstɹɛŋ(k)θən/
- De klanken “sh” en “zh”: reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, explanation /ˌɛkspləˈneɪʃən/, motivation /ˈmoʊ.tə.veɪ.ʃən/, efficient /ɪˈfɪʃənt/, animation /ˌæn.ɪˈmeɪ.ʃən/
- Lange woorden — let op de klemtoon: priority /pɹaɪˈɒɹɪti/, developer /dɪˈvɛləpɚ/, reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, complexity /kəmˈplɛk.sɪ.ti/, fundamental /ˌfʌn.dəˈmɛn.təl/
Klanken die Nederlandstaligen lastig vinden:
- Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: node /noʊd/, pause /pɔːz/, thread /ˈθɹɛd/, whereas /(h)wɛɹˈæz/, expand /ɪkˈspænd/
- /æ/ — opener dan de Nederlandse “e”: react /ɹiːˈækt/, stack /stæk/, algorithm /ˈælɡəɹɪðm̩/, gap /ɡæp/, whereas /(h)wɛɹˈæz/
- /g/ — een harde plofklank, geen Nederlandse “g”: algorithm /ˈælɡəɹɪðm̩/, gap /ɡæp/, trigger /ˈtɹɪɡɚ/, agnostic /aɡˈnɒstɪk/
Zo oefen je met deze video
- Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
- Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
- Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als react, render, virtual.
Wat is de Shadowing-techniek?
Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.