Spotify Machine Learning Engineer Interview Guide

Spotify's Ad Forecasting team is one of the few places where your ML models directly determine how much revenue the company books each quarter. That's a different kind of pressure than optimizing engagement metrics, because forecast errors have immediate financial consequences that sales teams feel the next morning. If you're interviewing here, you need to understand that tension between model sophistication and business accountability.

Spotify Machine Learning Engineer Role

This role sits at the intersection of production software engineering and applied ML, but what makes it distinctly Spotify is the squad ownership model. You won't hand a trained model to a platform team for deployment. You'll own the full lifecycle inside your squad, from writing the PyTorch training code to staging the GCP rollout to updating the experiment wiki with results. Success after year one means you've shipped a model that moved a squad-level metric (like ad fill rate accuracy or Home feed stream starts) and can walk your chapter through the trade-offs you made during a demo session.

A Typical Week

The research time is real, not aspirational. Spotify carves out dedicated hours for reading papers and prototyping speculative ideas like RAG-based playlist curation, and that time is protected by the squad's two-week sprint structure rather than squeezed into evenings. What might surprise you is how much of the week goes to infrastructure staging and written artifacts (design RFCs, experiment tracking wikis) rather than pure model development.

Projects & Impact Areas

Ad Forecasting is the team that appears most often in open listings, where you're predicting inventory availability and campaign pacing for Spotify's ad-supported tier of 675M+ monthly active users. The P2P Personalization team tackles a completely different problem shape: ranking and retrieval models for Home, Discover Weekly, and podcast suggestions, where the optimization target is engagement rather than revenue accuracy. Beyond those two, Trust & Safety runs anomaly detection protecting creators from fraud, and Creator Platform ML builds tools that surface audience behavior insights to artists.

Skills & What's Expected

Software engineering at expert level is the requirement most candidates underestimate. The role expects you to review Java microservices wrapping LLM inference endpoints, debug Scala Spark jobs for training data pipelines, and write production-grade Python, all in the same week. Business acumen is rated medium in the skill profile, yet the interview process includes product sense evaluation, so ignoring it is a mistake. Overrated: competitive programming tricks. Underrated: comfort with distributed data pipeline tools like Apache Beam and Dataflow, which show up constantly in day-to-day work.

Levels & Career Growth

Most external hiring happens at Engineer II and Senior, based on the volume of public listings at those levels. The jump from Senior to Staff is where careers tend to stall, because the differentiator stops being technical depth and becomes cross-squad influence: setting technical direction for a tribe, not just executing well within your own squad. Spotify published a technical career path framework that makes IC growth explicit without requiring a management switch, which is worth reading before your interview.

Work Culture

Your squad is a small cross-functional team with real decision-making autonomy, while your chapter (the ML-specific community across squads) provides career mentorship and technical growth. From what candidates and internal culture notes describe, crunch is genuinely rare and most engineers log off by 5:30-6 PM. The honest trade-off: Spotify's "loosely coupled, tightly aligned" philosophy demands strong async communication skills, so if you're not comfortable writing design docs and maintaining experiment wikis across time zones, the autonomy that makes this place attractive will feel like chaos instead.

Spotify Machine Learning Engineer Compensation

The ESO component in Spotify's equity mix is where candidates get tripped up. ESOs require you to pay a strike price to exercise, and if you leave at the wrong time, that portion of your package can evaporate. RSUs behave like cash, so when you're modeling your real comp, understand the ratio between the two and push to shift that ratio toward RSUs during negotiation.

Spotify is transparent about not always matching top-of-market FAANG compensation, but they're open to negotiation when you bring a competing written offer. The biggest lever most candidates miss: push on total equity value and the ESO-to-RSU mix, not base or signing bonus (cash bonuses are rare, signing bonuses tend to be small). Remote-friendly doesn't mean location-agnostic pay either, since remote salaries are pegged to your country of residence, which can work for or against you depending on where you live.

Spotify Machine Learning Engineer Interview Process

The pace is fast, so block your calendar accordingly. The top rejection reason isn't a failed coding problem, it's poor technical communication, particularly during the Presentation round. Spotify's panel wants proof you owned the work you're showing: why you chose Prophet over an LSTM for ad demand forecasting, what metric moved in production, and what you'd change next time.

