Design a Music Player with Queue, Loop, and Shuffle
AtlassianSoftware Engineer · Technical ScreenLast updated
Design music-player objects and state transitions for play, pause, queue, looping, and shuffle, with stubbed audio and deterministic tests.
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
playwhile paused a resume, and what shouldnextdo while paused?
Hints
Hint 1
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.
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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.