Spotify MLE 面经 2026：Recommendation、Search 和 Ranking

💡 核心要点 (Key Takeaways)

• Spotify MLE 面试主轴是 ML System Design（Recommendation、Search、Ranking，1-2 轮）+ ML Coding（特征工程、Ranking 指标实现、ML 理论，1-2 轮）+ 项目规模深挖 + Spotify values BQ；Culture 不是独立轮次，而是嵌进每一轮评分：前 10 分钟提问质量、metric 口径是否先讲清、假设是否主动声明、follow-up 约束变化能否接住，都算分。
• Spotify 是音乐流媒体 + 音频内容平台，Recommendation / Search / Ranking 题必须落在音频业务语境里答：内容库是亿级 track + podcast 且持续上新（new release 冷启动和曝光分配是必答项），playlist 是一等公民（歌单推荐、歌单内排序），Discover Weekly / Release Radar 这类招牌产品本身就是题目原型；skip rate、play-through、listening time 这些音频指标口径讲不出来，用电商 / 短视频模板答整轮难救。
• Search 是 Spotify MLE 的高频独立方向，不是 Recommendation 的附庸：音乐搜索要区分显式意图（找一首确定的歌 / 一个 artist）和发现意图（模糊 query、探索），query 理解、多路召回、混合排序、new release 冷启动、多语言各有一组考点——只准备推荐不准备搜索，是 Spotify MLE 候选人的常见准备缺口。
• Ranking 题的核心区分项是多目标 + 长期信号：listening time、skip rate、follow / save、subscription 转化多个目标怎么联合训练和排序，calibration 为什么重要（后续还有 ads bidding 等需要概率标定的环节），novelty effect 和长期 retention guardrail 怎么处理；只会讲单目标 CTR 优化会被判断为没跑过真实会员漏斗。
• Spotify 公开面经信号量偏小（MLE 帖少于 DS / DE 帖，部分混在 SWE 帖里），按「年份 + 级别 + 团队方向」筛选、以 2-3 篇共识判断轮次结构；7 天保 Recommendation SD + Search SD + ML Coding 下限，14 天补多目标 / Ads 场景和项目深挖，30 天加深 follow-up 链、长期信号专项和完整 mock。

这篇适合谁

这篇写给准备 Spotify Machine Learning Engineer（MLE）面试的候选人，覆盖 Personalization / Recommendation、Search、Ranking、Ads ML、Audio / ML Infra 等方向，级别以社招中高级为主（大致对标 Google L4 / L5、Meta E4 / E5，Spotify 内部有自己的级别体系，以 JD 和实际沟通为准），NG / Intern 和部分方向候选人的差异会在流程一节说明。文章基于 2026 年公开面经信号和 Spotify 公开的产品架构与 Culture 材料整理，各团队、级别、地区的轮次结构会有出入，以实际收到的邀请为准。

一句话定位：Spotify MLE = ML System Design（Recommendation、Search、Ranking）+ ML Coding（特征工程、Ranking 指标实现、ML 理论）+ 项目规模深挖 + Spotify values BQ。Spotify 是音乐流媒体 + 音频内容平台，题面和 SD 场景几乎都落在这个业务语境里：listening 行为、playlist 生态、Discover Weekly / Release Radar、new release 冷启动、podcast / audiobook、ads。Culture 不是一轮独立考试，而是嵌在每一轮技术题的评分里——前 10 分钟提问的质量、metric 口径是否先讲清、trade-off 是否完整，都直接进分。想看公司级完整题型清单（含 SWE / DS / DE 方向），见 Spotify 公司页；投 SWE 或 DS 的注意题型重心不同——SWE 重 Backend 化 Coding 和音频平台 System Design，见 Spotify SWE 面经，DS 偏 Experiment / Product Analytics，见 Spotify DS 面经。

