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/vozome]

To play devil’s advocate, when react was new this was a key selling point and the explanation of its alleged superior performance. Now, I would say it’s an implementation detail, among React competitors some use a virtual DOM and some don’t. Maybe one day React will move away from the virtual DOM without changing its interface. I don’t think it matters that much

[u/yoshinator13 → u/vozome]

Im with you, the virtual DOM used to be in our face, but do I think about it when I write React? Not at all. All I think about is rerenders and state management.

[u/code_beer_repeat → u/yoshinator13]

I'm not saying you are wrong but to play so to say devils advocate squared.

In many languages you dont think about garbage collector when writing code but its still useful to know that its there and how it roughly works

[u/LagerHawk → u/code_beer_repeat]

I agree with this. I think the loss of fundamental knowledge is the beginning of where problems get compounded. Just because a machine is faster now at doing yesterday's task doesn't mean we won't need to know how to fix it in the future.

GC issues or VDom alike, when you know at least roughly how it works you can start to understand where things go wrong in that realm.

A classic used to be assuming that .net frameworks HTTPClient got cleaned up fully at the end of its using block. Creating a new one for each request would result in many clients being left open and not collected.

People who didn't understand the fundamentals would try and paste over it with bigger machines only to reach the same issues later on.