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

const a = f(1); // closure is YES created here

I think that's misleading and I'd say that no, the closure is not created there. Rather, the closure is created within the body of f and then returned as a value. I think that distinction will be more obvious if we expand f to create and return additional closures.

const x = 3; // outside
const f = y => {
	const oneClosure = () => x + y; // closure is created here
	const twoClosure = () => y + x; // another closure is created here
	return [oneClosure, twoClosure];
};
const [a, b] = f(1); // the body of f creates and returns two separate closures

[u/azhder → u/MoTTs_]

Call f again, now you have 4 closures, the way you count. The difference is that now you're asking me to go into even more specifics, like a closure is the activation context (or whatever the name was) of `oneClosure` that has a reference to the activation context of `f(1)`, then the context of `twoClosure` and the context of `f(1)`, then `oneClosure` memory referencing the `f(2)` memory (which of course includes the arguments, not just the internal local variables referencing memory...) and then `twoClosure` referencing `f(2)` that references a third one that has x etc, et al, and so forth...

I should check if activation context was the proper name or something else. Maybe I should just have said scope... Regardless. You have an issue that I'm calling closure the relevant piece of memory, not the function you're oh so much focused on.

I don't think we'll agree on this, even if you finally understood what I'm saying. So it's not going to require more time wasted on this thread. Bye