• 适合准备 Spotify MLE 社招中高级面试的候选人（大致对标 Google L4 / L5、Meta E4 / E5）
• 主轴：ML System Design（Recommendation / Search / Ranking）+ ML Coding（特征工程 / 指标实现 / ML 理论）+ 项目深挖 + values BQ
• 题面和 SD 场景几乎全在音乐 / 音频业务语境：playback、playlist、discovery、new release、podcast、ads
• Culture 嵌在每轮技术评分里：提问质量、口径澄清、trade-off 完整度都算分，不是独立考试

面试流程：OA / Phone / VO / HM / Team Match 各轮是什么

Spotify MLE 的主线流程是：投递 / 内推 → Recruiter Screen → Take-Home 或 Online Assessment（部分岗位 / 部分级别）→ Phone Screen → Onsite / VO（4 轮）→ HM → Team Match → offer。公开信号里有两个特点要提前知道：MLE 没有统一 OA（NG / 部分岗位有 take-home 或 CodeSignal 式 online assessment），take-home 在 Spotify 更常见于数据 / 工程类岗位，MLE 岗位收到 ML 项目类 take-home 的比例不高但确实存在；VO 多为 4 轮 × 45-50 分钟，常见结构是 1-2 轮 ML Coding（其中常含一道 ML 理论 / 指标实现题）+ 1-2 轮 ML System Design（Recommendation / Search / Ranking 是高频方向）+ 1 轮 Values / Behavioral，Recommendation / Search 方向的团队可能排 2 轮 SD。各轮大致长这样：

• Recruiter Screen（30-45 分钟）：不考技术，聊动机、背景、级别期望和方向。MLE 岗位这轮常被问「你做过什么模型相关的工作、影响了什么业务指标」，要能一句话说清项目规模（内容库规模、用户规模、QPS、特征数量、模型延迟、影响的指标），「参与过推荐项目」这种颗粒度不够。同时会初步确认「为什么是 Spotify、为什么是音乐行业」，这轮的答案会传到后面轮次。
• Take-Home（部分 MLE 岗位，1-2 周）/ Online Assessment（NG / 部分岗位，限时）：如果 MLE 岗位收到 take-home，通常是 ML 项目交付题（数据分析 / 模型迭代 / metric 提升一类），考察的是「能不能像真工程师一样交付」：README、假设清单、代码与实验质量、trade-off 和后续改进计划都要写在文档里。NG / Intern 有时走 CodeSignal 式 online assessment（medium 难度、限时作答）。以实际收到的邀请为准。
• Phone Screen（45-60 分钟）：常见结构是 1 道 medium Python ML coding（特征工程、Ranking 指标实现、数据处理是高频方向，也会带产品味题面：top-N 最热门 track、基于共同收听行为的相似 artist 图）+ 简历深挖穿插，部分团队是纯 coding。考察的是无提示下能否先讲清 metric 口径、完成第一版实现并把复杂度讲清楚，follow-up 常见「数据量 10 倍怎么优化」「特征要秒级新鲜度怎么做」这类约束变化。
• Onsite / VO（4 轮，每轮 45-50 分钟，通常一天面完）：常见结构是 1-2 轮 ML Coding（特征工程、指标实现、ML 理论，外加一道经典 medium 或 OOD）+ 1-2 轮 ML System Design（Recommendation、Search、Ranking 是高频方向）+ 1 轮 Values / Behavioral（Spotify values + squad 文化）。Personalization 团队偏 Recommendation 和 playlist / discovery 场景，Search 团队偏 query 理解和检索排序，Ads 团队会在 SD 里加 ads ranking 和 bidding 追问。语言通常跟目标团队走，Spotify 面试以英文为主。
• HM（Hiring Manager Call）：VO 通过后，与 hiring manager 聊方向（recommendation / search / ads / audio infra）、level 和 comp，确认双向意向，不再考技术。
• Team Match：Spotify 的组织模型是 squads、tribes、chapters、guilds，匹配阶段会根据团队需求把你放进具体 squad。这一轮重点是双向确认方向和你和团队的匹配度，能主动说出「我希望进做 XX 方向的 squad」是加分项。Spotify 出结果通常 4-8 周，日程上留好余量。

