Design a Music Player with Queue, Loop, and Shuffle

Read the full interview experience this question came from →

Quick Overview

Design music-player objects and state transitions for play, pause, queue, looping, and shuffle, with stubbed audio and deterministic tests.

Design a Music Player with Queue, Loop, and Shuffle

Company: Atlassian

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

Design the objects and interfaces for a music player with `play`, `pause`, and `next` operations. Add a play queue, playlist looping, and shuffle. Explain the state transitions and how the player coordinates these features with an audio backend whose operations can be stubbed. ### Constraints & Assumptions - This is an object-oriented design and communication exercise. Actual audio decoding and device output are behind a stubbed interface. - Define queue precedence, end-of-playlist behavior, loop mode, and shuffle semantics explicitly; the source lists the features without fixing those policies. - Track identity must not depend on the title alone. A playlist may contain repeated tracks. - Begin with one local user and serialized commands. Network streaming and multi-device synchronization are outside the baseline. ### Clarifying Questions to Ask - Does a manually queued track play before the next playlist entry? - Does loop mean repeat the current track, repeat the playlist, or both? - Should shuffle preserve the current track and visit each remaining playlist occurrence once before repeating? - Is `play` while paused a resume, and what should `next` do while paused? ```hint Separate selection from playback The component that chooses the next track should not need to decode audio. The component that plays audio should not decide queue or shuffle policy. ``` ### What a Strong Answer Covers - Track/playlist identity, player state, queue state, and an audio-backend interface. - Explicit behavior for play, pause, next, completion callbacks, and empty inputs. - Queue, looping, and shuffle policies that do not contradict one another. - Testability through backend and randomness injection. - Safe handling of stale completion callbacks and failed track loads. ### Follow-up Questions - How would toggling shuffle midway through a playlist affect already-played and queued tracks? - How would you test the player without playing real audio or relying on nondeterministic random results?

Overview: Design music-player objects and state transitions for play, pause, queue, looping, and shuffle, with stubbed audio and deterministic tests.

Read the full Atlassian Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Atlassian
Atlassian logo
Atlassian
Sep 3, 2026
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
1
0

Design the objects and interfaces for a music player with play, pause, and next operations. Add a play queue, playlist looping, and shuffle. Explain the state transitions and how the player coordinates these features with an audio backend whose operations can be stubbed.

Constraints & Assumptions

  • This is an object-oriented design and communication exercise. Actual audio decoding and device output are behind a stubbed interface.
  • Define queue precedence, end-of-playlist behavior, loop mode, and shuffle semantics explicitly; the source lists the features without fixing those policies.
  • Track identity must not depend on the title alone. A playlist may contain repeated tracks.
  • Begin with one local user and serialized commands. Network streaming and multi-device synchronization are outside the baseline.

Clarifying Questions to Ask Guidance

  • Does a manually queued track play before the next playlist entry?
  • Does loop mean repeat the current track, repeat the playlist, or both?
  • Should shuffle preserve the current track and visit each remaining playlist occurrence once before repeating?
  • Is play while paused a resume, and what should next do while paused?

What a Strong Answer Covers Guidance

  • Track/playlist identity, player state, queue state, and an audio-backend interface.
  • Explicit behavior for play, pause, next, completion callbacks, and empty inputs.
  • Queue, looping, and shuffle policies that do not contradict one another.
  • Testability through backend and randomness injection.
  • Safe handling of stale completion callbacks and failed track loads.

Follow-up Questions Guidance

  • How would toggling shuffle midway through a playlist affect already-played and queued tracks?
  • How would you test the player without playing real audio or relying on nondeterministic random results?
Loading comments...