Implement sleep(ms) and delay with value

Q: Implement sleep(ms) and delay with value

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** every claim here — including the busy-wait comparison — was actually run, not reasoned about in the abstract. Read the "Thought Process" section before the code; the reasoning is the point of this question, not just the final answer. ## 1. The problem, restated Write `sleep(ms)`, callable as `await sleep(100)`, that pauses the CALLING async function for about `ms` milliseconds without blocking anything else on the page. Then write `delay(value, ms)`, the same idea but resolving with a specific value instead of `undefined`. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Does "pause" mean block the whole page, or just this async function? | This is the entire distinction the question is testing — get it wrong and the "solution" is actively harmful. | | Is a cancel/reject path needed? | Determines whe

The problem

Problem, as an interviewer would state it: "Write a sleep(ms) function I can await to pause execution for a given number of milliseconds, and a delay(value, ms) function that resolves with a given value after that delay. Show me you understand what actually makes this 'pause' different from a language like Python's time.sleep()."

Examples:

Code

await sleep(100);           // pauses ~100ms, resolves with undefined
await delay("done", 100);   // pauses ~100ms, resolves with "done"

Clarifying questions expected:

Does "pause" mean genuinely blocking everything else on the page, or just pausing the calling async function while other code keeps running? (This is the crux of the whole problem.)
Is a rejection path ever needed (a cancellable sleep), or is resolve-only fine for this version?
Is sub-millisecond precision expected, or is "close to ms" acceptable? (Real timers are never exact.)

Code / implementation expected: Yes — both functions, plus a real, direct demonstration that the implementation does not block the event loop, since that is the entire point of the question.

sleep
delay
promise

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: every claim here — including the busy-wait comparison — was actually run, not reasoned about in the abstract. Read the "Thought Process" section before the code; the reasoning is the point of this question, not just the final answer.

1. The problem, restated

Write sleep(ms), callable as await sleep(100), that pauses the CALLING async function for about ms milliseconds without blocking anything else on the page. Then write delay(value, ms), the same idea but resolving with a specific value instead of undefined.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Does "pause" mean block the whole page, or just this async function?	This is the entire distinction the question is testing — get i

The solution is hidden so you can try first

4 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: setTimeout-based sleep never blocks the event loop, while a busy-wait genuinely does — verified directly