高频面试问题与回答框架：常见问题分类、答题结构、公司侧重点差异
算法负责人面试中，面试官不再只关注你是否“会做”，更关注你“怎么做决策”、“如何落地”以及“为什么选这个方案”。本章提炼三条高频追问路径，帮你构建可复用的回答框架。
面试问答卡片
面试问题：请介绍一个你主导的推荐系统核心算法升级项目，从方案选型到上线你是怎么做的？
面试官考察点：①是否真·Owner而非参与者；②技术选型背后的权衡逻辑；③量化结果的严谨性。
回答框架：STAR框架 + 方案PK。S: 业务目标（提升CTR 5%）；T: 老模型进入瓶颈，特征/模型双约束；A: 在DIN和BST之间选择BST，因用户行为序列长且需要捕捉跨域兴趣；R: 离线AUC+0.8%，在线CTR+3.2%，全量无负向。
简短示例回答：项目背景是首页推荐CTR停滞，老模型特征交叉能力弱。我们对比了DIN和BST，发现BST的Transformer结构更适合我们长序列场景。离线验证后灰度10%流量，CTR提升3.2%，全量后CTR稳定提升，线上无负向。我们同时做了A/B时长监控，保证时长不变。
可能追问：①为什么不用DIEN？②特征工程做了哪些？③灰度期间有没有出现bad case？④如果CTR提升但是时长下降你会怎么决策？
避坑提醒：避免只讲技术细节而不讲决策过程；不要回答“我是用xxx模型效果很好”就结束，必须包含“为什么选它”和“不选什么”。
面试问题：你们团队是如何做特征工程的？有没有遇到过线上特征实时性导致模型效果变差？
面试官考察点：①对特征时效性的理解；②工程与算法的协同能力；③线上坏样本的处理经验。
回答框架：问题 → 分析 → 解决方案 → 效果验证。先说特征实时性带来的数据穿越问题，然后给出特征版本对齐方案（如特征快照+离线回溯），最后说监控指标。
简短示例回答：我们曾因用户实时点击特征未做时间截断，导致离线AUC高但在线无收益。分析发现线上模型看到了未来点击。解决方案：特征生成时绑定action_time，离线训练用T-1日快照，并且在线serving只取当前时间之前的特征。修正后在线CTR匹配离线预期，提升了2.1%。
可能追问：①怎么确保线上serving特征和离线训练分布一致？②特征回填的时效性如何保证？③有没有试过用实时特征做增量学习？
避坑提醒：不要只说“我们做了特征工程”，要说出具体的坑和排查方法；不要忽略特征工程对团队工程能力的要求。
面试问题：你们团队如何评估推荐系统的收益？除了CTR/CVR还看哪些指标？
面试官考察点：①是否具备多目标平衡意识；②长期价值与短期指标的关系；③能否向业务方解释指标。
回答框架：分类指标（核心指标+辅助指标+长期指标）→ 取舍原则 → 具体案例。
简短示例回答：我们搭建了三级指标体系：①核心：CTR、CVR、GMV；②辅助：用户停留时长、次日留存、深度转化；③长期：用户满意度调研、7日LTV。当CTR提升但时长下降时，我们会用“时长+CTR”联合收益矩阵决定是否全量，同时对头部用户做长尾推荐保护。
可能追问：①如果CTR和时长冲突，你最终怎么拍板？②从业务方角度看，他们更关心GMV，你怎么拉齐认知？③有没有因为优化某个指标导致另一个指标下跌的case？
避坑提醒：不要只背指标名字，要讲清楚每个指标的业务含义和trade-off；避免说“我们只看CTR”，显得格局太小。
常见问题分类与回答要点
| 问题分类 | 典型问题示例 | 核心回答结构 | 公司侧重点差异 |
|---|---|---|---|
| 项目深度 | 介绍一个最具挑战的算法项目 | STAR + 方案PK | 字节重视收益量化；阿里重视业务抽象 |
| 系统设计 | 设计一个大规模实时推荐系统 | 分层架构 + 关键模块决策 | 百度重视延迟；美团重视多场景复用 |
| 团队管理 | 如何定下周OKR并驱动团队执行？ | 目标拆解 → 资源分配 → 风险预案 | 腾讯重视协作；字节重视结果导向 |
| 技术前沿 | 对多模态推荐/LLM在推荐中的应用怎么看？ | 技术理解 + 落地可行性分析 | 快手重视短视频多模态；抖音重视实时性 |