Spotify Data Scientist Interview Guide

One pattern we see coaching Spotify candidates: they over-prepare for ML modeling and under-prepare for the experimentation and product thinking that actually dominate the interview. Spotify's DS org is embedded in product squads, not siloed in a central team, and the questions reflect that. If you can't articulate why you'd choose one success metric over another for a Discover Weekly experiment, strong modeling chops alone won't carry you.

Spotify Data Scientist Role

You're placed inside a squad (the Personalization team tuning Home shelf recommendations, the Ads Measurement team building campaign attribution, the Podcast team modeling audiobook engagement) and you own that squad's analytical loop end-to-end. Success after year one means you've designed experiments that changed how a feature behaves for some slice of Spotify's 675M+ monthly users, and your PM trusts you to define the right metrics, not just query them.

A Typical Week

The ratio of hands-on coding to meetings is higher than most product DS roles at comparable companies. You're not handing off specs to an analytics engineer; you're writing the SQL, building propensity score models in Python, and debugging data quality issues yourself. The day-in-life widget shows the split, but what it doesn't convey is how interleaved these activities are. A Wednesday morning might start with presenting playlist diversity findings to a Personalization product director, then pivot to writing an experiment recommendation doc that gets shared async in Slack before the next product review.

Projects & Impact Areas

Recommendation quality anchors most DS work, whether that's studying skip patterns in Discover Weekly segmented by taste-profile clusters or designing power analyses for artist verification experiments tied to fraudulent stream detection. Spotify's expanding advertising partnerships have turned the Ads Measurement team into a growing DS hub focused on attribution and inventory forecasting. Meanwhile, trust/safety (AI-generated content detection) and non-music audio engagement modeling are newer areas pulling in dedicated DS headcount as Spotify pushes deeper into podcasts and audiobooks.

Skills & What's Expected

The skill scores in the widget show high bars across stats, software engineering, ML, and data architecture, but here's the implication candidates miss: Spotify expects you to build and maintain data pipelines, not just consume clean tables. Python is the lingua franca (they've published about this since 2013), and SQL proficiency means schema design, not just SELECT statements. At Senior and above, business acumen and communication carry equal weight to technical depth. You need to walk a product director through tradeoffs specific to Spotify's two-sided marketplace (listeners vs. creators) and get a shipping decision made. GenAI/LLM skills score low for most roles; the AI Foundations team is the exception, so don't over-index on transformer prep when you should be drilling causal inference.

Levels & Career Growth

The widget shows five levels from Associate through Principal. What it doesn't show is the promotion bottleneck: moving from Senior to Staff requires demonstrating impact beyond your own squad's metrics, which means influencing experimentation standards or mentoring across a mission. Staff and Principal roles shift toward cross-squad technical leadership, not just harder individual analyses. Spotify has a documented IC career path (published on their engineering blog since 2016), so growth doesn't require switching to management.

Work Culture

Spotify's squad/tribe/guild model gives you genuine autonomy over your analytical approach and metric definitions. The flip side is less hand-holding than a centralized DS org, so your first months can feel disorienting if you thrive on heavy structure. The culture notes in the widget mention flexible hybrid arrangements and sustainable hours, and from what candidates report, that tracks. The pace ramps hard during experiment cycles but doesn't stay at redline.

Spotify Data Scientist Compensation

The cliff is the thing to internalize. Walk before 12 months and you leave with zero equity, which at Senior level represents a meaningful chunk of your total package. Refresh grants are performance-tied and discretionary, so when you're evaluating an offer, model your comp assuming the initial grant is all you'll get. If refreshes materialize, treat them as upside.

Spotify's negotiation notes explicitly list base, sign-on bonus, and equity grant as levers, while bonus targets and level are harder to move. From what candidates report, showing up with a competing offer from Meta or Google creates the most room on equity and sign-on. One Spotify-specific angle worth pressing: ask whether they can shift the mix between base and equity to match your risk tolerance, since the offer negotiation guidance calls this out as a real option. Get the vesting schedule details in writing before you sign.

Spotify Data Scientist Interview Process

