Video guide
17:15 · 25 July 2024
Senior React Interview Questions & Answers
Chapters 8 sections
- 0:00Introduction to React Fiber and Virtual DOM
- 2:17The Reconciliation Process and Stack Reconciler
- 3:56Why Fiber is Needed and Memory Optimization
- 8:32Concurrent React and Priority Queues
- 9:36Internal Update Priorities
- 10:05The Commit Phase and Diffing Algorithm
- 12:00Depth of Knowledge Needed for React Developers
- 16:07Browser Fundamentals and Conclusion
Interview questions in this video:
- 01
1. What is React Fiber, and how is it different from the virtual DOM?
Before Fiber, rendering was synchronous: compute the whole virtual DOM in one shot, then commit. A huge tree meant a blocked main thread.
Fiber (React 16) is an intermediate tree of plain JavaScript objects — one fiber per component, holding state, memoized props and references to child and sibling. Render work happens on the fiber tree, and crucially, it can be paused and resumed.
The virtual DOM still exists — it's now computed from the fiber tree and used only for diffing against the previous version.
React FiberVirtual DOMConcurrent React - 02
2. Can you explain the reconciliation process in React?
Old React used the stack reconciler: a state change triggered a recursive render from the root to the leaves, all on the call stack, synchronously. Big tree + data fetching = a form that won't respond while React renders.
With Fiber, React copies the current fiber tree in the background, applies queued updates node by node, and computes the new virtual DOM from it. Then the classic part: diff against the current DOM and commit the changes.
The commit phase is still synchronous — it's the render phase that became interruptible.
Stack reconcilerWork-in-progress treeCommit phase - 03
3. Why did React need Fiber at all? What does it enable?
Scheduling. Fiber works with a priority queue and a scheduler: React asks the browser for idle time via requestIdleCallback, works within the ~50ms frame budget, and pauses when the browser needs the main thread back.
A high-priority update — the user typing — can interrupt a low-priority one — rendering a fetched list. React parks the low-priority work-in-progress tree, handles the input, then resumes.
That's what "concurrent React" means: the UI stays fluid because rendering yields to the browser.
requestIdleCallbackPriority queueFrame budget - 04
4. How does React prioritize updates?
Internally there's a priority ladder: discrete events like clicks and typing at the top, then continuous events like scroll, then normal work like data fetching, down to low-priority things like offscreen route changes.
You don't manage it directly — but knowing it exists explains why input stays responsive while a heavy list renders.
Update prioritiesDiscrete events - 05
5. How does the diffing algorithm work? Why does React use heuristics?
Properly diffing two trees is O(n³) — a thousand elements would be a billion operations. React cheats with two heuristics.
One: if an element's type changed, throw away the subtree and rebuild it — re-rendering from scratch is cheaper than deep comparison. Two: assume keys are stable and unique, and use them to match list items across renders.
DiffingO(n³)Heuristics - 06
6. Why shouldn't you use array indexes as keys?
Keys only help if they're stable. Delete item five and every item after it shifts index — React now matches the wrong fibers to the wrong data, skipping re-renders it needed or redoing ones it didn't.
Use a real identity from the data.
KeysList rendering - 07
7. How deep into React internals should you actually go?
Depends on your positioning. Senior full-stack: the motivation and the top-level API are enough — you'll never touch a fiber directly.
Senior React/frontend: go deep. The market is crowded and this depth stands out. Bonus: the data structures involved — queues, priority heaps, trees — sharpen your engineering vocabulary everywhere else.
Career strategyInterview positioning - 08
8. Where should you start if you want to learn React internals?
Start with the two browser APIs the whole design orbits: requestIdleCallback (the browser granting background work time) and requestAnimationFrame (the pre-repaint hook where committed changes land).
Everything Fiber does — the priority queue, the interruptible render — exists to use those two APIs well. Fundamentals first; the framework follows.
Browser APIsFundamentals first
Transcript
So today we will answer some of the hardest senior React interview questions our minty has 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. Uh, 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 the 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 like computer state and with JSX, uh, compute the virtual DOM node all then singly in one shot. And then render the DOM and what React introduced in uh version 16 with React synchronous, it's 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 the traditional rendering, the fiber reconciliation can be paused, so we can actually pause, you know, when we're going to 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 dome is only used now to actually compute the differences to the dome. And the fiber, it's a new intermediary structure that allows us to pause and prioritize the render process, to make it asynchronous, or what they call concurrent in React. Cool. Well then um 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 BF fiber means for the reconciliation process as well. So, in the reconciliation, in traditional reconciliation, we had our component, it would trigger a state change and that would trigger a render of the component tree. And 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 visual dome. 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 this 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, right, we had our VDOM, we would make our diffing algorithm and finally commit to the dome, the changes needed. That was how React used to work. With fiber, things are a bit more complex. So, What React does, it's 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 this, many properties, but probably the most important are the state and the new props, like the props the component has, the memoized 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 the fiber tree with this internally, right? And it will render render function for all the for that fiber tree. And from it, it will deduct the virtual dome, and then the process is just like before, the virtual dome gets compared with our diffing algorithm and we commit changes to the dome. So far, nothing changed, but we have this intermediate step. Nice. Now, what I still don't understand, Bogdan, it's right now, we have the fiber tree, right, as a in in between the virtual dome and the stage changes that. Right? And I'm wondering why why the fiber tree? Why do I need fiber in the first place, right? right? Because it adds extra complexity. And I'm wondering, what does fiber allows me to do that the virtual dom couldn't? You you mentioned this asynchronous rendering, right? Could you expand a bit on that? Because it feels to me like it's 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 kind of definitely adding another layer of abstraction, of complexity. Um, is it worth it? Do we really need why? And why do we really need this step? This fiber tree. Yeah. Yeah, very 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, like as I explained before about the the stack reconciliator, we would go like have to run the whole render in one shot. We can actually pause. We can actually stop at the certain node, pause and do something else and then come back to this render. The way
that's done, and I'm going to sort of explain it really quickly. is that whenever an update, um, 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 phone component. There is an update queue for this phone component and that change that will be cued 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 can't 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. And so that means while React does all this, right? Imagine we have a huge component tree, um, it can actually it does it asynchronously, it doesn't take all the main thread to do this. Basically what React does, it's it goes to our main thread to the web browser and calls this function, which is, uh, I do not have it here, but it's called request either callback. Which basically it tells the browser, hey, um, do you have some free time? Are you idle? And the browser says, yes, I'm idle and I will let you do some work for around 50 milliseconds, that's the default in the browser. And then React goes and starts doing this work, right? It doesn't need to finish, you know, it will just do some work. When React finish the the frame budget, we call it that way, like the browser says, okay, you've done enough. But now I need to free the main thread to repaint or render the UI. Then React will pause everything. And this was impossible before, you really needed to finish the render before doing anything else. One follow-up question that comes to my mind, it's how can we manage all this in memory? I mean, how can we prevent memory leaks? The whole fiber tree will basically stay somewhere in memory and we're kind of adding changes to those and how can we make sure nothing nothing goes wrong? So, what React does really well is to reuse a lot of the fiber tree. So, you see when we create this new working progress that we're
rendering. Um a lot of this nodes are copied, especially if React see that they didn't change. So, 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. It will just maintain a reference to the previous one. So, it's very optimized and it tries to reuse as much as possible of the previous fiber tree. Mhm. Understood. Understood.
So it's it's kind of prepared for that to be as efficient as possible and and not not use too many resources. You mentioned a high priority update. How how does that work? What do what do you mean by that? What I mean is that imagine we are fetching some data and rendering a huge list of elements. That would be a low priority update because it's it's nothing that we need to instantaneously show to the user.
Whereas whenever the user is typing something on an input field 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. Then, yes, that would be a much higher priority update. So, React will pause this low priority render. It will create a new working progress tree for the high priority um update. Finish that one, commit, like compute the virtual dome and commit the changes to the dome and then go back to the low priority updates.
That's why it's called concurrent react or synchronous react because it can actually use a priority queue to under the hood prioritize this update so for the end user, even if we're doing a lot of background work, the UI feels a lot more fluid. Here's basically the list of internal priorities that the React developers added to the framework. The top priority would be a discrete event, like if they click or they type on an input.
The second one would be the scroll and we need to show something on screen because the user scrolled. A normal priority would be something like data fetch and a very low priority would be a route change for example. And all this is internal to the React code base, we don't need to worry about it. But it's important for us to know know that this is how react handles now. Um re-renders in updates. And so that's quite a bit of complexity I would say for the average react developer.
And I have a follow up question prepared uh, prepared here, which is what can you tell me about the diffing algorithm and the virtual DOM? So, as I mentioned, this render process, it's it can be paused and asynchronous, 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 and now I'm going to commit them to push them to the actual DOM. So, what we do, it's once we have each fiber tree um finished and we have the my state, we can compute the VDOM, the new virtual DOM. This didn't change much with previous React.
We will compare the VDOM, the new one, with the current virtual DOM and try to figure out the differences. Now, traditionally, comparing two trees like that would take, I think the big O for this would be n to the third. So n n by n by n, n being the number of elements. So imagine we have a thousand elements, it will take a billion operations to actually compare those trees. Wow. So, yeah, so React has two heuristics, uh, which is it basically assumes that if the type of an element change, so if this form is not a form anymore, then it will discard all the children and try to recompute that. So, because that's a lot cheaper,
like rendering that from scratch is a lot cheaper than comparing everything. So that's the first one, which is, you know, if different type, then we do. And the second one it's assume means they change values all the time. We're pushing a lot of new work. Um, and if they're not unique, React won't be really able to use them. Because it really tries to identify a leaf tree with a key. So imagine here we'd have um 15 inputs. It would use that key to differentiate which ones do I need to render and which ones I don't have. This is why, for example, you should never use array indexes as keys in area component. Because they're not stable. Right? Exactly. Because if you delete an element in in position five of the array, all the others will shift and all of a sudden maybe React doesn't render element number six even if the actual content or the underlying state has changed. So these are the 12 heuristic and you need to know this as a developer in order to really avoid having weird issues. So, of course, I have a follow up question prepared for that, but I just wanted to take a break and uh for everyone watching us, you're probably watching this video because you are either interviewing right now, and I guess you are a JavaScript engineer, whether it's, you know, front end with React or front end general, full stack, even back end developers interviewing right now. Then we have a present for you, so we prepared a free technical assessment for you to understand what your tingle gaps are, and to also adjust your interviewing process and try to fix those gaps for you to perform in your next tingle interview. It's available for free in the comments. The link is going to be there and you can go to the C Dev website and take it, and I wish you the best of luck. With that being said, my my you know, like big question right now about this after seeing all this stuff. I mean, React was already, you know, the learning curve was quite steep and the framework itself is because becoming pretty complex. I mean you you spent a few hours to have this kind of tingle depth. This knowledge is also not really available online, so you have to kind of dig deeper into the source code, the documentation. So my the million dollar question is, much, how deep should a the average React developer go? How much should a mid-level developer know? How much should a React
react engineering know. I guess to answer that, it very much depends of what kind of developer you are. If you are a senior full stack developer, a bit more spread out. You cannot really spend so much time in React. And so I would just learn maybe the motivation of the React team behind it and a top level API. But if you are a senior React developer, what we have seen in the market is that it did became a bit more overcrowded than it used to be. And so this level of technical depth will took daunting, it will really help you stand out in in the uh in the already overcrowded market. And the good news I have for everybody else is that the data structures that are being used like Qs and priority heaps and trees. They will develop your thinking model and your language. And so you don't really lose by going this deep if you're a senior React developer, I think you will have to go pretty deep into it because this is your team. You are a senior React developer. If you are a senior front end developer, also. But if you are a senior full stack, I would just look at the top level ideas behind it and try to understand the motivation of the React team behind it. You will not have to interact with a fiber directly at any point as a developer. So there's no need to go too deep into it. And if you're a React developer trying to deepen your knowledge in about React internals trying to learn more about fiber tree, where would you start? I would start with the browser APIs. There are two main functions that they build concurrent React around, which is request idle callback. Which is hey, the browser it's free and says you can give me some work to do, I will do it in the background. And that's what React starts rendering. And I think the other one was request animation frame, which is the browser saying, I'm going to repaint and re-render the UI. Is there anything really quickly that you want me to do before? And that's when React commits changes to the DOM. High priority changes. So you see them in the next refresh, in the next repaint. If you learn those, first of all, you can use them in other frameworks and then you'll realize that everything they built into fiber was
to be able to use these APIs in a concurrent mode. And that's why they they did a priority queue to it and and the whole fiber thing. So I would start there. Which is why folks, and for the people watching us, you will see this across the whole senior dev channel and across everything we do, but fundamental side the way to go, right? Because as you can see, whatever frameworks are trying to build upon, it's always upon basic browser functionality and JavaScript fundamentals, right?
with the basic data structures, we talk about the call stack. And as you can see when was actually explaining and going through the fiber explanations, he did a complexity analysis. He was always referring to data structures that are agnostic and to JavaScript characteristics that are built into the language. So, if you're really funny enough, if you really want to master the advanced features of a framework like React, you actually need to master and strengthen your fundamentals first.
If you're interested into strengthening your fundamentals, then you're in the right place. I'll make sure you subscribe to the channel, let us know in the comments if there's any other advanced react questions, senior level question that you want to cover or if there's anything in this video that you want us to go deeper in into and to expect a lot more videos like this coming your way., thank you so much, and we will see you folks in the next one.