シャドーイング練習: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM) - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

253 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

So today we will answer some of the hardest senior

React interview questions our M &T's got in real front -end interviews.

We are going to deep dive into concepts such as concurrent

React, React Fiber, the reconciliation process, and the virtual DOM.

Bogdan is going to answer the interview questions, but also give you the mental models and the reasons why behind his explanations.

Bogdan, are you ready?

Yes, let's go.

And let's go with the first question.

What is React Fiber and how is it different from the virtual DOM?

Perfect.

So I'm going to go ahead and share my screen for this one.

What is React Fiber and how is it different from the virtual DOM?

Well, to put this simply, back in the days we had our React elements

that would create a virtual DOM node and then that will be translated into an actual DOM node with reconciliation.

But the problem with this is that it's a very synchronous process.

That means imagine we have a huge tree of elements.

We need to render all of those.

I compute the state

and with JSX compute the virtual DOM node all done synchrously in one shot and then render the DOM.

And what React introduced in version 16 with React asynchronous is the fiber node, which is an intermediate structure that gets created.

And basically all the work of rendering component is done by fiber, by this fiber node.

So just like you had a tree of virtual DOM nodes, now you have a fiber tree.

Whenever we need to re -render, we work on this tree, we compute the new state, we run certain lifecycle methods.

And once we are done, we can then compute the virtual DOM from the fiber tree.

And the big advantage of having this structure

and the why behind it is that differently from the virtual node and traditional rendering, the fiber reconciliation can be paused.

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,

do something else, and then come back to this.

And that was not possible before fiber.

So that would be the big difference where the virtual DOM, it's only used now to actually compute the differences to the DOM.

And the fiber, it's a new intermediate structure that allows us to pause

and prioritize the render process to make it asynchronous or what they call concurrent React.

Cool, Bogdan.

This leads me to our second question today, which is, can you explain the reconciliation process in React?

And also, if you can tell me what does the introduction of React Fiber means for the reconciliation process as well?

So in the reconciliation, in traditional reconciliation, we had our component.

It will trigger a state change, and that will trigger a re -render of the component re.

And re -rendering means we would go from the root node, the root component, all the way to the children,

all the way to what we call the leaf nodes, the very bottom components, and run the render function recursively.

And we would put that in the call stack.

So all these things will be into the call stack, all the way to the bottom.

Then we would execute them.

And finally, from that, we would extract the new virtual DOM.

That's what they call the stack reconciler.

And this one, it's kind of synchronous in the sense of, imagine we have a huge component tree,

we would need to put recursively all those render functions in here, finish them, and then finally render.

When we have a huge component tree, you might have what we call a blocking UI.

Imagine we're fetching some data and rendering things on the screen.

If you are completing a form at the same time as a user,

you would perceive that form as non -responsive because the call stack is busy by rendering these components that are being fetched.

And so we can't really re -render, for example, the UI.

The browser cannot repaint, so maybe you're typing in an input field, but you don't see anything happening.

So that was kind of the old reconciliation process.

And after that, we had our VDome.

We would make our diffing algorithm and finally commit to the DOM, the changes needed.

That was how

React used to work.

With Fiber, things are a bit more complex.

So what React does is from the component tree, it will build what we call a fiber tree.

And a fiber, it's nothing but, let me zoom in, I think I have a fiber around here.

It's a JavaScript object.

And inside there's many properties, but probably the most important are the state and the new props, like the props the component has,

the memorized props, everything you need about the component, the function that runs it, the siblings and the child are all here.

And so React will create a fiber tree with this internally.

And it will run the render function for that fiber tree.

And from it, it will deduct the virtual DOM.

And then the process is just like before.

The virtual DOM gets compared with our diffing algorithm and we commit changes to the DOM.

So far, nothing changed, but we have this intermediate step.

Nice.

Now, what I still don't understand by the minute, right now we have the fiber tree, right?

As a, in between the virtual DOM and the state changes the plate.

And I'm wondering...

Why the fiber tree?

Why do I need fiber in the first place?

Because it adds extra complexity.

And I'm wondering, what does fiber allows me to do that the virtual DOM couldn't?

You mentioned this asynchronous rendering.

Could you expand a bit on that?

Because it feels to me like it's adding a lot of complexity.

React was already complex.

The diffing algorithm was already complex.

And now we have a stage in between that's kind of definitely adding another layer of abstraction, of complexity.

Is it worth it?

Do we really need why? and why do we really need this step, this fiber tree?

Yeah, very good question.

So what the fiber tree allows us to do is that it works together with a priority queue and a scheduler.

And rather than having this process synchronous, like we really, as I explained before about the stack reconcilator,

we would go like have to run the whole render in one shot.