题型雷达：ML Coding、ML System Design、Search、SQL、Values BQ 各占多少

按 MLE 岗位把题型按出现频率排个雷达图，ML System Design 和 ML Coding 是两根主轴，Spotify 的音频内容平台场景贯穿全程：

• ML System Design（最高频，1-2 轮）：Spotify MLE 最核心的环节，场景几乎都在 Spotify 自己的业务线上——Recommendation（home feed、Discover Weekly / Release Radar 式周期推送、playlist 推荐、new release 冷启动与曝光分配）、Search（音乐 / podcast 搜索的 query 理解、多路召回、排序、多语言）、Ranking（多目标、calibration、长期信号）、ads ranking（Ads 方向团队）。考点是业务约束（listening time、skip rate、follow、subscription 转化、内容多样性）→ 数据与特征 → 多段模型与延迟预算 → 评估与实验 → rollback 与监控的完整闭环，音频内容库的规模（亿级 track / podcast、多端）要能落到容量估算。通用结构框架可以看 ML System Design 专题，这里重点说 Spotify 场景怎么落。
• ML Coding（1-2 轮）：Python 为主，两种风格。一种是数据 / 特征向：特征工程（listening 行为序列、session 特征、时间衰减、cold start）、Ranking 指标实现（AUC / NDCG / GAUC / MRR，注意并列名次和时间切分防标签泄漏）、产品味 medium（top-N 热门内容、相似 artist 图、playlist 相似度）。另一种是 ML 理论：multi-objective（listening 和 conversion 怎么联合训练）、calibration 为什么重要（ads bidding 等下游需要概率标定）、delayed feedback（subscription / churn 标签延迟）、two-tower 在 retrieval 里的取舍。难度 medium，follow-up 会加规模和边界情况。
• Search 专项（Search 方向团队高频，其他方向出现在追问里）：音乐搜索和通用搜索最大的区别是意图结构——显式搜索（用户知道要找哪首歌 / 哪个 artist，query 接近完整标题）和发现搜索（模糊 query、探索性听歌）的排序逻辑完全不同，混合检索（exact match + 语义 + collaborative）怎么融合、new release 没有行为数据怎么排、多语言 / 多市场怎么处理，是 Spotify Search MLE 题的固定考点。
• SQL / 数据（中低频）：MLE 岗位一般不单独设 SQL 轮；Recommendation / growth 方向的候选人可能在 coding 轮被要求写实验指标聚合查询（listening / subscription 漏斗、window function、A/B 分组对比、cohort），不是主线，保基本盘即可。
• Spotify values BQ（1 轮 + 穿插每轮）：Spotify 的 BQ 考察 values 和 squad 文化协作。公开材料里 values 有两种常见表述：一是 We are in the music business, not the technology business / Open wins over closed / Do the next right thing / Grow by getting things done 四条；二是 open、curiosity、resourceful、empathy 四个关键词。高频方向：一次失败下的技术决策（模型没达预期怎么推）、跨 squad 推动一个决定、一次线上问题 / rollback 处理、为什么 Spotify。准备 5-8 个 STAR 故事，每个有 measurable impact 且能接两层追问。

高频题目：8 个代表题型和考点

以下是 2026 年公开面经信号里反复出现的题「类型」，只归纳题型和考点，不复刻任何人的具体原题：

