How do I practice coding and algorithm questions?

Use PracHub's coding console to write, test, and debug your solutions in Python or JavaScript. View hints, test against sample inputs, and compare with official solutions.

What difficulty level is this coding question?

This is a medium difficulty Coding & Algorithms question, commonly asked during Technical Screen rounds at Apple.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Apple during technical interviews.

Implement a debounce function | Apple Coding Question

Quick Overview

This question evaluates a candidate's ability to implement a debounce utility using runtime features such as closures, timers, and function-context preservation, testing competencies in function design, stateful behavior, and event-rate control within the Coding & Algorithms domain.

Implement a debounce function

Company: Apple

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Technical Screen

## Problem: Implement `debounce(fn, wait)` Implement a `debounce` utility function. ### Behavior Given a function `fn` and a delay `wait` (milliseconds), `debounce(fn, wait)` returns a new function `debounced` such that: - When `debounced(...args)` is called repeatedly, it postpones calling `fn` until **after** `wait` ms have elapsed since the **most recent** call. - When the timer finally expires, `fn` is invoked **once** with the **latest** arguments and the original `this` context. ### Requirements - Preserve `this` binding when invoking `fn`. - The returned function should be callable multiple times. ### Optional extensions (if time) - Support `debounced.cancel()` to cancel a pending invocation. - Support `debounced.flush()` to immediately run the pending invocation (if any).

Quick Answer: This question evaluates a candidate's ability to implement a debounce utility using runtime features such as closures, timers, and function-context preservation, testing competencies in function design, stateful behavior, and event-rate control within the Coding & Algorithms domain.

Part 1: Simulate Basic Debounce(fn, wait)

A debounced function delays execution until `wait` milliseconds have passed since the most recent call. You are given a chronological list of calls made to a debounced function. Each call is represented as `(time, context, value)`, where: - `time` is the call time in milliseconds - `context` represents the original `this` binding - `value` represents the latest argument payload Simulate the behavior of `debounce(fn, wait)`. Rules: - A call at time `t` schedules an invocation for `t + wait`. - If another call happens before that scheduled time, the old pending invocation is discarded and replaced by the new one. - When the function finally runs, it uses the latest `context` and `value`. - If a call happens at the exact same time a pending invocation is scheduled to fire, process the pending invocation first, then process the new call. - After all events are processed, any remaining pending invocation should also be included. Return every actual invocation as `(invoke_time, context, value)`.

Constraints

0 <= len(events) <= 200000
0 <= wait <= 10^9
Event times are integers in nondecreasing order.
If multiple calls share the same time, they appear in the exact order they occur.

Examples

Input: ([(0, 'A', 1), (2, 'B', 2), (7, 'C', 3)], 5)

Expected Output: [(7, 'B', 2), (12, 'C', 3)]

Explanation: The call at time 2 replaces the earlier pending call. At time 7, the pending `(7, 'B', 2)` fires before the new call at time 7 is processed.

Input: ([(1, 'x', 10), (10, 'y', 20)], 3)

Expected Output: [(4, 'x', 10), (13, 'y', 20)]

Explanation: The calls are far enough apart that both invocations happen.

Input: ([], 4)

Expected Output: []

Explanation: No calls means no invocations.

Input: ([(5, 'a', 1), (5, 'b', 2), (6, 'c', 3)], 0)

Expected Output: [(5, 'a', 1), (5, 'b', 2), (6, 'c', 3)]

Explanation: With `wait = 0`, each pending invocation becomes due immediately and fires before the next same-time event is processed.

Hints

Keep only one pending invocation at any moment: its fire time, context, and value.
Before handling a new call at time `t`, check whether the previous pending invocation should fire first.

Part 2: Simulate Debounce with cancel()

Now extend the debounce simulation to support `cancel()`. You are given a chronological list of events for a debounced function. Each event is one of: - `('call', time, context, value)` - `('cancel', time)` Behavior: - A `call` at time `t` schedules an invocation for `t + wait`. - A later `call` before that time replaces the pending invocation. - `cancel()` removes any pending invocation that has not fired yet. - If an event happens at the exact time a pending invocation is scheduled to fire, the pending invocation fires first, then the event is processed. - After all events are processed, any remaining pending invocation should be included. Return every actual invocation as `(invoke_time, context, value)`.

Constraints

0 <= len(events) <= 200000
0 <= wait <= 10^9
Event times are integers in nondecreasing order.
If multiple events share the same time, they appear in the exact order they occur.

Examples

Input: ([('call', 0, 'A', 1), ('call', 2, 'B', 2), ('cancel', 4), ('call', 10, 'C', 3)], 5)

Expected Output: [(15, 'C', 3)]

Explanation: The pending call from time 2 is cancelled at time 4. Only the later call at time 10 survives.

Input: ([('cancel', 1), ('call', 3, 'X', 9)], 2)

Expected Output: [(5, 'X', 9)]

Explanation: Cancelling with no pending invocation does nothing.

Input: ([('call', 0, 'A', 1), ('cancel', 5)], 5)

Expected Output: [(5, 'A', 1)]

Explanation: The pending invocation is due at time 5, so it fires before the cancel event at the same time is processed.

Input: ([], 3)

Expected Output: []

Explanation: No events means no invocations.

Hints

Reuse the basic debounce state: a single pending invocation tuple is enough.
Handle any due invocation before processing the current event, especially for exact-time `cancel` events.

Part 3: Simulate Debounce with flush()

Now extend the debounce simulation to support `flush()`. You are given a chronological list of events for a debounced function. Each event is one of: - `('call', time, context, value)` - `('flush', time)` Behavior: - A `call` at time `t` schedules an invocation for `t + wait`. - A later `call` before that time replaces the pending invocation. - `flush()` immediately invokes the pending call, if one exists and has not already fired. - The flushed invocation uses the latest `context` and `value`, and its invocation time becomes the flush time. - If an event happens at the exact time a pending invocation is scheduled to fire, the scheduled invocation fires first, then the event is processed. - After all events are processed, any remaining pending invocation should be included. Return every actual invocation as `(invoke_time, context, value)`.

Constraints

0 <= len(events) <= 200000
0 <= wait <= 10^9
Event times are integers in nondecreasing order.
If multiple events share the same time, they appear in the exact order they occur.

Examples

Input: ([('call', 0, 'A', 1), ('call', 2, 'B', 2), ('flush', 4), ('call', 10, 'C', 3)], 5)

Expected Output: [(4, 'B', 2), (15, 'C', 3)]

Explanation: The latest pending call is flushed early at time 4. The later call at time 10 fires normally at time 15.

Input: ([('flush', 1), ('call', 3, 'X', 9)], 2)

Expected Output: [(5, 'X', 9)]

Explanation: Flushing when nothing is pending does nothing.

Input: ([('call', 0, 'A', 1), ('flush', 5)], 5)

Expected Output: [(5, 'A', 1)]

Explanation: The scheduled invocation is already due at time 5, so it fires before the flush event is processed.

Input: ([('call', 0, 'Z', 7), ('flush', 0)], 3)

Expected Output: [(0, 'Z', 7)]

Explanation: A flush can force the pending invocation to run immediately, even at the same timestamp as the call.

Hints

A flush event is only meaningful if there is still a pending invocation after processing all due timers up to that time.
For a `flush` event at time `t`, append `(t, latest_context, latest_value)` and clear the pending state.

Quick Overview