Budget about five weeks from recruiter call to offer decision. Weak technical communication is a top rejection reason, from what candidates report. Getting the math right isn't enough. Spotify's squad model means your future colleagues are PMs and engineers, so every round rewards the ability to explain assumptions and metric definitions to people who won't read your notebook.

That communication bar hits hardest in the final Presentation stage, where you're defending a past project to a mixed panel. But it also shapes how interviewers score you across the entire loop. From what candidates describe, feedback from all seven rounds gets weighed together rather than any single interviewer holding a veto. The practical takeaway: consistency matters more than one standout performance, and a rough round doesn't automatically sink you if the rest of your signal is strong.

Spotify Data Scientist Interview Questions

/* D7 retention by signup_date.
   Assumptions:
   - Day 7 means the calendar day that is exactly 7 days after signup_date.
   - streams.ms_played is in milliseconds.
   - BigQuery Standard SQL.
*/

WITH cohort AS (
  SELECT
    u.user_id,
    DATE(u.signup_ts) AS signup_date
  FROM `users` u
),
eligible_streams AS (
  SELECT
    s.user_id,
    DATE(s.stream_ts) AS stream_date
  FROM `streams` s
  WHERE s.ms_played >= 30000
),
retained_users AS (
  SELECT
    c.user_id,
    c.signup_date
  FROM cohort c
  JOIN eligible_streams es
    ON es.user_id = c.user_id
   AND es.stream_date = DATE_ADD(c.signup_date, INTERVAL 7 DAY)
  GROUP BY c.user_id, c.signup_date
)
SELECT
  c.signup_date,
  COUNT(DISTINCT c.user_id) AS new_users,
  COUNT(DISTINCT r.user_id) AS retained_d7_users,
  SAFE_DIVIDE(COUNT(DISTINCT r.user_id), COUNT(DISTINCT c.user_id)) AS d7_retention
FROM cohort c
LEFT JOIN retained_users r
  ON r.user_id = c.user_id
 AND r.signup_date = c.signup_date
GROUP BY c.signup_date
ORDER BY c.signup_date;

/* Discover Weekly share of listening in first 28 days after signup.
   Notes:
   - A stream is attributed to Discover Weekly if the streamed track_id exists in the Discover Weekly playlist.
   - To prevent duplicate attribution within Discover Weekly, dedupe (playlist_id, track_id).
   - BigQuery Standard SQL.
*/

WITH dw_playlists AS (
  SELECT p.playlist_id
  FROM `playlists` p
  WHERE LOWER(p.name) = 'discover weekly'
),
dw_tracks AS (
  SELECT DISTINCT
    pt.track_id
  FROM `playlist_tracks` pt
  JOIN dw_playlists dwp
    ON dwp.playlist_id = pt.playlist_id
),
streams_28d AS (
  SELECT
    s.user_id,
    s.track_id,
    s.ms_played
  FROM `streams` s
  JOIN `users` u
    ON u.user_id = s.user_id
  WHERE DATE(s.stream_ts) >= DATE(u.signup_ts)
    AND DATE(s.stream_ts) < DATE_ADD(DATE(u.signup_ts), INTERVAL 28 DAY)
),
user_totals AS (
  SELECT
    user_id,
    SUM(ms_played) AS total_ms_28d
  FROM streams_28d
  GROUP BY user_id
),
user_dw AS (
  SELECT
    s.user_id,
    SUM(s.ms_played) AS dw_ms_28d
  FROM streams_28d s
  JOIN dw_tracks dwt
    ON dwt.track_id = s.track_id
  GROUP BY s.user_id
)
SELECT
  t.user_id,
  t.total_ms_28d,
  COALESCE(d.dw_ms_28d, 0) AS dw_ms_28d,
  SAFE_DIVIDE(COALESCE(d.dw_ms_28d, 0), t.total_ms_28d) AS dw_share_28d
FROM user_totals t
LEFT JOIN user_dw d
  ON d.user_id = t.user_id
ORDER BY t.user_id;

import numpy as np
import pandas as pd

# df columns: user_id, variant, exposure_ts, event_ts, event_type
# Assumptions:
# - exposure_ts is already the first exposure per user (if not, we enforce it below)
# - session events are event_type == 'session'

_df = df.copy()

