Recommended preparation

Editorial practice groupings, not verified official interview questions or endorsements.

Public Spotify prep guide

Spotify Frontend Interview Questions

Prepare with seven practice prompts shaped by public web engineer accounts from 2021 and 2022, more recent Glassdoor previews and the official Life at Spotify pages: a search form that fetches from an API and renders into the DOM without a framework, an image carousel, a traffic light, an event-loop output question, a closure that limits calls, a system-design round that includes the backend, and the algorithms round.

This guide uses public, self-reported interview accounts and the official Spotify hiring pages to create realistic constraints. It does not claim access to private interview material, a fixed interview format, or the stack of every Spotify team.

7 practice promptsHTML, JavaScript, DOM, system designFull practice set requires Premium

Study priorities

Prepare for product judgment, not Spotify trivia

The public accounts of the web loop describe a recruiter chat, then a final round of four interviews: data structures and algorithms, a web practical, system design, and values. The web practical is where frontend preparation pays off, and it is framework-free. One candidate who received an offer built a form, fetched data from the Spotify API based on the input and rendered the result into the DOM; another, who joined Spotify, described building a feature with JavaScript, HTML and CSS and no debugging round. The first candidate wrote afterwards that the interviews needed a good grasp of HTML and JavaScript fundamentals, tested no arcane concepts and, for them, needed no CSS.

Public previews of Glassdoor web engineer reports add JavaScript fundamentals under questioning: the output order of code that mixes setTimeout and promise chains, a closure that limits how many times a function can run, event delegation, memoization and the CSS box model, and a traffic light built in plain HTML, CSS and JavaScript. Each prompt below starts with the clarifying questions a strong candidate asks, then the behaviours a strong answer covers, then the miss that usually ends the round.

Role lenses

Two product contexts for practising transferable frontend judgment

These are preparation lenses based on the open Spotify web and full-stack postings in October 2026, not claimed team assignments. Choose the lens closest to the role and keep the reasoning framework-neutral.

Internal business tools

The Subscriptions mission builds internal products that let teams launch, configure and manage Premium offers through guided workflows, and the Platform team builds Groove for planning and dependency tracking, both with React and TypeScript.

Practice focus: Multi-step forms with validation and safe defaults, permissions and audit trails, optimistic edits with rollback, GraphQL contracts, and keyboard-first data entry.

Internationalisation platform

The Stockholm Platform posting builds the localisation workflows and global rollouts behind more than 180 markets.

Practice focus: Locale-aware formatting with Intl, right-to-left layout, text expansion and truncation, pluralisation, and feature rollout by market.

Representative practice prompts

Seven Spotify frontend interview practice questions

For each prompt, clarify the contract, explain ownership and trade-offs, implement or diagram the smallest credible slice, and test the failure cases. Prompts modelled on a report read in full link to it; the others draw on the Glassdoor previews listed under the sources.

Prompt 1

Build a search form that fetches from an API and renders the results into the DOM, without a framework

Build a form whose input drives a request to a public API, then render the results into the page with plain DOM APIs: show progress while the request runs, show an empty and an error state, and make sure a slow earlier response never overwrites a newer one.

Practice version modelled on a reported round: Public report: Spotify web engineer final round with an offer, April 2022

What this measures

HTML and JavaScript fundamentals without a framework, fetch and error handling, safe DOM rendering, request ordering, and accessible form behaviour.

Clarify first

  • Confirm whether the request runs on submit or on every input, and whether a debounce is expected.
  • Confirm the response shape, the empty case and how the request is authenticated, if at all.

Strong answer should cover

  • Use a real form element with a label and handle submit, so Enter works and keyboard and screen-reader behaviour come for free.
  • Build result rows with createElement and textContent rather than innerHTML, so API data cannot inject markup.
  • Keep one status at a time (idle, loading, results, empty, error) and render only that branch.
  • Abort the previous request or tag each request with an id, and ignore any response that is not the latest.

Common miss: Concatenating API strings into innerHTML, and letting a slow first response replace the results of a later query.

Practice cancelling stale requests (free)

Prompt 3

Build a traffic light with plain HTML, CSS and JavaScript

Render three lights and cycle them on a timer with configurable durations, and add start and stop controls that leave no timer running.

What this measures

Timers and cleanup, a small state machine in plain JavaScript, CSS for visual states, and how you reason about drift and restarts.

Clarify first

  • Confirm the sequence and the duration of each light, and whether durations can change while it runs.
  • Confirm which controls exist, such as start, stop or a pedestrian button, and what they do mid-cycle.

Strong answer should cover

  • Model the light as an ordered list of states with durations and one function that moves to the next state.
  • Schedule each transition with a single timer and clear it on stop, so a restart never stacks timers.
  • Drive the visuals from a class or a data attribute on the container, so CSS owns the colours.
  • Mention drift: chained setTimeout calls are fine for a demo, and a timestamp check is the fix when accuracy matters.

