Spotify Machine Learning Engineer Interview: Questions & Prep (2026)

Spotify is one of the world's leading audio streaming platforms, and its ML team builds some of the most widely used AI products in the world: Discover Weekly, podcast recommendations, real-time audio analysis, and personalised ad targeting. Breaking into this team requires strong preparation across machine learning theory, system design, and product thinking.

Candidates typically report a process that includes a recruiter call, a technical phone screen, and a virtual onsite with multiple rounds. These rounds commonly cover ML fundamentals, coding (data structures and algorithms), ML system design, and a behavioural round focused on Spotify's values. The exact structure varies by team and seniority level, so confirm the format with your recruiter early.

As of July 2026, knok's jobradar shows 130 open roles at Spotify across India. The broader Machine Learning Engineer market is active, with 803 openings tracked nationally:

Bangalore leads by a wide margin, making it the strongest base for ML career moves in India right now.

These questions are commonly reported by candidates who have interviewed at Spotify for ML Engineer roles. Spotify's own products give you rich context to anchor every answer.

1. How does Discover Weekly work at a high level, and how would you redesign or improve one part of it?
2. Design an ML system to predict podcast listener churn (a user stops returning after the first few episodes).
3. How would you handle the cold-start problem for a brand-new user who just signed up with no listening history?
4. Walk me through how you would build a real-time audio feature extraction pipeline for music genre classification.
5. How would you A/B test a new recommendation algorithm? What metrics would you track, and what would make you decide to ship or roll back?
6. Tell me about a model you shipped that underperformed in production. What went wrong, and how did you fix it?
7. Spotify operates across many countries with very different music preferences. How would you build a recommendation model that respects this diversity without training a separate model per country?
8. What is the difference between collaborative filtering and content-based filtering? When would you choose one over the other at Spotify's scale?
9. How would you design a system to detect explicit audio content at scale across millions of uploads?
10. How do you approach feature engineering for sequential user behaviour data, such as a listener's skip and play history?
11. Describe a time you had to trade off model accuracy against latency or infrastructure cost. What was your decision process?
12. How do you measure the real business impact of an ML model after it goes live?

Use the STAR format (Situation, Task, Action, Result) for all behavioural and project-based questions. Below are three examples anchored to real ML scenarios.

Q: Tell me about a model you shipped that underperformed in production. What went wrong, and how did you fix it?

*Situation:* At my previous company, I trained a click-through rate model for personalised content recommendations. Offline evaluation looked strong, with good AUC on our holdout set.

*Task:* After launch, production click-through was noticeably lower than our offline estimates, and the business team escalated quickly.

*Action:* I audited the feature pipeline and found a couple of issues. First, there was a training-serving skew: one feature was computed with a one-day lag in training but served in real time in production, creating a distribution mismatch. Second, our holdout set was randomly split, leaking future data into training through a user-level feature. I corrected the lag, rebuilt the holdout using a proper time-based split, and retrained. I also added feature distribution monitoring to catch drift early.

*Result:* After retraining, production performance matched our revised offline estimates and clicks recovered to the level we originally projected. The monitoring system caught a similar drift issue months later before it reached users.

---

Q: Describe a time you had to trade off model accuracy against latency or cost. What was your decision process?

*Situation:* Our team was building a real-time recommendation re-ranker that ran on every page load. The most accurate model we had was a large transformer that could not serve at the required throughput within the latency budget.

*Task:* I needed to find a solution that kept recommendation quality high while hitting the latency target the product team had set.

*Action:* I first profiled where the latency was coming from and confirmed most of it was in model inference. I then tried a few approaches: quantising the model, distilling it into a smaller student model, and switching to a lighter architecture trained from scratch. I ran offline quality checks and a small shadow test for each option. The distilled model hit our latency target with only a small drop in quality, which the product team accepted after reviewing the metrics together.

*Result:* We shipped the distilled model and met the latency requirement in production. The experience taught me to prototype latency constraints early, before investing time in training large models.

---

Q: How do you measure the real business impact of an ML model after it goes live?

*Situation:* After shipping a new playlist personalisation model, my manager asked me to quantify its actual business value, not just report offline metrics.

*Task:* I had to connect ML outputs to user and revenue outcomes in a rigorous, defensible way.

*Action:* I designed a holdback experiment where a small share of users continued to receive the old model. I tracked metrics that mattered to the business: session length, return rate over the following weeks, and playlist save rate. I also worked with the data team to confirm the experiment groups were balanced before drawing conclusions.