We can actually pause.

We can actually stop at a certain node, pause and do something else and then come back to this render.

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,

an update gets attached to this fiber tree.

So let's imagine there's a state change here for this form component.

There is an update queue for this form component and that change that will be queued there.

And what React will do after that is to copy the current fiber tree in the background and do work on it.

That means just go through each node and see

if there's any updates and compute the new memoized state and run the render method.

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.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

このレッスンの語彙とスピーキングのポイント

このスピーキングレッスンは、動画「React Interview Questions Senior Level」を教材にしています。繰り返し出てくる語は次のとおりです：react, fiber, tree, Dom, render。この動画には、シャドーイング用の文が253文、単語が3294語あります。音声の長さは17:15です。話す速さは速く、1分あたり約191語です。音のつながりや弱く発音される音が多くなります。英語の頻出3,000語に含まれる単語は80%だけなので、語彙は難しめです。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
virtual 形容詞	/ˈvɜɹt͡ʃuəl/	事実上の
priority 名詞	/pɹaɪˈɒɹɪti/	優先, 優先権
component 名詞	/kəmˈpoʊ.nənt/	部分
node 名詞	/noʊd/	結節
element 名詞	/ˈɛləmənt/	要素, エレメント
stack 名詞	/stæk/	塚
pause 名詞	/pɔːz/	休止, 中断
reconciliation 名詞	/ˌɹɛkənˌsɪliˈeɪʃ(ə)n/	和解
commit 動詞	/kəˈmɪt/	預ける, 任せる
queue 名詞	/kju/	列, 待ち行列
compare 動詞	/kəmˈpɛɚ/	比べる, 比較する
framework 名詞	/ˈfɹeɪm.wɜːk/	骨組み
complexity 名詞	/kəmˈplɛk.sɪ.ti/	複雑さ
stable 名詞	/ˈsteɪ.bəl/	馬小屋, 厩舎
fundamental 形容詞	/ˌfʌn.dəˈmɛn.təl/	基本的な

動画に出てくる句動詞

単語	発音	意味
go ahead 動詞	/ˌɡoʊ əˈhɛd/	どうぞお先に

繰り返し練習したい文

動画に出てくる短く完結した文です。日常会話でそのまま使えます。

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?

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
条件文 if + 節, will/would + 動詞 — 条件とその結果	if they're not unique, react won't be
「used to」 used to + 動詞 — 今はもう違う過去の習慣や状態	used to work · used to be
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	will be translated · is done · can be paused
関係詞節 who / which + 節 — 人や物について情報を加える	node, which is · today, which is · function, which is

注意したい発音

話し手はyou're, I'm, don'tなど、短縮形や弱形を41回使っています。聞こえたとおりの短い形で発音しましょう。

「th」の音: algorithm /ˈælɡəɹɪðm̩/, thread /ˈθɹɛd/, strengthen /ˈstɹɛŋ(k)θən/
「sh」と「zh」の音: reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, explanation /ˌɛkspləˈneɪʃən/, motivation /ˈmoʊ.tə.veɪ.ʃən/, efficient /ɪˈfɪʃənt/, animation /ˌæn.ɪˈmeɪ.ʃən/
長い単語（アクセントの位置に注意）: 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/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: virtual /ˈvɜɹt͡ʃuəl/, reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, algorithm /ˈælɡəɹɪðm̩/, scroll /skɹoʊl/, trail /tɹeɪl/
/v/ — /b/ にならないように、上の歯を下唇に当てる: virtual /ˈvɜɹt͡ʃuəl/, developer /dɪˈvɛləpɚ/, motivation /ˈmoʊ.tə.veɪ.ʃən/, curve /kɚv/, dive /daɪv/
/f/ — 「フ」ではなく、上の歯と下唇で出す: fiber /ˈfaɪ.bɚ/, framework /ˈfɹeɪm.wɜːk/, fundamental /ˌfʌn.dəˈmɛn.təl/, fetch /fɛt͡ʃ/, folk /foʊk/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。virtual, priority, componentなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM) - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Backend Interview Questions (Junior & Mid)

how AI broke the SWE Career Ladder

FullStack Interview Questions (Junior & Mid)

Senior Frontend Developer Interview Questions

おすすめ動画

React Conf 2025 React Native Keynote

BGP Overview

Use these CSS features instead of JavaScript

Armchair Architects: Resiliency in the Cloud – Core Patterns

Video

Can This Vibe Coder Beat a Senior Developer?

Trust the Process: How to Design Teams That Actually Work

How I deploy serverless containers for free

The future unfolds! How to optimize Android apps for adaptive layouts

10 Essential React Native Tips Every Developer Must Know

Is React Native Dead? Shopify Is Leaving