From what candidates report, a strong System Design performance won't save you if your Product Sense answers reveal you can't connect model choices to Spotify's actual business levers (ad fill rate, Discover Weekly engagement, creator retention). Every round feeds a composite picture of you, so a "mixed" signal on product thinking or behavioral fit can outweigh clean code. Prepare as if the person evaluating your Presentation also read your System Design notes, because consistency across rounds matters more than any single standout session.

Spotify Machine Learning Engineer Interview Questions

from __future__ import annotations

from collections import defaultdict
from typing import Dict, Iterable, List, Tuple


def max_impressions_in_sliding_window(
    events: Iterable[Tuple[int, str]],
    window_ms: int,
) -> Dict[str, int]:
    """Return max number of impressions in any window of length window_ms per campaign.

    Args:
        events: Iterable of (timestamp_ms, campaign_id). Events may be out of order.
        window_ms: Window length in milliseconds, must be >= 0.

    Returns:
        Dict mapping campaign_id to maximum count of events in any inclusive window
        [t, t + window_ms].

    Complexity:
        Let n be total events and n_c events for campaign c.
        Time: sum_c O(n_c log n_c) due to sorting.
        Space: O(n) for grouping.
    """
    if window_ms < 0:
        raise ValueError("window_ms must be >= 0")

    # Group timestamps by campaign.
    by_campaign: Dict[str, List[int]] = defaultdict(list)
    for ts, cid in events:
        by_campaign[cid].append(ts)

    result: Dict[str, int] = {}

    for cid, ts_list in by_campaign.items():
        ts_list.sort()

        best = 0
        left = 0
        # Two pointers over sorted timestamps.
        for right, ts_right in enumerate(ts_list):
            # Maintain window constraint: ts_right - ts_left <= window_ms
            while ts_right - ts_list[left] > window_ms:
                left += 1
            # Current window size is [left, right].
            best = max(best, right - left + 1)

        result[cid] = best

    return result


if __name__ == "__main__":
    sample_events = [
        (1000, "c1"), (1500, "c1"), (1200, "c1"),
        (2000, "c1"), (2100, "c2"), (2200, "c2"),
        (5000, "c2"),
    ]
    print(max_impressions_in_sliding_window(sample_events, window_ms=700))
    # c1: timestamps [1000,1200,1500] fit in 700ms window => 3
    # c2: timestamps [2100,2200] fit => 2

/*
Assumptions (rename to your warehouse conventions):
- Table: ads.ad_delivery_events
- Columns:
  - event_id STRING
  - campaign_id STRING
  - event_time TIMESTAMP
  - ingestion_time TIMESTAMP
  - impressions INT64
  - cost_micros INT64
  - partition_date DATE (optional)

Goal:
- Daily delivered impressions and spend by campaign_id
- Last 14 complete days (exclude today)
- Use event_time for day bucketing
- Deduplicate duplicates by keeping latest ingestion_time per event_id
- Exclude negative cost_micros
*/

WITH params AS (
  SELECT
    DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY) AS start_date,
    DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) AS end_date
),
filtered AS (
  SELECT
    e.event_id,
    e.campaign_id,
    e.event_time,
    e.ingestion_time,
    COALESCE(e.impressions, 0) AS impressions,
    COALESCE(e.cost_micros, 0) AS cost_micros
  FROM ads.ad_delivery_events e
  CROSS JOIN params p
  WHERE DATE(e.event_time) BETWEEN p.start_date AND p.end_date
    AND COALESCE(e.cost_micros, 0) >= 0
),
deduped AS (
  SELECT
    event_id,
    campaign_id,
    event_time,
    impressions,
    cost_micros
  FROM (
    SELECT
      f.*,
      ROW_NUMBER() OVER (
        PARTITION BY f.event_id
        ORDER BY f.ingestion_time DESC, f.event_time DESC
      ) AS rn
    FROM filtered f
  ) x
  WHERE rn = 1
)
SELECT
  DATE(event_time) AS event_date,
  campaign_id,
  SUM(impressions) AS delivered_impressions,
  SUM(cost_micros) / 1e6 AS delivered_spend
FROM deduped
GROUP BY 1, 2
ORDER BY 1, 2;

The distribution tells a clear story: Spotify's ad forecasting org interviews like a systems team that happens to do ML, not the other way around. ML System Design and ML Modeling compound each other in a specific way here, because sample questions show you'll need to connect probabilistic forecast outputs (prediction intervals for hourly ad inventory) directly to campaign pacing constraints and optimizer inputs. The biggest prep mistake is treating coding as an afterthought, since pipeline design and algorithm questions together carry as much weight as the forecasting-focused rounds, and the coding problems themselves are ad-domain flavored (streaming impression events, EWMA computations) rather than generic.