• Recommendation 系统设计（home feed / Discover Weekly 式 top-N，ML SD 最高频）：设计 Spotify 首页或 Discover Weekly 式周期推荐。考点：业务约束（listening time、skip rate、follow / save、subscription 转化、内容多样性、new release 曝光）、候选集是动态的（每天有新歌 / 新 podcast 上架，长尾 artist 内容多）、多路 retrieval（i2i、u2i、embedding ANN + 业务规则）、多目标 ranking（listening、skip、conversion，multi-task + calibration）、re-ranking（多样性、genre / mood、新鲜度、exploration）、评估（离线 NDCG / GAUC + 线上 A/B：listening time、skip rate、retention 和 guardrail）、延迟预算（毫秒级）。关键动作是先立业务约束和音频指标口径，再谈模型怎么服务约束。
• Music Search 系统设计（Search 方向高频）：设计 Spotify 的音乐 / podcast 搜索：query 理解（区分显式意图——找确定的 song / artist / playlist——和发现意图）、多路召回（exact match、倒排索引、语义向量、collaborative）、排序（显式 query 重相关性、发现 query 重个性化和探索）、new release 和长尾 artist 的冷启动、多语言 / 多市场、latency 预算。考点是意图分类 + 混合检索 + 排序融合，只按「通用搜索引擎模板」答而不区分显式 / 发现意图是典型减分。
• Ranking 多目标 / ads ranking 系统设计（Ranking 与 Ads 方向高频）：为推荐或 ads 场景设计 ranking 层：多个业务目标（listening、engagement、conversion、广告主 ROI）怎么联合训练和融合（加权、Pareto、业务权重怎么定）、calibration（为什么 AUC 高但概率不准会在 bidding / 预算分配上出事故）、guardrail（长期 retention、用户体验不被短期点击率牺牲）、ads 场景加 auction 机制和 eCPM 排序。考点是「多目标 + 长期信号 + 校准」的完整闭环，单目标 CTR 叙事答不下来。
• ML Coding：Ranking 指标实现（高频）：实现 AUC / NDCG / GAUC / MRR。考点：代码能跑、指标口径正确（NDCG 的折损和并列名次、GAUC 按 user 分组加权）、主动交代边界情况（空列表、单一 user、时间切分防标签泄漏），follow-up 加规模时结构撑得住。
• ML Coding：listening 日志特征工程（高频）：从 listening 日志（member 的 impression → play → skip → follow 行为序列，带时间戳）构造排序特征：滑动窗口统计（最近 7 天 / 30 天行为）、session 特征、时间衰减、playlist 上下文特征、cold start 和缺失值处理。考点：口径先讲清再写（什么算一次有效播放、skip rate 的分母、play-through 的定义）、follow-up 追「特征要求秒级新鲜度怎么做到」（实时流 vs 离线批、training/serving 一致性）。
• ML 理论题：multi-objective / calibration / delayed feedback（math heavy）：listening 和 subscription conversion 两个目标怎么联合训练（多目标加权、业务权重随季节 / 市场变化怎么处理）；calibration 为什么重要（下游 ads bidding 和预算分配需要概率标定，AUC 高但概率不准会出什么问题）；subscription / churn 是延迟决策（member 不会马上取消），label delay 怎么处理（delayed feedback model、proxy label、延迟窗口怎么选）。推导要能手写，直觉要能三分钟内讲完。
• 经典 coding + OOD（部分团队出现）：产品味经典 medium（top-N 最热门 track、基于共同收听行为的相似 artist 图、playlist 相似度）+ OOD（playlist 服务：create / add / reorder / share、容量与权限）。考点是工程实现质量（代码结构、命名、测试、可扩展性）而不是算法炫技，follow-up 常加「输入变成流式」「时间维度」约束；Spotify 的 coding 口味是 Backend 工程 + 经典 medium 混合，详见 Spotify SWE 面经 的 coding 部分。
• SQL + BQ / 项目深挖方向：SQL：给定 member listening / subscription 表，算月度 listening 活跃率和 subscription churn（活跃口径、多设备多账号处理、时区与 billing 周期口径）。BQ / 深挖：一个你主导的推荐 / 搜索 / 排序项目（目标、你的具体贡献、量化结果、最大取舍）、一次模型没达预期的经历、一次跨 squad（产品 / 工程 / data）推动上线、为什么 Spotify。规模数字（内容库规模、用户规模、QPS、特征数、延迟、影响指标）必须张口就来，bad case review 和 offline-online gap 的处理是加分项。

