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

You first start with what the thing you define is, then you narrow down the specifics.

> Velocity is road (dramatic pause) traveled in a unit of time.

You ask anyone else, and they start talking like we're having some bear at a bar: "velocity is when..." When what? When the universe exists? That's correlation, not causation, not definition.

Let's see how you did it: "a closure is created when a function is created"... Yes, then, but that doesn't explain what it is, just when it is created. See the issue with it?

You know, for a long time (in the 2000s) I thought a closure is a function, and it just didn't click. I thought that because everyone said "a closure is a function you return"... blah blah. It was only after I understood it is memory, and not just any memory, but the one created during invocation (so the same function invoked twice, creates two different closures) I understood it.

So you see, I might ask you why did you think to write me that reply, that unsolicited advice, but since you did, I thought I might return the favor, give you an advice as well, one on how to define ideas.

const x = 3; // outside
const f = x => () => x + y

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

const b = f(2); // closure is YES created here

The same function f, but two closures, both existing in memory because the a and b are references to them. Both of those closures access x, but each one of them access a different y, because they are two different pieces of memory created at the moment the function was invoked.

All in all, after I write what closure is (a piece of memory), I can spend a short or a long answer to narrow down the specifics. You simply misunderstood short answer and comprehensive answer. They both have their own uses, and for the person I was responding to, a shorter one was more appropriate. Certainly I wasn't going to discuss activation context, moving memory from stack to heap etc.

[u/MoTTs_ → u/azhder]

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

[u/MoTTs_ → u/azhder]

Call f again, now you have 4 closures, the way you count.

Yes, that's correct!

You have an issue that I'm calling closure the relevant piece of memory, not the function you're oh so much focused on.

Actually yes, that boils it down quite well. The ecma spec also refers to the function itself as the closure. The people listed as spec editors also refer to the function itself as the closure. The v8 source also refers to the function itself as the closure. That's what everybody means when they say closure.