Prep with Spotify ad forecasting questions and worked solutions at datainterview.com/questions.

How to Prepare for Spotify Machine Learning Engineer Interviews

Spotify is pushing hard on two fronts: scaling its advertising business through the Spotify Ad Exchange for programmatic buying, and deepening creator tools as part of its 2026 artist roadmap. For ML Engineers, that translates to forecasting models for ad inventory pacing, recommendation systems for personalization across 696 million monthly users, and identity protection pipelines that prevent creator impersonation and scams.

The biggest mistake candidates make in their "why Spotify" answer is talking about loving music. Interviewers have heard it thousands of times. What actually lands: referencing something like Spotify's AI content protection policies and explaining how you'd approach the classification problem behind detecting mismatched or fraudulent content at scale, or describing how you'd design campaign pacing models that optimize for completion rate and cost-per-conversion in the Ad Exchange. Anchor your answer to a system you'd want to build, with enough specificity that it couldn't apply to any other company.

Try a Real Interview Question

from __future__ import annotations

from typing import List, Tuple, Optional


def rolling_mape_and_wape(
    rows: List[Tuple[str, float, float]]
) -> Tuple[List[Tuple[str, Optional[float]]], Optional[float]]:
    """Compute 7-day rolling MAPE per provided date and overall WAPE.

    Args:
        rows: List of (date_str, actual, forecast) where date_str is 'YYYY-MM-DD'.

    Returns:
        (rolling_mape_by_date, wape)
        rolling_mape_by_date: list of (date_str, mape_or_none) in ascending date order.
        wape: overall WAPE as float, or None if total actual denominator is 0.
    """
    pass

from __future__ import annotations

from collections import deque
from dataclasses import dataclass
from datetime import date, datetime, timedelta
from typing import Deque, Dict, List, Optional, Tuple


@dataclass(frozen=True)
class _Day:
    d: date
    y: float
    yhat: float


def _parse_date(s: str) -> date:
    return datetime.strptime(s, "%Y-%m-%d").date()


def rolling_mape_and_wape(
    rows: List[Tuple[str, float, float]]
) -> Tuple[List[Tuple[str, Optional[float]]], Optional[float]]:
    """Compute 7-day rolling MAPE per provided date and overall WAPE.

    Rolling window is defined over the last 7 calendar days including current date.
    Only days present in input are used. MAPE terms with y == 0 are ignored.

    Overall WAPE uses all provided days, adding |y - yhat| for every row and adding
    |y| to the denominator only when y != 0. If denominator is 0, WAPE is None.
    """
    if not rows:
        return ([], None)

    # If duplicate dates appear, keep the last occurrence.
    by_date: Dict[date, Tuple[float, float]] = {}
    for ds, y, yhat in rows:
        by_date[_parse_date(ds)] = (float(y), float(yhat))

    days: List[_Day] = [
        _Day(d=d, y=by_date[d][0], yhat=by_date[d][1]) for d in sorted(by_date)
    ]

    # Overall WAPE.
    num = 0.0
    den = 0.0
    for day in days:
        num += abs(day.y - day.yhat)
        if day.y != 0.0:
            den += abs(day.y)
    wape: Optional[float] = None if den == 0.0 else num / den

    # Rolling 7-calendar-day MAPE per provided date.
    window: Deque[_Day] = deque()
    sum_ape = 0.0
    cnt = 0

    out: List[Tuple[str, Optional[float]]] = []
    for cur in days:
        window.append(cur)
        if cur.y != 0.0:
            sum_ape += abs(cur.y - cur.yhat) / abs(cur.y)
            cnt += 1

        cutoff = cur.d - timedelta(days=6)
        while window and window[0].d < cutoff:
            old = window.popleft()
            if old.y != 0.0:
                sum_ape -= abs(old.y - old.yhat) / abs(old.y)
                cnt -= 1

        mape = None if cnt == 0 else sum_ape / cnt
        out.append((cur.d.isoformat(), mape))

    return out, wape

Spotify's engineering team has been writing Python since at least 2013, and their ML Engineer job listings consistently require production-grade Python, not competitive programming fluency. That history means your coding round will likely reward readable, well-structured solutions over brute-force optimization. Build that habit with problems at datainterview.com/coding.

Test Your Readiness

Gauge where your gaps are, then target your remaining prep time with Spotify-specific practice questions at datainterview.com/questions.