An interesting corner-case of the JS execution model, to be sure, but as far as sins against JS go I'd argue that the original one is wanting to use setTimeout at all, especially with delay values below human-perceptible limits. If you need to use setTimeout to order execution like you have here, wouldn't you be better off using Promises (or continuation-passing, if you want to be completely cross-browser without a bunch of library cruft)?

Aurelia has a nice abstraction that uses mutation observer if available falling back to setTimeout and handling edge cases in different browsers.

https://github.com/aurelia/task-queue/blob/master/src/index.js

I have to second DDB's comment here. Your age might be showing a little too much with this one. Can't you just wrap the function in question in a promise instead of fiddling with timeouts? I can't imagine an implementation like this would be especially easy to maintain, given all of the arbitrary timeout values that need to be in place.

This kind of reminds me of an interview question I was given as a candidate. I was told to imagine that Microsoft's Int32.Parse function had a bug in it, and to implement it in my own way. A fun little exercise, sure, but what had I really demonstrated at the end of it? Knowledge of ASCII character codes and some basic loop arithmetic, that's it. I really can't see how that's valuable in a candidate (they were impressed regardless).

Maybe you should change that question to the following:

setTimeout2(() => console.log('a'), 0);
console.log('b');
setTimeout2(() => console.log('d'), -1);
console.log('c');  

Otherwise, the question could be easily "solved" with this method:

function setTimeout2(func, delay) {
    if (delay < 0) {
        func();
        return;
    }

    setTimeout(func, delay);
}

And that's probably not what you wanted the candidate to write :)

Without additional restrictions the simplest I can come up with is function setTimeout2(f, t) { setTimeout(f, (t+1)*100);} It is not an timeout anymore, but technically satisfies the request :)

Oren, indeed it is not general. Moreover, it is not reliable too: if browser thread running this JS will be preempted in the middle between two calls to setTimeout2 written in this fashion - it won't work, so results depend on a race. But to know all that means a candidate understands JS runtime quirks quite clear. Gives more topics to talk about than keeping sorted queue of callbacks as well.

Oren, true. But in case function setTimeout2(f, t) { setTimeout(f, (t+1)*100);} it relies on the fact that your original function finishes execution before timeout expires on 'a' call.

setTimeout2(() => console.log('a'), 0); // effectively scheduled to 100ms from now console.log('b'); // logs b console.log('c'); // logs c setTimeout2(() => console.log('d'), -1); // effectively scheduled 'now'

In order to have 'a' and 'd' reversed - 'a' should not be ready for execution by the time this snippet finishes. Otherwise, both 'a' and 'd' are ready and it will take 'a' first the same as if were normal setTimeouts.

To illustrate, we can add horrendous code to simulate "browser thread is busy/preempted":

function sleep(miliseconds) { var currentTime = new Date().getTime(); while (currentTime + miliseconds >= new Date().getTime()) {} }

If put between 'b' and 'c' - the code with my implementation will show 'bcad' instead of 'bcda' that is shown without it. Here I have a code snipped to demonstrate: https://www.w3schools.com/code/tryit.asp?filename=FVBODA5I2URJ

Why can't you do:

function setTimeout2(f, n) { setTimeout(f, n * 1000 + 1000); }

Depending on the resolution of JavaScript's timer, change the ratio and offset to a number large enough to make sure that the call with zero waits longer than the call with -1.

My problem with this question is it would leave a bad impression

• setTimeout is not super common anymore
• over insistence of passing a negative value to setTimeout just doesn't make much sense
• whether they can or can't answer this question wouldn't actually tell me much about their web development skills. If they can answer this, I'd be a little unsure what I just learnt, and that I would be better served by a more relevant example that is actually related to web dev, for instance I'd be more interested in knowing if they can handle the nuances of async / promises

This is the exact reply I'm actually expecting, I just really don't buy it. If you are happy with the question that's fine, I'm just saying, to me, it seems really bogus. It is not close to anything a modern web developer would actually have to program, and I disagree it shows whether they can program or not. Your answer is a classic example of awful hacks people have done in the past on the frontend. To me, it says you are going to do awful things with js to solve a problem that should never have been a problem in the first place