Common miss: Three independent setInterval calls that drift apart and keep running after stop.

Practice timed sequences with a sleep helper (free)

Prompt 4

Predict the output order of code that mixes setTimeout and promise chains

Read a snippet that combines synchronous logs, setTimeout, a setTimeout inside a promise and a chain of promises, then state the exact order of the output and explain why.

What this measures

A precise model of the event loop, the call stack, the microtask queue and task scheduling, and the ability to explain it step by step.

Clarify first

  • Confirm the runtime, browser or Node, since some ordering details differ between them.
  • Read the whole snippet once before answering and note every promise that is already resolved.

Strong answer should cover

  • Run the synchronous code first and write down each log in order.
  • Drain the microtask queue, promise callbacks in the order they were queued, before any timer runs.
  • Treat each setTimeout callback as a new task; promise callbacks it queues run before the next timer.
  • Say the rule out loud as you go, so a slip on one line does not hide the model.

Common miss: Assuming setTimeout with zero delay runs before a resolved promise callback.

Practice nested microtask output (free)

Prompt 5

Write a closure that limits how many times a function can run

Implement a wrapper that takes a function and a limit, calls the function normally up to the limit, and returns undefined for every call after that, without global state.

What this measures

Closures, higher-order functions, forwarding this and the arguments, and edge cases around the limit.

Clarify first

  • Confirm what calls after the limit return: undefined, the last result or an error.
  • Confirm whether this and the arguments must be forwarded, and whether the limit can be zero.

Strong answer should cover

  • Keep the call count inside the closure, not on the function or in a module variable.
  • Forward this and the arguments with apply, and return the result of each allowed call.
  • Handle a limit of zero and negative limits explicitly.
  • Note that once is the limit-one case and that a reset function is a small extension.

Common miss: A counter in an outer variable shared by every wrapped function, so wrapping a second function breaks the first.

Practice once, the limit-one case (free)

Prompt 6

Design a product end to end in the system-design round, backend included

Take a product-style prompt from requirements to architecture: the client, the API, the data store and the pieces that keep it fast and available, then defend the trade-offs.

Practice version modelled on a reported round: Public report: Spotify web engineer final round with an offer, April 2022

What this measures

Requirements gathering, how the layers interact, storage and consistency choices, and scaling tools such as load balancing, queues and caches, the topics one web engineer account lists for this round.

Clarify first

  • Confirm the core use cases, the expected scale and which parts the interviewer wants in depth.
  • Confirm the consistency needs, for example whether users must see their own writes immediately.

Strong answer should cover

  • Start from requirements and a rough capacity estimate, then sketch the client, the API, the services and the storage.
  • Choose the data store by access pattern and state what you give up under a partition, using the CAP framing where it helps.
  • Add load balancing, a queue for slow work and caches at the client, the edge and the service, each with an invalidation rule.
  • Close with the frontend view: loading states, pagination and what the client does when a dependency fails.

Common miss: Designing only the browser layer when the interviewer expected the database, queues and caches as well.

Read the system design blueprint on architecture (free)

Prompt 7

Clear the data structures and algorithms round

Solve one or two LeetCode-style problems in CoderPad, explain the complexity as you go, and keep the code readable enough to extend when the interviewer adds a follow-up.

Practice version modelled on a reported round: Public report: Spotify web engineer interview thread, 2021 to 2022

What this measures

Clean fundamentals, choosing a data structure for the access pattern, edge cases, and communication while coding.

Clarify first

  • Confirm the input size and the constraints before choosing an approach.
  • Confirm whether the interviewer wants a working solution first or the optimal one straight away.

Strong answer should cover

  • Start with a correct solution that passes the examples, then improve it if the constraints demand it.
  • Use maps, sets and stacks where they remove nested loops, and state the complexity.
  • Test empty input, one element and duplicates aloud before declaring the answer done.
  • Keep names and helpers clean, since the same interviewer may ask for an extension.

Common miss: Jumping to an optimised solution before a working one exists, then running out of time.

Read the data structures and algorithms blueprint for frontend loops

Public mini walkthrough

Scope the fetch-to-DOM search form before writing the first line

Treat this as a representative exercise, not a description of the reported one. Work from the contract toward the rendering, and say each decision out loud.

  1. Pin the trigger

    Submit or every keystroke; if every keystroke, agree on a debounce and on what an empty query shows.

  2. Choose one status

    Idle, loading, results, empty or error, held in one variable, with one render function that switches on it.

  3. Render safely

    createElement and textContent for every value that comes from the API, and a single container that is replaced on each render.

  4. Guard the request order

    Abort the previous request or compare a request id, so only the latest response can reach the screen.

  5. Keep it accessible

    A labelled input inside a form, a real submit button, and a polite live region that announces the result count.

