I pay you for a day to pair program with us in our codebase.
Ask HN: “Expert Level” JavaScript questions?
41–50 of 54 posts
Re: Ask HN: “Expert Level” JavaScript questions?
#42Earlier quoted context omitted.
I see. I'll remember this example for when someone asks why you need types.
this is more than just types though. Typescript, even in strict mode, will still allow this! You need strict function arity/signature checking of some kind, which a dynamically typed language could have, and a statically typed language could lack.
If a language can't detect the difference between a function a => f(a) and a function (a,b) => f(a,b) then I would consider it very weakly typed indeed. Dynamic vs static isn't really the issue, Python will also complain if you call a function with the wrong number of arguments.
Then again I suppose that you could recreate JavaScripts behaviour even in the fairly strongly typed C# if you wanted to, by defining two overloaded versions of Map as follows:
IEnumerable Map(this IEnumerable list, Func f)
IEnumerable Map(this IEnumerable list, Func f)
Re: Ask HN: “Expert Level” JavaScript questions?
#43There 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 prob…
can someone explain why setTimeout(func, 0); works?
setTimeout 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.
Re: Ask HN: “Expert Level” JavaScript questions?
#44There are some weird corners of JavaScript that I went years without knowing. Did you know object literals support getter and setter methods[1]? As other commenters will point out, such quirks are as easy to look up as they are irrelevant to actual software development. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... "Defining getters and setters"
God, I used to go nuts with defineProperty and such back in the day. Kind of a bummer that it's even easier to do with ES6, cause that code was usually bad news.
Re: Ask HN: “Expert Level” JavaScript questions?
#45There 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 prob…
can someone explain why setTimeout(func, 0); works?
1) 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.
Re: Ask HN: “Expert Level” JavaScript questions?
#46There 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 prob…
can someone explain why setTimeout(func, 0); works?
I 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"
Re: Ask HN: “Expert Level” JavaScript questions?
#47A good interviewer will start at a high level and drill down into what you're experienced with, rather than pick an obscure topic and assume you've done your homework. For example, they might ask for a hard problem you've recently solved in your last company. If you say something related to code splitting, you can expect he'll drill down more specifically into webpack, dependency cycles, etc. If you say something rel…
As an interviewer, you don't even exactly have to be an expert. Maybe you have no clue what .bind does. But you will learn a ton about the candidate by listening to them teach you about it.
My favorite interviews (both as the interviewer and interviewee) are the ones where I end up learning a lot from the other person. I love when a candidate mentions some technology I'm not familiar with, and then I get to make them teach me all about it.
Re: Ask HN: “Expert Level” JavaScript questions?
#48Good lord OP don't rule yourself out before someone else does. Just apply. You need to apply to go on at least 4-5 interviews (and bomb some of them) before you get a hang of it anyway.
Re: Ask HN: “Expert Level” JavaScript questions?
#49[deleted]
Re: Ask HN: “Expert Level” JavaScript questions?
#50Explain why ['1','1','1'].map(parseInt) returns [1, NaN, 1] but ['1','1','1'].map(n => parseInt(n)) returns [1, 1, 1].
Try this ['1','1','1'].map(Number).
That's just about language specifics, not a question for seniors in my opinion.