公开面经信号怎么读

一亩三分地等面经社区是 Spotify MLE 面试信息最集中的公开来源，但要注意：Spotify 的公开信号总量比头部四大公司少，而且 MLE 帖比 DS / DE 帖少（部分 MLE 经历混在 SWE 帖子里发布，take-home 相关帖明显偏 data / 工程方向），读法比内容更重要。几个原则：

按「年份 + 级别 + 团队方向」筛选。2026 年 recommendation 团队的信号和 2024 年 ads 团队的信号可能完全不一样（语言、有没有 take-home、SD 深度都在变），只看最近 2-3 篇。团队方向必须对得上——MLE 的信号（Recommendation、Search、Ranking、特征工程）对 SWE 岗位（Backend、audio streaming、event pipeline）参考价值有限，反过来也一样，混着看会准备错方向。

找共识，不信个例。Spotify MLE 信号量小，单篇面经说「VO 是 5 轮、SD 只考了搜索」不能当结论；两到三篇独立帖子都提到「4 轮、1-2 ML coding + 1-2 SD + 1 values」「SD 高频方向是 recommendation / search / ranking」「take-home 只出现在部分岗位」，这个结构才可信。面经作者有幸存者偏差（过的人爱写，挂的人少写），整体难度感知会偏乐观。

提取「轮次结构 + 题型方向 + 挂点」，忽略剧情。每篇面经真正有用的信息密度就这三样：每轮考什么类型、面试官追问到什么深度、作者觉得自己过 / 挂在哪。故事细节、情绪、对面试官的评价都不需要带进你的准备里。

不搬运、不暗示合作。本站所有 Spotify MLE 面经内容都只归纳公开信号，不复制任何候选人的逐字面经，也不代表与任何面经社区有合作或转载关系。你读到的公开帖子请以原作者发布的内容为准。

常见挂点：Spotify MLE 独有的失分方式

把公开面经里的挂因和模拟面试复盘对照，Spotify MLE 特有的失分点集中在这几个：

• 用电商 / 短视频模板答音乐 Recommendation：最 Spotify 特色的挂点。SD 里全程没有出现 playback、skip、playlist、new release、artist 这些业务词，容量估算落不到亿级 track / podcast、多端（app / 车机 / 智能家居 / Web）的语境里，或者不主动讲内容池是动态的（每天上新、长尾 artist）——new release 没有行为数据，冷启动和曝光探索怎么分配答不出来。Spotify 面试官默认你处理过音频内容的时效性和规模，套通用推荐模板整轮可信度下降。
• Search 方向没准备：公开信号里音乐搜索题在 MLE 面里出现频率不低，但大量候选人只准备 Recommendation。答不出显式搜索和发现搜索的意图区分、混合检索怎么融合、new release 和长尾 artist 怎么排、多语言怎么处理，等于漏了一整根题轴。
• 规模不谈：feature / serving 题里不主动提内容库规模（亿级 track）、用户规模、QPS、freshness SLA 和 cost，只讲组件。Spotify 的规模语境是「多端 × 亿级内容 × 全球市场」，规模含糊是红旗；「我们团队有个推荐系统」这种颗粒度等于没说。
• Ranking 指标口径不严谨：实现 AUC / NDCG / GAUC 时并列名次、时间切分（防标签泄漏）、分组加权这些口径含糊，或者被追问「离线 AUC 涨了线上掉了怎么排查」时接不住（training/serving 一致性、特征漂移、novelty effect、评估集偏差）。指标题难度本身不高，口径错误是典型减分项。
• 多目标和长期信号没准备：只会讲单目标 CTR / 点击优化，答不出 listening time、skip rate、follow、subscription 转化多目标怎么联合训练，calibration 在 ads bidding 里为什么重要，novelty effect 和长期 retention guardrail 怎么处理。会被判断为没跑过真实会员漏斗。
• 项目规模说不清 / 只讲模型：深挖问内容库规模、用户规模、QPS、特征数、延迟时含糊带过，或者项目里只有模型结构没有线上闭环（特征、serving、实验、rollback）。每个项目准备三层回答：概述（2 分钟）→ 规模与取舍（5 分钟）→ 反思与结果（3 分钟），数字做速查表；「只讲模型」的补法见 MLE 只讲模型怎么补。
• 不澄清口径就动手写 + values 故事空泛：Spotify 的评分文化里「把假设说出来并确认」本身就是评分项——metric 口径（什么算有效播放、skip rate 分母）不先讲清就默默按自己脑补的前提写，前 10 分钟沉默直接上手通常直接失分。values BQ 侧的故事全是「我很努力」「我责任感强」，没有具体事件、没有 measurable impact、没有 squad 协作成分；「为什么 Spotify」答不出对音乐 / 音频业务的真实理解，Team Match 阶段会显得没做功课。

