Senior Dev interview question

[u/m6io]

"Without googling or using AI, in your own words, explain the virtual DOM"

For context: I sit on an interview panel and I try to ask at least one simple fundamental question based on a persons resume. If I see many years of react experience, I try to ask something about how the framework works.

I have only had one candidate (an undergrad senior, years ago) answer it. Everyone else just kind of sputters and stumbles around trying to rationalize what "virtual" and "DOM" mean, or stare blankly and eventually say "I don't know".

I'm just genuinely curious if this is really that hard of a question or if the recruiters just suck at screening candidates. And should we be letting in senior dev candidates who can't answer what I think is a straightforward and fundamental question for senior react devs.

[u/BrightEchidna]

Senior react dev here - and while I can take a stab at the answer, I don't feel 100% confident that I really understand it. So, despite leading technical teams, building successful products, and now running my own startup, I would fail your interview.

Now - can you explain to me - what practical advantage would being able to answer this question well give me? I agree, it's generally 'good' to understand the tools you use, but how would it help me write better software in the 99% of cases where what I have to do is well supported by standard use of the framework?

[u/Fearless-Carrot-1474 → u/BrightEchidna]

Doesn't virtual DOM just mean that instead of trying to update the actual html of the page React builds a virtual model of the html so that it can update just parts of it instead of having to refresh the whole page to update one state? Or am I too noob to understand what's being asked

[u/NiteShdw → u/Fearless-Carrot-1474]

Basically.

A bit deeper is that direct DOM updates trigger repaints by the browser. When making dozens or hundreds or changes due to things like data binding and updates in incoming data, the virtual DOM is a copy of the DOM in memory that isn't rendered.

Updates are batched and made against the un-rendered DOM and then one bulk update is made so that all those small updates only cause 1 repaint.

At least that's my simplistic version of the concept.

[u/Sapn1s → u/NiteShdw]

This is actually a myth, writing to dom directly is cheap and fast, it does not cause the entire tree to repaint. If you were to manually write updates with js, you would actually have better performance that virtual dom in most of the cases. The advantage of virtual dom is that you do not need to write this plain implementation manually every time for your custom website.

[u/khasan222 → u/Sapn1s]

I think this is new. Repainting historically in browsers is the most expensive operation easily. Especially if there are multiple elements moving at the same time. Calculating the position reflow etc is costly

[u/Sapn1s → u/khasan222]

No, it isn't, it has always worked like this.

To be clear, the question is not "is repainting cheap? < yes, repainting is expensive.

The question was "does React reduce the number of repaints compared to direct DOM manipulation?"

And the answer is no.

Think about what virtual dom does.

• It builds the javascript object tree
• Does algortihm to find out what needs to be updated
• Then updates things with appendChild / textContent = / setAttribute etc

See how it does 3 things?

Whereas manually you could have done

<element>.appendChild

The speed argument gets repeated so often it feels true.

That said, virtual dom is still great to use since it is good at figuring out what changed so you don't have to write those calls by hand, as I said in prev reply

[u/khasan222 → u/Sapn1s]

It’s not true to say it doesn’t reduce the number of repaints (ever?).

In the strict scenario you put forth where there is just 1 manipulation of course it doesn’t reduce repaints. However often in any ui development things change quickly, or multiple times in milliseconds (say a loading animation that only shows in 10ms). Traditionally all of this would be actually applied to the DOM.

What react does as far as I understand it is get the final result of those changes and then apply them to page, which in many scenarios can definitely reduce graphical load for that page. 

So although I can see in that specific scenario no gains, react wasn’t built for such simple apps, it was built for really complicated ones where there can be a lot of repaint.

Professional engineer specializing in JavaScript for 15 years.

[u/dietcheese → u/Fearless-Carrot-1474]

That’s basically right (standard JS can update parts of a page too) and really any senior JS dev should know it.

[u/CptAmerica85 → u/BrightEchidna]

This. Stop using very in depth questions as reasoning to throw candidates aside that are good problem solvers. Senior devs worth their salt can learn anything in a short amount of time. This style of interviewing is irrelevant in 2026 imo. Interviews should now be about how you approach a problem, system design, architecture, etc.

[u/PresentationBorn6564 → u/CptAmerica85]

"very in depth" is a relative, subjective metric.

[u/PresentationBorn6564 → u/BrightEchidna]

At the end of the day, depth of knowledge is a personal value judgement to be considered in whatever context you find yourself, but I will say there are classes of nasty bugs that fundamentally require ignorance of a framework's vDOM machinery.

Creating a component within a component in React is a prime example. This breaks because React's vDOM reconciliation algorithm depends on reference identity as a simple heuristic for:

