最近刚结束 Pinterest VO ，四轮全部顺利通过，整体感觉比预想中友好。Pinterest 的面试没有特别偏的题，整体节奏也比较友好，但 coding 和 system design 的深度追问还是挺考验临场反应的。把每一轮的经历都写下来，给正在准备的同学参考。
整体流程
Pinterest 的 VO 流程是 CodeSignal 预筛 → 技术电话面 → Virtual Onsite，整个周期大概 3-4 周，推进速度在中等偏快。Onsite 四到五轮，我这次是四轮：BQ + 价值观考察、Coding、System Design、Coding。每轮 45 分钟，System Design 稍长一些接近一个小时。面试环境用的是 CoderPad，可以跑代码，比 Google Docs 好用很多。
Pinterest 有一个特别明显的风格：非常在意你解释思路的方式，代码写完之后接着追问 trade-off 和边界处理，几乎每轮都会有 follow-up，不会让你只是把答案交出去就完事。
Round 1：BQ + 价值观考察
这轮主要看你有没有把用户放在第一位的意识，以及能不能把复杂问题讲简单。
我被问到的两道题：
- 分享一个你简化复杂系统的例子
- 当用户体验和业务指标发生冲突时，你如何把用户放在第一位？
我用 STAR 框架讲了之前优化推荐流去重服务的经历。通过调整架构和缓存策略，把接口响应时间压下来，同时降低了系统负载。我把前后数据对比整理成图表直接展示给面试官，对方对这一块挺认可的。
建议提前准备 2-3 个能体现「简化系统」和「用户优先」的故事，最好有具体数字。
Round 2：Coding
题目要求从一批数据中，找出指定类别下分数最高的前 k 条记录。
基础做法是用 HashMap 按类别归类，每个类别下的记录按分数从高到低排序，查询时直接截取列表头部的前 k 条。
面试官追问了时间和空间复杂度，还探讨了插入和查询频率对数据结构选型的影响，以及有没有进一步优化的思路。如果插入频繁、查询也频繁，可以考虑每个类别维护一个小根堆，控制堆大小为 k，这样插入时动态维护 Top K，查询直接返回。
Round 3：System Design
这道题是设计个性化首页推荐流，涵盖相关 Pin 的召回与实时排序。
我从需求拆解入手，先梳理了底层数据结构（Pin、Board、User Graph），然后分别讲了离线部分用 Spark 做批量计算，实时部分用 Flink + Kafka 做流式处理。排序层用了 GNN 加特征工程，缓存侧搭配 Redis 和 CDN 做性能加速。一致性方面，因为读多写少，我采用了最终一致性模型。
现场画了 3 张架构图，从客户端请求进来，经过 API Gateway，到 Ranking Service，再到 Feature Store 取特征。面试官全程最关注的点是：这套设计能否扛住 10 亿 Pin 级别的高 QPS 场景。
准备时一定要把高并发、缓存、一致性这几个点想清楚，面试官会顺着 QPS 和延迟一直追问。
Round 4：Coding
给了一组无序的车票，每张票记录了一个出发地和目的地，所有票可以连成一条完整的路线，需要恢复出正确的行程顺序。
先用 Map 存下每张票的出发地 → 目的地映射，再用一个 Set 记录所有目的地。没有出现在目的地集合里的出发地就是整个路线的起点，然后顺着 Map 一步步还原后续站点。
面试官追问了可能遇到的边界情况以及对应的处理策略，比如是否有环、是否存在多条独立路线、输入为空或只有一张票的情况。
另外还有同学遇到过「海量数据下怎么设计索引来支持多条件查询，以及进一步压缩索引成本」的题。基础方案用多索引查得快但占空间；限制一个索引就压缩成单索引 + 扫描；完全不让建索引就用二分定位 + 全扫，空间最小但查询最慢。Follow-up 会追问数据到数十亿且只能保留一个索引时怎么权衡。
整体感受
Pinterest 面试整体节奏比较友好，面试官沟通方式都很直接，不会刻意为难你。但 follow-up 追问是必然的，每道题都会在你写完之后继续挖 trade-off、边界情况、扩展性，所以不能只是把代码交出去，要全程保持思路清晰、能随时接追问。
写在最后
最近 Pinterest、TikTok、Meta、Google、IBM 等公司的 OA 和 VO 都在持续。Interview Show 专注北美技术岗位的面试辅助，团队来自一线大厂，OA 辅助、VO mock、System Design 和 BQ 打磨都有覆盖。面前面都会提前 mock，面时不慌，有需要的同学随时可以聊。
祝大家顺利拿到 Pinterest Offer！