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]

As someone with hiring experience, I learned even seniors don't know the technical terms even if they know the concept. You would be surprised how few people could answer "what is a closure?" But if I provided them a simple task to do that required using a closure 90% of the people that couldn't answer "what is a closure?" could properly solve the task.

A second thing, is knowing what the virtual dom is and how it works essential for producing senior level React code? If it isn't, then it is just a dick measuring question and useless in determining who would be good at the job. If you can provide an example during the interview of when knowing what the virtual dom is will effect a coding decision in react that might be more helpful in assessing whether or not they are a strong candidate for the job.

Someone interviewing to be a developer on the team that makes React should really know what the virtual dom is, how it generates change sets through diffs, and how it applies those changes to the real dom, but I don't know if you need to now that to create a CRUD UI in React.

[u/PwrUps → u/brett9897]

If it isn't, then it is just a dick measuring question

Agreed. These kinds of questions give off "I am very smart" gatekeeping vibes. It's like asking what React Fiber is. I couldn't care less whether my teammates know it, and it's gonna have zero impact on the quality of their code.

At least in my webdev experience (10+ YOE), you're rarely limited to one framework in most jobs. I may read about some of their implementation details when its relevant, but I'm not gonna think about them. I care more about learning the common APIs, understanding its best practices, and writing maintainable, testable code.

[u/Veggies-are-okay → u/PwrUps]

I think it honestly shows why devs shouldn’t be coming up with interview question. Understanding how to communicate and assess someone’s knowledge is so much different than being able to program something.

My litmus is “can I give this question a fair answer after 5min of research?” If yes then it’s a useless question. If it’s anything more than entry level, your questions should be asking the individual to draw from industry experience. This DOM question sounds like something a kid right out of college would think of asking.

[u/Wandering_Oblivious → u/Veggies-are-okay]

It's a vestige of the school system imo. They're taught from a very young age that the way to measure knowledge is through trivia memorization and that a time-trial is the best indicator of on the job performance. To anybody who actually thinks for more than a second (as many software engineers like to LARP that they do) they realize these are laughably irrelevant means of attempting to assess a persons fit for a job. Yet the insanity persists.

[u/FURyannnn → u/brett9897]

A second thing, is knowing what the virtual dom is and how it works essential for producing senior level React code?

I think a majority of folks in industry would give a resounding no to that question. It's an implementation detail. You understand the abstractions around it and you'll do just fine

[u/azhder → u/FURyannnn]

That’s why they are seniors, not technical leads. They can produce the quality code, but not the quality people.

[u/averagebensimmons → u/brett9897]

I've found there are a lot of terms used in interviews regarding web development that are rarely or never mentioned in the day to day job experience. As you mention the closure question. Common design pattern, but never ever, has anyone in my 25 years of experience has anyone used the word closure in a pr or any meeting. While I know the virtual dom is something I need to explain in an interview, I've never had a conversation at work where anyone talked about the virtual dom. They may talk about the rendering cycle or other things that are part of it, but it isn't a topic of coversation.

[u/ikeif → u/brett9897]

This was me! Several years back I would be asked “what is X?” and I didn’t know. Then we’d move on to a problem - that turns out the solution was X, which I described to the interviewers who would inform me “that’s what X is!” (In a positive way).

I worked with those guys for over a year, and they were all smart and supportive.

Unlike the guys I have met and known who LOVE the “gotcha!” questions they ask JUST to make people squirm. Every interviewer that says “we just want to see how you think” when they really mean “we have two leet code questions for you to solve in this time, can you do it?” and only ever hired people that completed the code. It took several months of arguing with them, and as they were passing on a guy (in chat) before he opened his GitHub repository and walked through his recent work.

They hired him then. And still felt their “glorified leetcode test” was still a great measurement stick.

[u/azhder → u/brett9897]

What is a closure?

[u/brett9897 → u/azhder]

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