准备路线：7 天 / 14 天 / 30 天

按你距 VO 的天数选路线。三个版本的共同原则：ML System Design（Recommendation + Search）和项目规模深挖永远优先，ML Coding 和 ML 理论次之，SQL 保基本盘，values 故事保下限，最后两天只留 mock 和状态调整，不学新东西。

• 7 天（保下限版）：D1-D2 ML System Design：「home feed / Discover Weekly top-N 推荐」和「music Search」各按「业务约束 → 数据 / 特征 → 多段模型与延迟预算 → 评估与实验 → rollback」45 分钟结构完整走一遍，每遍计时，动态内容池、new release 冷启动、显式 / 发现意图区分这些失败路径必须主动交代；D3 ML Coding 做 2 题（NDCG / GAUC 实现 + listening 日志特征工程），重点练指标口径和边界情况；D4 ML 理论：multi-objective + calibration + delayed feedback，推导手写一遍，每个三分钟内能讲完，外加 1 道产品味 medium（top-N 或相似 artist 图）；D5 项目深挖 + values：主项目写三层答案（概述 → 规模与取舍 → 反思与结果），按 Spotify values 整理 5-6 个 STAR 故事 + 为什么 Spotify，口述录音回听；D6 完整 mock 1 场（SD + coding + 10 分钟 values），录音复盘；D7 缓冲日，检查设备日程，早睡。
• 14 天（标准版）：在 7 天基础上——D8-D9 补 2 道 SD：「Ranking 多目标系统」（multi-objective + calibration + guardrail）和「ads ranking 或 podcast / audiobook 推荐」（跨内容类型的推荐差异、多语言），每道强制主动交代失败路径和评估方法；D10 把 D1-D2 做过的 2 道 SD 重做一遍，这次把「动态内容池 + 音频指标口径 + training/serving 一致性」写成主线而不是补充；D11-D12 ML Coding 再补 2 题（滑动窗口流式特征、listening / subscription 漏斗 SQL 实验聚合）+ 1 道实验指标设计题（primary + guardrail）；D13 项目深挖扩到 2 个主项目 + mock 完整 loop（SD + coding + 深挖 + values 各一段）；D14 缓冲日。
• 30 天（系统版）：在 14 天基础上——D15-D18 SD 扩场景：new release 冷启动与 exploration（内容池动态性的完整答法）、Search 的多语言 / 跨市场处理、Recommendation 的疲劳 / 长期 guardrail、feature 平台 cost 优化（存储 / 计算 / freshness 取舍），每道补三类 follow-up（规模放大、实时性、失败降级）并给出方案 + 取舍；D19-D21 实验与长期信号专项：member-level 分流取舍、novelty effect、delayed feedback 下的实验时长与指标评估、「离线 AUC 涨线上掉」诊断，能在白纸上完整讲一遍；D22-D24 项目深挖库扩到 3 个主项目，各练三层追问（approach → 细节 → reflection），把「效果怎么衡量、bad case 怎么 review、规模化后怎么变」的答案写成卡片，规模数字做成速查表；D25-D27 连续 2-3 场完整 mock（找真人或录音），重点看 follow-up 接没接住、边写边说的节奏、规模和 cost 有没有主动提到；D28 复盘 mock，把断片点写下来各补一段；D29-D30 缓冲日。

