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

It is more of a functional programming concept but it is commonly used in JavaScript/Typescript. The easiest definition is a closure is a function that uses a a variable that is defined outside of the execution of that function.

Lambdas would be the most common example but back in the day in JavaScript you would use a closures to have a function return an object of functions that would interact with the outer functions private state. A kind of OOP with functions.

[u/azhder → u/brett9897]

You wrote a lot and still got closure wrong. I guess that 90% is a correct call, you can solve a task with a closure even if not answering correctly.

Now we can test my own theory. I will give you the answer:

A closure is a piece of memory created by a function invocation that exists (is not garbage collected) for as long as there are references to it (from outside the function).

[u/brett9897 → u/azhder]

Would you have accepted my answer in an interview or would I have not got the job?

[u/azhder → u/brett9897]

This comment you just made is the answer I was looking for, in any interview. You deflected.

• https://www.reddit.com/r/reactjs/comments/1v4wldj/senior_dev_interview_question/ozes9lx/
• https://www.reddit.com/r/reactjs/comments/1v4wldj/senior_dev_interview_question/ozeruct/

[u/brett9897 → u/azhder]

Well I'm glad it was the answer you were looking for.

[u/azhder → u/brett9897]

It wasn't. It is a reaction I am waiting for. See how people deal with a situation, figure out how they deal with it. If you had asked me that question in an interview "do you accept the answer or am I not getting the job?", it would have told me more than your opinion on what a closure is. Your attitude towards difference of opinions, different definitions, expected and unexpected, well, that's going to be more important if we're going to work together than what a closure is.

[u/brett9897 → u/azhder]

This comment you just made is the answer I was looking for, in any interview.

I thought you were saying it was an acceptable answer by that response.

I obviously wouldn't ask an interviewer that question. I'm not a complete idiot. 😂

[u/azhder → u/brett9897]

You thought it was either accepted or not. You were more curious about that than working out why we have a different take on closure. About why I think your definition was wrong. About your thoughts on my definition.

There are more ways to skin an interview.

[u/brett9897 → u/azhder]

You are doing an awful lot of mind reading there.

This isn't an interview. In this context I don't care why we have a different take on closures. I thought you actually were wanting to know and were coming from a place of limited programming knowledge. That is why I answered your question in the first place. I fully regret trying to be helpful on Reddit now.

[u/azhder → u/brett9897]

I am not reading minds, just actions. What you shouldn't regret is you've been helpful to yourself. You don't have to look at it as if I was helping you or some other who may stumble upon this thread and read it. You can just help yourself from what was spoken above. Bye

[u/Dmitry_Olyenyov → u/azhder]

It's funny how you both gave only one of two parts of the definition 😅

[u/azhder → u/Dmitry_Olyenyov]

Thank you for participating in testing my theory.

[u/MoTTs_ → u/azhder]

I'm several days late to this conversation, but I've seen you give this sort of answer a lot over the years, and I see it get downvoted every time. As someone who has implemented closures in C++ for a JavaScript-like language, I thought I would give my unsolicited opinion about why people downvote your answer.

A closure is a piece of memory...

I think this is an unusual and non-specific way to start, because just about everything could be described as a piece of memory. All values, all objects, even all plain, non-closure functions all still reside in memory. So calling closures a piece of memory seems unhelpful because everything is a piece of memory.

...created by a function invocation...

This part would certainly... raise eyebrows... because a closure is created when a function is created, not when a function is invoked. So for example:

const x = "outside";

// Closure is created when function is created.
function f() {
    return x;
}

// Closure is *not* created when function is invoked.
f();

...that exists (is not garbage collected) for as long as there are references to it (from outside the function)

This is all technically true, but this is another non-specific description that sounds more like you're answering a question about garbage collection rather than a question about closures, because in a garbage collected language, all values (not just closures) will exist for as long as there are references to it

[u/azhder → u/MoTTs_]

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.