这场是最近一位同学拿到的 Google L4 Software Engineer VO 面试，整体节奏很典型：前面聊背景很快，直接进入 coding + follow-up。
题目是现场给的，没有公开原题
You are given a list of user actions in a system. Each action is represented as:
(user_id, timestamp, action_type)
A user is considered “inactive” if they have no activity within a sliding window of size K minutes.
Design a system to support:
- addAction(user_id, timestamp, action_type)
- getInactiveUsers(current_timestamp)
Return all users that are inactive at the given time.
Constraints:
- Actions come in real-time (not sorted)
- Up to millions of users
- Need near real-time query performance
面试一开始，面试官直接问：
“你觉得这个更像是一个 data structure 题，还是 system design？”
候选人这里没有犹豫，说这是一个 data structure + streaming 场景结合，先做单机设计，再讨论扩展。
这一点非常关键。
接下来进入澄清环节：
候选人主动确认了几个点：
- K 是固定的吗（是固定窗口）
- 是否需要精确到秒（是）
- 用户是否会重复出现（会）
- inactive 是否要持续返回（是 snapshot）
面试官反馈：good clarification，继续。
核心思路其实很典型：
候选人提出用：
- HashMap：记录每个 user 的 latest timestamp
- 同时维护一个 时间排序结构（比如 min-heap 或 ordered map）
逻辑是：
- 每次 addAction → 更新 user 最新时间
- 同时更新排序结构
- 查询时，从最早时间开始扫，找出小于
current - K的用户
但这里面试官马上追问：
“如果用户很多，这个 scan 会不会很慢？”
候选人这里没有硬顶，而是马上优化：
👉 引入 lazy cleanup + 双结构设计
具体描述（不写代码，用语言）：
- 一个 map 存最新时间
- 一个队列（按时间 append）
- 查询时：
- 从队列头开始弹
- 如果这个时间已经不是该用户的最新记录 → skip
- 否则判断是否过期
这个点讲清楚之后，面试官明显点头。
接下来进入第二轮追问（Google 很爱这一段）：
“如果这是分布式系统怎么办？”
候选人这里展开：
- 按 user_id 做 shard
- 每个 shard 本地维护 inactive
- 上层做 aggregation
同时补充了一个很关键的点：
👉 clock skew / timestamp 不一致问题
这个回答加分很明显。
然后面试官继续压：
“如果 query 非常频繁呢？”
候选人给了两个方向：
- 缓存结果（比如每秒更新一次 inactive set）
- 使用类似时间轮（time bucket）来优化
如果你最近有 VO 面试，提前准备这些 真实题型和思路，会非常关键。
我们也有代面试，面试辅助，OA代写等服务助您早日上岸~
