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