OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导。
virtual onsite一共包含三轮 coding 和一轮与 Hiring Manager 的沟通。整体感觉 Pinterest 的面试非常注重代码质量、沟通清晰度，以及ownership。网传pin的面试题很难，但其实还好。以下是我们的真实case分享。
第一轮 coding 面试考的是一道比较常规的 graph 题，但 twist 很有意思。题目是：给定一个城市地图，每条边代表一条单向道路，每条道路有一个开关（on/off），问从城市 A 到城市 B 是否存在一条路径，最多允许翻转 K 个开关使其变为可通行。candidate 建了一个变种的 BFS，状态包含当前 node 和已经 flip 了多少次。每次遇到关闭的道路，如果没超过 K，就尝试 flip 并加入队列。面试官非常注重变量命名和边界条件的处理，尤其是 flip 计数的逻辑是否能避免重复访问。
第二轮题目是一个典型的 LRU Cache + Eviction Hook 的变种。除了 get 和 put，还需要支持在元素被驱逐的时候触发一个 callback 函数。思路还是用双向链表 + HashMap，但额外需要在 evict 时正确触发回调。candidate 写完后和面试官详细讨论了线程安全的问题（没有想到会在算法面试问这些问题），包括是否需要加锁、是否支持并发访问等。他也问了如果 callback 执行时间太长，会不会影响主流程，candidate 提到了用异步处理的可能性。
第三轮是一个面试官自己设计的题，看得出来是实际遇到的系统问题：输入是一个日志系统的访问记录，格式是 (user_id, action_type, timestamp)，实现一个类支持以下两个方法：countUniqueUsers(start_time, end_time)，和 getUserActions(user_id, start_time, end_time)。candidate 先用两个 Map 做 indexing，一个按 user_id 索引，一个按 timestamp 排序的 list。countUniqueUsers 用 sliding window + HashSet 处理，getUserActions 直接 binary search 范围查找。面试官非常关心数据量大时的性能，还问了是否可以只用一个索引结构解决两个方法，这部分讨论挺深入。这也是最近的面试的趋势，考原题的概率越来越小了。
最后一轮是和 Hiring Manager 的聊天（HM competency），重点不是算法，而是聊 experience 和合作经历。他先简单介绍了团队正在做的一些 infra 工作，然后问 candidate 过去有没有从零设计某个系统、是否带过新人、有没有对 legacy code 进行重构。 candidate 重点讲了一个异步消息系统从 design 到 rollout 的过程，以及怎么推动整个团队 adopt 新工具。整个对话非常轻松，也很注重沟通方式和影响力。