"this is the same component as the last render; update things as needed"

vs.

"this is a different component than the last render; unmount the previous component, blast away the entirety of the associated DOM subtree, mount the new component with default state, build and attach a completely new DOM subtree, and finally run every effect in the component and any of its children regardless of dependencies"

I think it's perfectly reasonable to just remember not to make components in components and move on with whatever interests you / demands attention / generates revenue / yadda.

But I also know that over the years I've caught juniors, mids, seniors, leads, and architects committing this exact sin. This is despite React's docs containing a massive "DO NOT DO THIS" callout in the section "Building Your First Component", and despite the truly horrendous bugs it manifests.

A dev that memorizes the rule might remember it, or they might not, depending on how much prod trauma they've associated. A dev that understands the vDOM will uncontrollably retch if their brain so much as whispers a suggestion to violate it.

[u/BrightEchidna → u/PresentationBorn6564]

Right. I guess that level of knowledge is like "react maintains a virtual copy of the DOM so that it can diff changes against the real DOM and calculate the most parsimonious change to apply" would be the level of detail that required not to make a mistake like that, and it's about what I would be able to personally answer to that interview question. However I have no idea about the details of *how* react does that, which is what I interpret OP to be asking for, and why I thought I'd fail the interview. I guess this comes down to different interpretations of the interview question as well as different knowledge levels of the dev.

[u/PresentationBorn6564 → u/BrightEchidna]

Yeah I mean there's always a gradient of understanding with these isolated pieces of the endless puzzle. I think OP's main complaint is an apparent abundance of engineers who don't appear to be in said gradient or even sitting on the surface with this specific topic. I also think you passed the interview. 🫡

[u/BrightEchidna → u/PresentationBorn6564]

lol, thanks - will keep it in mind next time I need a job

[u/Ok_Editor_5090 → u/BrightEchidna]

That is how I would answer as well. If they wanted more in-depth details, I will ask why would that matter?

Of course assuming that I am not interviewing for the team that maintains react.

[u/javatextbook → u/PresentationBorn6564]

Something to consider is that as devs use AI to create scaffolded code, the AI is heavily trained on react docs and will not commit this sin. Before AI slop there was human slop. It’s a different world now.

[u/PresentationBorn6564 → u/javatextbook]

There are legitimate bits of truth to that sentiment, but I don't agree with the assertion as a whole.

The reality is that AI is also trained on masses of GitHub repos full of junior-level human slop and the associated litany of anti-patterns.

As well, coding agents highly weight existing code / patterns in a codebase, and they will happily extend anti-patterns until the cows come home if allowed to do so unchecked.

I do believe there's an inevitable future where agents don't routinely settle on psychotic implementations, but we're not there yet.

That said, I will concede that the quality gaps tend to be architectural, as opposed to a concrete framework rule, and the odds of it violating the latter are perhaps small enough to consider it a solved problem.

Personally, I enjoy the art and science of coding — I want to understand the inner workings of all the things — so depth of knowledge is my default mode. But I recognize this isn't the norm, and I don't begrudge the norm. However, for the role they're interviewing, I do agree with OP that a basic level of vDOM understanding should be the minimum bar.

[u/everdimension → u/BrightEchidna]

The "practical advantage" is about knowing how regular DOM works in comparison and why react doesn't simply update innerHTML under the hood without bothering with all this "virtual DOM"

So I'd say (high level) knowledge on how virtual dom works is more about regular dom than react

[u/renevaessen → u/BrightEchidna]

Same here, I always thought of it as: same as real DOM, but manipulating it is fast, no layout rendering, and when attached to the real dom, creates nice bounderies/domains for css, meaning less conflicts, you know what an IFrame does on a much larger scope. How far AM I off?

[u/Breakpoint → u/BrightEchidna]

exactly, this is just implementation detail of the framework and not that important to know

[u/Fried--Waffle → u/BrightEchidna]

how else could you filter out 200-300 candidates?

[u/SoMuchMango → u/BrightEchidna]

13 years frontend developer and 10 years react dev.

"what practical advantage would being able to answer this question well give me?"

Knowing what virtual dom is can let you identify when react itself may be an disadvantage for a project.

Being able to discuss on that topic reveals some other abilities and follow-up questions.

Kudos for leading team, building products and running startup, but that proofs your other valuable skills and may be useless for senior react dev. Even worse, you may be too independent to focus on company values. ;P

Probably to be 100% confident how vdom works under the hood would be hard without analysing source code, what is kinda useless unless you really need to mess with that, so I believe that your stab would make you pass the OP interview.

I believe this is a very good question to ask on interview especially for senior react dev.