Which video event signals completion, and how do you track playback time?

Tests HTMLMediaElement events and UI performance. Answer: use ended for replay; read currentTime on timeupdate but throttle updates or use requestAnimationFrame. Red flag: setInterval polling, currentTime===duration checks, or unthrottled state writes.
WHAT THIS TESTS: This question probes two separate HTMLMediaElement API concepts plus a hidden performance dimension. The interviewer wants to know if you understand native media lifecycle events versus manual polling, and whether you recognize that timeupdate is a high-frequency firehose that can wreck rendering performance if you update framework state or the DOM on every tick.
A GOOD ANSWER COVERS: First, the ended event is the correct signal that playback has finished. You should add an event listener for ended on the video element and use that to toggle the replay button visibility. Do not rely on comparing currentTime to duration because container metadata and floating point values can mismatch by fractions of a second. Second, for the running timestamp, listen to the timeupdate event and read video.currentTime, which gives elapsed seconds as a floating point number. Third, and this is what separates senior candidates, you must address update frequency. The timeupdate event does not fire at a fixed interval; browsers may dispatch it anywhere from roughly 4 Hz to 66 Hz depending on implementation and system load. Updating React state or writing to innerText on every callback can cause layout thrashing or unnecessary re-renders. A solid answer proposes throttling the UI update to 100-250 ms for a coarse label, or using requestAnimationFrame to read currentTime from a ref and manually updating a text node for a smooth counter. Fourth, formatting the raw seconds into a human-readable MM:SS string is expected.
COMMON WRONG ANSWERS: Using onfinish, oncomplete, onstop, or load instead of ended. Polling with setInterval every second instead of using timeupdate. Checking if currentTime exactly equals duration to detect the end, which is brittle. Updating unthrottled React state inside the timeupdate handler with no mention of performance cost. Confusing the paused state with ended, which means the replay button might disappear if the user simply pauses.
LIKELY FOLLOW-UPS: How does your approach change if the video has the loop attribute enabled? The ended event will not fire. How would you build a custom seek bar? Combine timeupdate with pointer events on a progress rail, using currentTime and duration. What happens if the user scrubs while the video is playing? You may want to suppress timeupdate-driven UI changes during seeking to avoid jitter.
ONE CONCRETE EXAMPLE: Consider a two-minute video. In Chrome, timeupdate might fire roughly four to ten times per second. If you call setState with the currentTime on every event in React, you schedule four to ten commits per second. A senior implementation stores the video element in a ref, listens to timeupdate, and inside a throttled callback updates a local state or DOM text node at most four times per second. For a butter-smooth progress ring, you would instead use requestAnimationFrame to read ref.current.currentTime and compute the fractional progress against duration, writing directly to an SVG stroke-dashoffset without touching React state at all.
Read the original → developer.mozilla.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.