*Result:* The new model showed a statistically meaningful lift in return rate in the holdback group. I documented the methodology and metrics in a shared playbook so the team could reuse the approach for future model launches.

For ML system design questions, use a structured walk-through: start by clarifying the problem and success metrics, then discuss data sources and labelling, then feature engineering, then model choice and why, then serving and latency requirements, then monitoring and maintenance. Spotify questions often reward candidates who anchor their design to audio or user behaviour data specifically, not generic setups.

For behavioural questions, STAR works best. Situation and Task should be brief (a sentence or two each). Spend most of your time on Action (your specific choices, not 'we' as a team) and Result (quantified or clearly described outcomes). If you cannot share numbers due to confidentiality, describe the direction and scale of the impact.

For coding questions, think out loud from the start. Candidates report questions on graph traversal, dynamic programming, and data manipulation with libraries like Pandas or NumPy. State your approach before coding, mention edge cases, and ask about constraints upfront.

For product-sense questions about Spotify's features, get into the habit of asking 'what is the goal of this feature?' before jumping to a solution. Interviewers want to see that you connect ML choices to user value and business outcomes.

Spotify ML interviewers consistently look for a few qualities beyond raw technical skill.

Product awareness: Spotify expects ML engineers to understand what their models are actually for. Candidates who can talk about Discover Weekly, the audio features Spotify exposes via its API, or how personalisation differs for music versus podcasts tend to stand out.

Depth over breadth: Interviewers prefer candidates who can go deep on one ML area (recommendation systems, audio processing, ranking) rather than giving surface-level answers across many topics.

Engineering rigour: Spotify is a high-scale system. Showing that you think about latency, data pipelines, monitoring, and failure modes (not just model accuracy) signals that you can own an ML feature end to end.

Collaboration and communication: Candidates report that Spotify values people who can explain ML trade-offs to non-ML stakeholders. Practise explaining your choices in plain language.

Data-driven thinking: Interviewers want to see that you default to measurement. Frame decisions around metrics, experiments, and evidence rather than intuition alone.

Week 1: Ground yourself in Spotify's products and ML thinking

Read Spotify's engineering blog posts and watch their public talks on recommendation systems, audio embeddings, and data infrastructure. Familiarise yourself with how Discover Weekly and podcast recommendations work at a conceptual level. This product context makes your system design answers far more specific and memorable.

Week 2: ML fundamentals and system design

Revise core topics: collaborative filtering, matrix factorisation, gradient boosting, neural embeddings, and ranking models. Practise designing end-to-end ML systems out loud. A good prompt to practise: 'Design a podcast recommendation system for a platform with millions of active users.' Aim to cover data, features, model choice, serving, and monitoring in every session.

Week 3: Coding and algorithms

Practise medium and hard problems on arrays, graphs, and dynamic programming. Coding rounds are reported to be similar in style to standard software engineering interviews. Prioritise clarity and correctness: explain your reasoning as you code rather than working in silence.

Week 4: Behavioural prep and mock interviews

Write out several STAR stories from your own experience. Cover at least one story each for: a technical failure and recovery, a trade-off decision, a cross-team collaboration, and a project where you measured business impact. Run at least a few full mock interviews with a peer or community member before your actual round.

Treating Spotify like a generic tech company. Candidates who give purely textbook ML answers without connecting them to audio, streaming, or personalisation often do not progress. Use Spotify's actual products as the context for your examples wherever possible.

Optimising only for accuracy. A common pattern is to jump straight to 'I would use XGBoost because it has the best AUC.' Interviewers want to hear you weigh latency, cost, data availability, and maintainability alongside accuracy.

Skipping clarifying questions in system design. Jumping to a solution before establishing scale, latency requirements, and success metrics is a red flag. Spend the opening minutes of any design question asking and aligning before you start drawing diagrams.

Using 'we' throughout STAR answers. Interviewers are assessing your individual contribution. Be specific about what you personally decided, built, or fixed.

Not preparing questions to ask the interviewer. Spotify interviewers typically leave time for your questions. Asking thoughtful questions about their ML challenges or team structure signals genuine interest and leaves a strong impression.

Ignoring monitoring and feedback loops. Many candidates describe training and deploying a model but stop there. Showing that you think about data drift, retraining schedules, and production alerts demonstrates real-world ML maturity.