# Ensure timestamps
_df['exposure_ts'] = pd.to_datetime(_df['exposure_ts'], utc=True)
_df['event_ts'] = pd.to_datetime(_df['event_ts'], utc=True)

# Enforce first exposure per user and carry variant from first exposure
first_exposure = (_df[['user_id', 'variant', 'exposure_ts']]
                  .dropna()
                  .sort_values(['user_id', 'exposure_ts'])
                  .drop_duplicates('user_id', keep='first'))

# Join first exposure back, then filter to events after that exposure
_df = _df.merge(first_exposure, on='user_id', how='inner', suffixes=('', '_first'))
_df['variant'] = _df['variant_first']
_df['exposure_ts'] = _df['exposure_ts_first']
_df = _df.drop(columns=['variant_first', 'exposure_ts_first'])

# Window (0, 7] days after exposure
window_end = _df['exposure_ts'] + pd.to_timedelta(7, unit='D')
in_window = (_df['event_ts'] > _df['exposure_ts']) & (_df['event_ts'] <= window_end)

is_session = _df['event_type'].eq('session')

# User-level retention label
user_retained = (_df.loc[in_window & is_session, ['user_id']]
                 .drop_duplicates()
                 .assign(retained=1))

user_table = (first_exposure[['user_id', 'variant']]
              .merge(user_retained, on='user_id', how='left')
              .fillna({'retained': 0}))

agg = (user_table.groupby('variant', as_index=False)
       .agg(n=('user_id', 'nunique'), x=('retained', 'sum')))
agg['p'] = agg['x'] / agg['n']

# Compute lift (assumes variants named 'control' and 'treatment')
control = agg.loc[agg['variant'].eq('control')].iloc[0]
treat = agg.loc[agg['variant'].eq('treatment')].iloc[0]

p_c, n_c = float(control['p']), int(control['n'])
p_t, n_t = float(treat['p']), int(treat['n'])

diff = p_t - p_c
se = np.sqrt(p_t * (1 - p_t) / n_t + p_c * (1 - p_c) / n_c)
z = 1.96
ci_low, ci_high = diff - z * se, diff + z * se

result = {
    'retention_by_variant': agg[['variant', 'n', 'x', 'p']].to_dict(orient='records'),
    'lift_abs': diff,
    'lift_ci_95': (ci_low, ci_high)
}
result

import numpy as np
import pandas as pd

# df columns: user_id, track_id, session_id, event_ts, event_name
_df = df.copy()
_df['event_ts'] = pd.to_datetime(_df['event_ts'], utc=True)

# Build per track_start a window to match the first skip within 30 seconds in the same session and track
starts = (_df[_df['event_name'].eq('track_start')]
          .sort_values(['session_id', 'track_id', 'event_ts'])
          .assign(start_id=lambda x: x.groupby(['session_id', 'track_id']).cumcount())
          [['session_id', 'track_id', 'event_ts', 'start_id']]
          .rename(columns={'event_ts': 'start_ts'}))

skips = (_df[_df['event_name'].eq('skip')]
         .sort_values(['session_id', 'track_id', 'event_ts'])
         [['session_id', 'track_id', 'event_ts']]
         .rename(columns={'event_ts': 'skip_ts'}))

# For each start, find the first skip after start within 30s
# Approach: merge-asof within each (session_id, track_id)
starts_list = []
for (sid, tid), s_starts in starts.groupby(['session_id', 'track_id']):
    s_skips = skips[(skips['session_id'] == sid) & (skips['track_id'] == tid)]
    if s_skips.empty:
        s_starts = s_starts.assign(skipped_30s=0)
    else:
        m = pd.merge_asof(
            s_starts.sort_values('start_ts'),
            s_skips.sort_values('skip_ts'),
            left_on='start_ts',
            right_on='skip_ts',
            direction='forward',
            tolerance=pd.Timedelta(seconds=30)
        )
        s_starts = m.assign(skipped_30s=m['skip_ts'].notna().astype(int)).drop(columns=['skip_ts'])
    starts_list.append(s_starts)

start_labeled = pd.concat(starts_list, ignore_index=True)

# Aggregate per track
agg = (start_labeled.groupby('track_id', as_index=False)
       .agg(starts=('start_id', 'count'), skips_30s=('skipped_30s', 'sum')))

