> didn't know what happens when setTimeout() is followed by an infinite loop

I'm not some JS guru but I've done a few and I'm wondering why would I need to know this? To me this looks like the type of question that is there specifically because people answer it wrong, they know they answer it wrong and you know they know they answer it wrong so it makes them lower their demands in terms of pay rate.

I guess it's an important question because it is about the event loop.

Lots of weird things (bugs) can happen when you don't understand how the event loop work. I would definitely pass a "senior" javascript dev that don't know/understand the concept.

Exactly this.

A senior should know that JavaScript runs single threaded with an event loop, and therefore doing heavy calculations will block your user interactions.

If you don't know this, you also won't know when to use WebWorkers etc.

Juniors can learn, seniors should be the ones teaching them. Seniors should define the architecture of your solution, and solve weird problems. You cannot do this without proper in-depth knowledge.

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.

These are examples of indicators that, taken together, helps determine how in-depth your knowledge is. I imagine that if you work with JS on a more than surface level, you'd eventually be curious about or be forced to understand how things actually work to be able to precisely control your program outcomes.

It could be very important. Like the difference between something running at the right time or not.

There's a video of a talk I gave floating around the internet somewhere a year or two after Node.js came out where I talk about Node, the Event Loop, and how much I liked JS. Perhaps they saw it and were like "ew!"

Interviewed a guy who wrote a JavaScript book.

He Had no idea how to do anything other than write books.

> try to land a job at companies with ex-colleagues, where they are able to vouch for your technical skills.

That gets him a foot in the door alright, but I don't think it'd let him avoid those interviews?