Actionable preparation

A 7-day Spotify frontend interview preparation plan

Every day ends with code, a test, a design artifact, or a question you can use in the real process.

  1. Day 1

    DOM fundamentals without a framework: forms, events, createElement, textContent and event delegation.

    Deliverable: A search form that renders rows safely from a fixture.

  2. Day 2

    Fetch and request order: loading, empty and error states, and aborting the previous request.

    Deliverable: The same form against a public API with a stale-response guard.

  3. Day 3

    UI components in plain JavaScript: an image carousel and a traffic light, each with cleanup and keyboard access.

    Deliverable: Two components that pass a keyboard-only check.

  4. Day 4

    JavaScript fundamentals under questioning: event-loop output order, closures, this, memoization and the CSS box model.

    Deliverable: Five snippets with the written output and the rule behind each.

  5. Day 5

    Algorithms: two LeetCode-style problems a day under CoderPad conditions, with the complexity stated.

    Deliverable: Four solved problems with their edge cases listed.

  6. Day 6

    System design end to end: requirements, the API, the data store, caches, queues and the client view.

    Deliverable: A one-page design with the trade-offs you would defend.

  7. Day 7

    Values and a mock loop: stories for ownership, adaptability, collaboration and drive, then one narrated round of each type.

    Deliverable: A list of questions for the recruiter about the web round, the tools and the timing.

Preparation FAQ

Common Spotify frontend interview preparation questions

Are these the real Spotify questions?

No. They are FrontendAtlas practice versions modelled on round types described in public, self-reported accounts and on the official Life at Spotify pages. The wording, the data and the test cases are ours.

Do I need React for the web round?

The accounts used here describe HTML and JavaScript fundamentals and building a feature with JavaScript, HTML and CSS rather than a framework exercise, and one candidate needed no CSS at all. The current postings list React and TypeScript for the job itself, so prepare plain DOM work for the round and React for the conversation about your experience.

Is there a take-home?

The official pages do not mention one, and none of the web accounts used here describes one. The official pages name CoderPad for technical work and Mural for diagrams.

Do the London and Stockholm teams interview the same way?

The detailed web accounts do not state a European office. A 2019 thread has a commenter saying the process differs by country, and a 2022 Stockholm Android account describes a final of four interviews with a second interviewer shadowing, the same shape the official page describes. Confirm the format for your office with the recruiter.

What does the values interview look for?

The official interview page names values alignment, ownership and pride in what you deliver, adaptability, collaboration and drive, and asks candidates to make their answers on those qualities easy to see. Prepare one story for each.

Free public practice

Build the underlying skills with free practice

These public pages cover the DOM, request-order, event-loop, closure, CSS and design skills used by the practice prompts. They are supporting drills, not claimed Spotify questions.

Take latest: abort previous requestsThe request-order guard behind the search form.Fetch and render a list with loading, error and empty statesThe same request states, in React.Nested microtask outputThe output-order reasoning the event-loop question checks.OnceA closure that limits a function to one call.ClosuresLexical scope and the state a wrapper keeps.Event delegationOne listener for many rows or controls.MemoizationCaching results and choosing the cache key.The CSS box modelContent, padding, border and margin, and box-sizing.System design blueprint: architectureHow to lay out the client, the API and the services.Behavioural storiesA structure for the values interview.

Public interview reports and official context

Sources and evidence limits

These links support the public context used by the guide. Their notes state what each source can and cannot establish about preparation.

Glassdoor: Spotify web engineer interview reports

Public previews mention an output-order question mixing setTimeout and promise chains, a closure that limits how many times a function can run, JavaScript and CSS basics, and a traffic light in plain HTML, CSS and JavaScript. The full reports could not be read by our tools, so nothing else from them is used.

Medium: Getting Interviewed at Spotify, February 2022

A Stockholm Android loop: four one-hour final interviews (algorithms, system design, pair programming in your own IDE, values), each with a second interviewer. It shows the Stockholm final shape for mobile, not the web practical.

Life at Spotify: Interview

Official interview stages, the lead-and-shadow format, CoderPad and Mural for technical work, and the qualities assessed. It names no interview questions.

Spotify jobs on Lever

Official open roles. In October 2026 they include a senior web engineer in London and senior full-stack engineers in London, Stockholm and New York; used for product and stack context only.

Full company practice

Continue with the full Spotify practice set

This public guide is complete enough to plan a focused week. Premium unlocks the company-tagged Spotify set, including the image slider and the debounced search, and the wider premium library of coding, concept and system-design practice.

Unlock the full Spotify practice set