# Filter minimum starts
agg = agg[agg['starts'] >= 500].copy()

# Wilson interval
z = 1.96
n = agg['starts'].astype(float)
x = agg['skips_30s'].astype(float)
p = x / n

den = 1 + (z**2) / n
center = (p + (z**2) / (2 * n)) / den
half = (z * np.sqrt((p * (1 - p) / n) + (z**2) / (4 * n**2))) / den

agg['skip_rate'] = p
agg['ci_low'] = center - half
agg['ci_high'] = center + half

top20 = agg.sort_values(['skip_rate', 'starts'], ascending=[False, False]).head(20)

top20[['track_id', 'starts', 'skips_30s', 'skip_rate', 'ci_low', 'ci_high']]

Over half the question weight sits in measuring whether a product change actually worked, from picking the right metric to isolating its causal driver in a messy rollout across markets or platforms. That concentration means a candidate who's strong in, say, ML but shaky on experimental design for zero-inflated listening distributions or diff-in-diff across staggered iOS/Android launches will hit a wall fast. Most people under-prepare for the causal inference slice, treating it as an extension of A/B testing when Spotify's questions push you toward identification strategies (instrumental variables, regression discontinuity) that require genuinely different reasoning.

Sharpen your prep with Spotify-specific practice problems at datainterview.com/questions.

How to Prepare for Spotify Data Scientist Interviews

Spotify crossed €17.2 billion in annual revenue and posted a record annual operating profit in 2025. The advertising arm is scaling programmatic buying through Spotify Ad Exchange, which means DS teams there are building targeting models, incrementality frameworks, and campaign measurement pipelines from near-scratch.

On the creator side, Spotify committed to paying out over $11 billion in royalties in 2025 and is rolling out AI protections against artist impersonation and identity fraud. If you're interviewing for a Music or Platform mission squad, expect your work to sit at the intersection of recommendation quality and creator trust, two priorities that often pull in opposite directions.

Most candidates blow the "why Spotify" question by gushing about Discover Weekly. Interviewers want to hear you name a specific tension in the business and explain why your background maps to it. A strong answer might sound like: "I've built attribution models for programmatic audio campaigns, and Spotify Ad Exchange is solving exactly the incrementality problem I spent two years on at my last company." That's not interchangeable with any other company because it ties your experience to a product Spotify launched in the last year, not a playlist feature everyone already knows about.

Try a Real Interview Question

| user_id | variant | assign_ts           |
|---------|---------|---------------------|
| u1      | control | 2026-01-01 10:00:00 |
| u2      | treatment | 2026-01-01 12:00:00 |

| user_id | event_ts            | event_type |
|---------|---------------------|------------|
| u1      | 2026-01-03 09:00:00 | listen     |
| u2      | 2026-01-10 12:01:00 | listen     |

WITH assigned AS (
  SELECT
    user_id,
    variant,
    assign_ts
  FROM experiment_assignments
),
retained AS (
  SELECT DISTINCT
    a.user_id,
    a.variant
  FROM assigned a
  JOIN listening_events e
    ON e.user_id = a.user_id
   AND e.event_type = 'listen'
   AND e.event_ts >= a.assign_ts
   AND e.event_ts < a.assign_ts + INTERVAL '7 day'
)
SELECT
  a.variant,
  COUNT(DISTINCT a.user_id) AS assigned_users,
  COUNT(DISTINCT r.user_id) AS retained_users,
  1.0 * COUNT(DISTINCT r.user_id) / NULLIF(COUNT(DISTINCT a.user_id), 0) AS retention_7d
FROM assigned a
LEFT JOIN retained r
  ON r.user_id = a.user_id
 AND r.variant = a.variant
GROUP BY a.variant
ORDER BY a.variant;

Spotify's coding screens don't stop at writing correct queries. You'll reason about schema design choices, think through how event-level listening data should be modeled, and defend tradeoffs in your approach out loud. Build that muscle at datainterview.com/coding, where the problems are structured to mirror real DS interview pressure.

Test Your Readiness

Experimentation and causal inference are where most candidates underperform relative to their confidence. Sharpen those edges at datainterview.com/questions.