Yeah but here's the thing: I do understand the event loop, I understand the sync/async models in JS but I have very little knowledge of how setTimeout works in this context. That's because I've never used it, and I've never used it because the book that I read 15 years ago about JS said something like this: "Here's a function that allows you to run some code after some time. If you feel the need to ever use it, it means you're doing something wrong, therefore please never use it". This very vague explanation combined the lack of usage of it makes it pretty hard for a candidate like me to realize that you are actually asking a question about event loops. So my question is, if you want to see my knowledge about those things, why not ask some direct questions about it?

I'm the kind of interviewer that would keep asking until you do know. I would actually start with asking about the event loop. Don't know that, no problem, what happens with setTimeout()? Don't know that, no problem, how does async, await work? Don't know that, why do we need WebWorkers? What happens with an infinite loop? How do events work? etc.

There are plenty of ways to see how this person came into contact with the event loop concept, whether in theory or in practice.

Meh, I'm with previous commenter. I know what the event loop means, that JS is single threaded, and what setTimeout is supposed to do under normal circumstances. I consider the question stupid, moreover your answer to it is likely incorrect, because it depends on the implementation. I bet Node.js never interrupts the loop for example (and I never even done Node.js, it would just be a sane thing to do).

And yeah, you might agree on Node behaving differently, but that just proves the question is very bad. Even with "in browser" clause the answer can change tomorrow for all we know.

It is like asking about undefined C++ behavior in an intentionally very bad example.

Then please enlighten me what frontend questions you ask in your interviews.

By the way, only 1 out of 10 frontend developers can answer what the event loop is, according to my experience.

I am not saying understanding event loop is not mandatory for senior JS devs. It is just that your question is really obscure. Why not just ask what an event loop is and what are the consequences of that execution model?

Some JavaScript developers know the theory, but not all of them. At least you should know how it practically works.

So when you ask "What is the JavaScript event loop?", most will stare at you not knowing what it is. So then I jump to the practical side. They at least should have worked with either setTimeout, async/await and/or events. So then you start asking for practical consequences of the event loop, such as what happens with an infinite loop after setTimeout or await, or during handling of an event. That is a real practical example that they should know. If you don't then you don't know neither theory nor practice.

Practice can change tomorrow.

I agree that a senior should know this, but at the same time I've never run into a problem at work that required me to start using web workers because what I was doing was so CPU intensive. Most professional Javascript development is pretty run of the mill.

> I agree that a senior should know this, but at the same time I've never run into a problem at work that required me to start using web workers because what I was doing was so CPU intensive.

A few weeks ago I interviewed a front-end developer who said that in his current job he rolled into production some code that blocked the UI for nearly 1 minute, and that problem was only noticed in production because during testing they didn't used realistic data.

He then said that his approach to solve the problem was to rewrite everything from scratch using a faster framework.

Unloading the blocking tasks to web workers wasn't even in his universe of potential alternatives.

Suffice to say, he was not hired.

If you're applying for a front-end position and are oblivious to basic GUI principles, such as how not to block the UI, then you might not be lucky.