Delay the Resolution of Each Promise - Solution & Explanation

Problem Overview: You receive an array of promises and a delay time t in milliseconds. Each promise should resolve with the same value as the original, but only after waiting an additional t milliseconds once the original promise resolves.

Approach 1: Promise Chaining with setTimeout (O(n) time, O(n) space)

Iterate through the input array and transform each promise using promise.then(...). Inside the then callback, wrap the resolved value in a new Promise and delay the resolution using setTimeout. The key idea is that the delay should start after the original promise resolves, not before. Each promise becomes promise.then(v => new Promise(res => setTimeout(() => res(v), t))). This approach works well because promise chaining preserves the original resolution value while inserting asynchronous delay logic.

Time complexity is O(n) since you iterate through the list once to wrap each promise. Space complexity is O(n) because a new promise object is created for every original promise. This technique relies heavily on concepts from promises and asynchronous execution.

Approach 2: Async/Await Wrapper Function (O(n) time, O(n) space)

Create a helper async function that awaits the original promise, then waits again using a timer-based promise. For example, first await promise to get the value, then await new Promise(res => setTimeout(res, t)). Finally return the resolved value. Mapping the input array to this wrapper produces the delayed promises array. The logic becomes easier to read when working with async/await, especially for developers who prefer sequential asynchronous flow over chained callbacks.

The runtime remains O(n) since each promise is processed once. Space usage is also O(n) due to the creation of new wrapped promises. The underlying mechanism still uses the JavaScript event loop and timer queue, concepts central to JavaScript asynchronous programming.

Recommended for interviews: The promise chaining approach using then and setTimeout. It directly demonstrates understanding of promise resolution flow and asynchronous control. Interviewers expect you to show that the delay happens after the promise resolves, not before. The async/await version is equally correct but often considered syntactic sugar over the same mechanism.