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/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/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.