FAQ：Spotify MLE 面试 5 个高频问题

Q1：Spotify MLE 面经怎么读？重点看什么？
公开面经（一亩三分地、Blind 等社区）重点读三样：轮次结构（几轮、每轮什么类型）、题型方向（Recommendation / Search / Ranking 场景题还是经典 ML 题）、挂点（作者觉得过 / 挂在哪）。注意 Spotify 的 MLE 信号量偏小，帖子以 DS / DE 经验居多，部分 MLE 经历混在 SWE 帖子里；只看年份 + 级别 + 团队方向对得上的最近 2-3 篇，以多篇共识为准。本篇的轮次结构、题型雷达和挂点就是按这个共识整理出来的。

Q2：Spotify MLE 面试几轮？
社招通常是：Recruiter Screen（不考技术）→ Take-Home 或 Online Assessment（部分岗位 / 部分级别，NG 更多）→ Phone Screen（45-60 分钟，1 道 medium Python ML coding + 简历深挖穿插）→ Onsite / VO 4 轮（1-2 轮 ML Coding + 1-2 轮 ML System Design + 1 轮 Values / Behavioral，每轮 45-50 分钟，recommendation / search / ads 团队方向不同）→ HM → Team Match。轮次数量和结构因团队、级别、地区而异，具体以实际收到的邀请为准，Spotify 出结果通常 4-8 周。

Q3：Spotify MLE 考什么？难度如何？
ML System Design 考 Recommendation、Search 和 Ranking，核心是链路完整度（业务约束 → 候选集与特征 → 多段模型与延迟预算 → 评估与实验 → rollback）+ Spotify 音频场景约束（亿级内容库、new release 冷启动、playlist 语境、多端多市场）；ML Coding 考 Python 特征工程 + Ranking 指标实现 + ML 理论（multi-objective、calibration、delayed feedback），难度 medium 但追问偏系统和数学；SQL 中低频，保基本盘；BQ 围绕 Spotify values 和 squad 协作文化，要求 measurable impact。主轴是「能不能把 Recommendation / Search / Ranking 链路讲成有数据闭环、有规模约束、贴着音乐业务答的线上服务」，不是算法竞赛深度。

• Q4：Spotify MLE 和 SWE / DS 岗位差别大吗？
  差别集中在题型主轴。MLE 的主轴是 ML Coding（特征工程、指标实现、ML 理论）+ ML System Design（Recommendation、Search、Ranking）+ 项目规模深挖 + values BQ；SWE 的主轴是 Backend 化 Coding（playlist / playback 事件聚合、OOD、streaming 去重）+ 音频平台 System Design（audio streaming、search & discovery、event pipeline）+ values，看 Spotify SWE 面经 2026；DS 的主轴是 Python Coding（含 DS&A）+ SQL + 实验设计 + Product Analytics（流媒体业务案例），看 Spotify DS 面经。三个岗位共用 Spotify values 的文化底色，但题型重心完全不同——投哪个岗位就按哪个岗位准备，公司级完整题型清单看 Spotify 公司页。
• Q5：没有大规模推荐 / 搜索经验，怎么准备 Spotify MLE？
  三个动作：第一，翻译经验——推荐 / 搜索 / 增长 / 数据经历都能映射到 Spotify 语境，主动说清你的系统如果面对亿级音频内容库、new release 冷启动、多目标 ranking 会怎么处理（现有系统的局限你要能自己点出来）；第二，补业务语言——把 listening time、skip rate、play-through、playlist 这些指标口径背到能张口定义的程度，SD 里每个决策都落回这些指标；第三，把 2-3 个最接近的项目按「概述 → 规模与取舍 → 反思与结果」三层重写，数字做速查表，确保深挖时不卡壳。