tezvyn:

Instrument a first-full-song activation event

AI-drafted, machine-checkedSource: interviewbeginner
WHAT IT TESTS

precise event definition and reliable instrumentation.

OUTLINE

define 'full song' server-side, emit a typed event with user, song, and context, dedupe the first-time flag.

WHAT THIS TESTS This checks whether you can translate a product definition into a precise, trustworthy event. Activation here is the user's first full song, so the trap is sloppy definitions: a play click is not a listen, and a client-only counter is not reliable. The interviewer wants clear semantics, a sensible payload, and dedup logic.

A GOOD ANSWER COVERS First, pin down completion. A full song means playback position reached at or near the track's end, accounting for users who let the last second fade. The frontend reports progress, but the backend validates against the known track duration and the actual bytes or segments streamed, so a fabricated client event is caught. The event payload includes user_id, song_id, track_duration, listened_duration, event_timestamp, client platform and version, and a session_id. Activation is the first time this completion event occurs for a user, so the backend checks and sets a persisted activated_at flag, emitting the activation event exactly once. Send events over a reliable channel with retries and idempotency keys so dropped or duplicated network calls do not double-count.

COMMON WRONG ANSWERS Firing activation on play-start or on reaching some arbitrary few seconds. Trusting the client to declare completion with no server validation. Emitting the activation event on every full listen rather than only the first. Ignoring idempotency, so retries inflate counts. Forgetting context fields needed for later segmentation.

LIKELY FOLLOW-UPS How do you handle offline playback that syncs later? Buffer events locally with timestamps and idempotency keys. How do you treat a song that is ninety-five percent played? Define a completion threshold and document it. How do you prevent replay abuse from inflating activation?

ONE CONCRETE EXAMPLE A user streams a three-minute track. The player reports progress every few seconds; when position crosses the completion threshold near the end, it sends a song_completed event with the payload above and an idempotency key. The backend confirms streamed segments match, sees no prior activated_at for this user, sets it, and emits user_activated once. A later replay of the same song sends song_completed again but does not re-trigger activation.

Read the original → amplitude.com

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.