3 ms·
There are the run-of-the mill senior level generic questions about high level knowledge and procedure. I'll ignore those since you asked specifically about expe
by hoorayimhelping 8y ago
There are the run-of-the mill senior level generic questions about high level knowledge and procedure. I'll ignore those since you asked specifically about expert level general JavaScript knowledge (not specific to node or front end):
You might see a dumb question that is just a bunch of spaghetti nonsense you'll have to unravel. Explain what this ridiculous codeblock does.
Definitely expect to see closure-based problems. You can almost bet your money on seeing an anonymous function in a loop printing an unexpected value of i:
(copy these code blocks into your browser console and test them out)
for(var i = 0; i < 10; i++) {
setTimeout(function() { console.log(i); }, 1);
}
Event loop: Explain it in words or pictures. Explain why
setTimeout(func, 0);
works.
variable scoping with var, let and const. Variable and function hoisting. Expect brain teasers exploiting the differences in const / let and var:
const x = [1, 2, 3];
for (var i = 0; i < x.length; i++) {
setTimeout(function() { console.log(i, x[i]); }, 1);
}
Scoping and binding. Function.prototype.bind(), Function.prototype.apply(), Function.prototype.call(). Maybe explain why you have to bind ES6 class methods used in callbacks.
- crimsonalucard 8y agocan someone explain why setTimeout(func, 0); works?
- pharrington 8y agosetTimeout enqueues "func" onto the event queue of the current (typically, only) thread. Thus, "func" can only run at the earliest at the beginning of the next loop iteration of the event queue consumer.
- dentemple 8y ago1) setTimeout is a Browser/Node API, not a Javascript method 2) Functions that are being returned from the Browser API are pushed to a special waiting area (called the "Callback queue"), not to the immediate Call Stack 3) Functions are only taken from the Callback queue when both the Call Stack and the other higher priority queues (like the "Job" Queue) are empty. When setTimeout is invoked, the Javascript engine sends func and 0 as arguments to the API, then moves on. The engine doesn't get blocked by setTimeout, nor does it wait to see the end result. Javascript's job is done here, and so it just moves on to the rest of the code. When the API receives setTimeout's arguments, it executes the Timer(?) method, passing to it an argument of 0 seconds. This resolves immediately. However, the API isn't allowed to send functions straight back into the Call Stack. Functions are forced into an intervening waiting area called the Callback Queue. (In the case of promises, there's also a higher priority queue that functions can be sent to instead: the "Job" or "Micro-task" Queue). Javascript's event loop will only pull functions from the Callback Queue when 1) the main thread of execution has finished all of its synchronous code, 2) the Call Stack is empty, and 3) no higher priority queues have functions left to be pulled either. Therefore, in the case of "setTimeout(func, 0)", func can be forced to wait a very long time, indeed. If the intervening synchronous code takes 10,000 ms to run, the func from setTimeout(func, 0) will, at a minimum, run at the 10,000 ms point. However, back in the days of "callback hell", this was often the reason why you'd do a "setTimeout(func, 0)" or two in the first place: to manipulate the order in which certain functions were run by the thread of execution. Since, literally, what it does it knock a function out of the normal order of events and places it into a lower priority queue.
- furgooswft13 8y agoI assume GP meant "how it works". Why it works is because the spec says so and the native code behind it makes it. Why does func() work, or 1+1? How it works is func is scheduled to execute asynchronously on the next tick of the event loop at the soonest, so if func() printed "wat" and you have console.log('huh') directly after that statement, you'd see "huh" then "wat"