美国Netflix software engineer ng面经
美国Netflix software engineer ng面经 (English Translation Coming Soon)
Netflix上岸SDE，我只用了这三招
Netflix的技术面试非常注重与其实际业务场景的结合。题目往往不是孤立的算法题，而是包装在视频流、用户数据、推荐系统等业务场景下的综合问题。
第一题: 算法 - LRU Cache
Question: Design a Data structure that follows the constraints of a Least Recently Used (LRU) cache.
Implement the LRUCache class: LRUCache(int capacity) Initializes the LRU cache with positive size capacity. int get(int key) Return the value of the key if the key exists, otherwise return -1. void put(int key, int value) Update the value of the key if the key exists. Otherwise, add the key-value pair to the cache. If the number of keys exceeds the capacity from this operation, evict the least recently used key.
The functions get and put must each run in O(1) average time complexity.
解析：
这道题是LeetCode Hard难度的经典题目，也是FAANG面试中的常客。对于Netflix这样需要大量缓存视频元数据、用户播放历史等信息的公司来说，高效的缓存策略至关重要。这道题完美地考察了你对数据结构（哈希表、双向链表）的组合运用能力和在O(1)时间复杂度下实现复杂逻辑的能力。
1. 核心思路分析: 题目要求get和put操作都是O(1)时间复杂度。我们来分解一下需求：
get(key): 需要快速查找到key对应的value。什么数据结构查找是O(1)？哈希表（Hash Map）。 put(key, value): 同样需要快速查找key是否存在。如果存在，更新value；如果不存在，插入新的key-value。这也指向了哈希表。 难点来了: 当缓存满了，需要淘汰"最久未使用"的元素。这意味着我们需要一个能记录元素使用顺序，并且能快速在头部插入（最新使用的）和在尾部删除（最久未使用的）的数据结构。什么数据结构能满足O(1)的插入和删除？链表。而为了能方便地删除任意节点（因为一个中间节点被访问后，需要移动到头部），我们需要知道它的前驱和后继节点，所以双向链表（Doubly Linked List）是最佳选择。
2. 数据结构组合: 我们的解决方案是"哈希表 + 双向链表"。
哈希表 (HashMap): key是输入的key，value是对应的双向链表节点的引用（指针）。这样，我们可以通过key在O(1)时间内定位到链表中的节点。 双向链表 (Doubly Linked List): 链表中的每个节点存储key, value。我们维护一个头部（head）和尾部（tail）指针。越靠近头部的节点表示最近被访问过，越靠近尾部的节点表示最久未被访问。
3. 操作流程:
get(key): 通过哈希表查找key。如果不存在，返回-1。 如果存在，获取到对应的链表节点。 将这个节点从它当前的位置移动到链表的头部（表示它刚刚被访问过）。 返回节点的值。 put(key, value): 通过哈希表查找key。如果key已存在： 更新节点中的value。 将该节点移动到链表头部。 如果key不存在： 检查缓存是否已满（len(hash_map) == capacity）。 如果已满，删除链表的尾部节点（最久未使用的），并同时从哈希表中删除对应的key。 创建一个新的节点，存储新的key和value。 将新节点插入到链表头部。 在哈希表中添加新的key和它对应的节点引用。
代码实现 (Python):
class DLinkedNode: def init(self, key=0, value=0): self.key = key self.value = value self.prev = None self.next = None
class LRUCache: def init(self, capacity: int): self.cache = {} self.head = DLinkedNode() self.tail = DLinkedNode() self.head.next = self.tail self.tail.prev = self.head self.capacity = capacity self.size = 0
def _add_to_head(self, node):
node.prev = self.head
node.next = self.head.next
self.head.next.prev = node
self.head.next = node
def _remove_node(self, node):
node.prev.next = node.next
node.next.prev = node.prev
def _move_to_head(self, node):
self._remove_node(node)
self._add_to_head(node)
def get(self, key: int) -> int:
if key not in self.cache:
return -1
node = self.cache[key]
self._move_to_head(node)
return node.value
def put(self, key: int, value: int) -> None:
if key in self.cache:
node = self.cache[key]
node.value = value
self._move_to_head(node)
else:
node = DLinkedNode(key, value)
self.cache[key] = node
self._add_to_head(node)
self.size += 1
if self.size > self.capacity:
removed = self.tail.prev
self._remove_node(removed)
del self.cache[removed.key]
self.size -= 1
Follow-up Questions:
如果要求是LFU (Least Frequently Used) Cache，你会如何修改你的设计？（需要额外在节点中记录访问频率，并可能使用一个频率到双向链表的哈希表来管理）。 这个实现在多线程环境下是安全的吗？如果不是，你会如何改进？（需要加锁，比如使用threading.Lock）。
第二题: 系统设计 - 设计Netflix的"Top 10"功能
Question: Design the system that generates and displays the "Top 10" list on Netflix, which is updated daily.
解析：
这是一个非常好的New Grad系统设计题。它不像"设计整个Netflix"那样宽泛，而是聚焦于一个具体、真实且有挑战的功能。它考察了你对数据处理、分布式系统和大规模服务设计的理解。
1. 需求分析 (Requirement Clarification):
功能性需求: 为每个国家/地区生成一个Top 10的电影/剧集列表。 列表每天更新一次。 用户打开App时能快速看到这个列表。 非功能性需求: 高可用性 (High Availability): Top 10列表必须随时可用。 低延迟 (Low Latency): 用户加载列表的速度要快。 准确性 (Accuracy): 排名需要准确反映过去24小时的观看热度。 可扩展性 (Scalability): 系统需要能处理全球数亿用户的观看数据。
- 核心指标定义: 如何定义"热度"？最直接的指标是"观看次数"或"观看时长"。我们可以简化为"过去24小时内，点开并观看了至少2分钟的独立用户数"。
3. 高层架构设计: 我们可以把系统分为两部分：离线计算部分和在线服务部分。
离线计算 (Offline Computation): 数据源: 用户的观看事件流。每当一个用户播放视频，一个事件（如{userId, contentId, watchTimestamp, country}）就会被发送到数据管道中（比如Kafka）。 数据处理: 使用一个大规模数据处理框架（如Spark或Flink）来处理这些事件。我们可以设置一个每天运行一次的批处理任务（Batch Job）。 计算逻辑: 任务启动后，读取过去24小时的观看事件。 按country和contentId进行分组。 计算每个contentId在每个country下的独立userId数量。 对于每个country，将contentId按计算出的热度降序排序，取前10名。 结果存储: 将计算出的Top 10列表存储到一个能被在线服务快速读取的数据库中。考虑到读取速度和数据结构（每个国家一个列表），NoSQL数据库如Redis或DynamoDB是很好的选择。我们可以用country作为key，Top 10的contentId列表作为value。
在线服务 (Online Service): API服务: 创建一个微服务（Top10 Service），专门负责提供Top 10列表。 API端点: 设计一个简单的API，如GET /api/v1/top10?country=CA。 服务逻辑: 当收到请求时，服务直接从Redis/DynamoDB中读取对应国家的结果并返回。 CDN缓存: 为了极致的低延迟和可用性，我们可以将API的返回结果在CDN（内容分发网络）上缓存一天。这样，绝大多数用户的请求甚至都不会到达我们的API服务，而是直接由离用户最近的CDN边缘节点返回，速度极快。
4. 数据模型:
Redis中的数据结构: 可以使用哈希表（Hash）。 Key: top10 Field: CA (国家代码) Value: ["contentId1", "contentId2", ..., "contentId10"] (JSON字符串)
### 5. Follow-up Questions:
如果需要实时更新Top 10列表，而不是每天一次，你会如何修改设计？（需要从批处理转向流处理，使用Spark Streaming或Flink来处理实时事件流，并可能使用一个带有排序功能的缓存结构，如Redis的Sorted Set）。 如何处理数据倾斜问题？（比如某个热门剧集的数据量远超其他，可能导致Spark任务中某个executor负载过重。可以通过加盐、两阶段聚合等方式解决）。 如何确保计算结果的准确性？如果批处理任务失败了怎么办？（需要有监控和告警机制，以及任务重试逻辑。在任务成功完成前，在线服务继续提供前一天的旧列表）。
行为面试与文化匹配
Netflix的文化面试是其招聘流程中最具特色的部分。面试官会深入挖掘你的过往经历，来判断你是否符合其著名的文化准则。
核心文化理念: Freedom & Responsibility (自由与责任): 公司给予员工极大的自由度，但同时也要求员工具备高度的责任心和自我驱动力。 Context, not Control (情境，而非控制): 领导者的职责是提供清晰的上下文，而不是事无巨细地控制员工如何工作。 Highly Aligned, Loosely Coupled (高度一致，松散耦合): 团队目标高度一致，但执行方式上保持独立和灵活。 Candid Feedback (坦诚沟通): 鼓励直接、坦诚、建设性的反馈。
行为面试问题示例:
Question: Tell me about a time you had a strong disagreement with a colleague or your manager. How did you handle it, and what was the outcome?
解析:
这个问题直接考察你处理冲突、沟通反馈和坚持己见（当你是对的时候）的能力。一个糟糕的回答是"我听从了经理的安排"或者"我们争吵了一番但最后还是我妥协了"。Netflix欣赏的是基于逻辑和数据的理性探讨。
STAR方法回答示例:
Situation (情境): 在我之前的一个实习项目中，我所在的团队负责优化一个推荐服务API的性能。我的经理提出了一个方案，建议通过增加更多的缓存层来降低数据库的压力。这是一个看似合理的常规做法。
Task (任务): 我的任务是实现这个多层缓存方案。但在进行初步的技术调研和性能分析时，我发现问题并非出在数据库的读压力上。
Action (行动): 数据驱动的分析: 我没有立即开始写代码，而是花了一天时间，使用性能分析工具（Profiler）对API的调用链路进行了详细的分析。我发现，API响应慢的主要瓶颈（约70%的时间）是由于服务内部一个复杂的业务逻辑计算，而不是数据库查询。 准备替代方案: 基于我的发现，我设计了一个替代方案：将那个复杂的计算逻辑进行算法优化，并将其结果异步计算并缓存，而不是每次API调用时都实时计算。我做了一个简单的PoC（概念验证），证明我的方案可以将API的P95延迟降低约50%。 坦诚沟通: 我主动预约了和经理的一对一会议。我首先肯定了他方案的合理性（在很多场景下增加缓存是有效的），然后展示了我的性能分析数据，清晰地指出了我们面临的真正瓶颈。接着，我演示了我的PoC结果，并解释了我的替代方案如何能更直接、更高效地解决问题。 寻求共识: 我没有说"你的方案是错的"，而是说"我认为我们可能面临一个不同的问题，这是我的数据，以及一个可能的替代思路，您觉得呢？" 我将这次沟通定位为一次基于数据的技术探讨，而不是挑战权威。
Result (结果): 我的经理对我的深入分析和主动性表示赞赏。在仔细评估了我的数据和方案后，他同意我的判断，并支持我带领一个小任务组去实现这个优化。最终，我们成功将API的P95延迟降低了60%，远超最初的目标。这次经历也让我和经理之间建立了更强的信任关系。他之后也给了我更多的自由度和责任去探索技术方案选型。