Coinbase 的 CodeSignal 题有一个很鲜明的节奏：第一层先把数据结构跑起来，后面每一层都在原接口上追加能力。最容易浪费时间的地方不是 set 和 get，而是前两层没有把状态边界定死，等到 TTL、前缀查询和撤销操作出现，代码就开始互相打架。
这篇把题目拆成四级。开局先写一个可测试的内存 KV Store，后续只扩展，不推倒重来。
第一题：实现基础 KV Store
题目描述
实现 set(key, value)、get(key)、delete(key) 和 update(key, value)。不存在的 key 要返回清晰的结果，删除后不能继续被读到。
解题思路
主表直接用 Map<String, Record>。Record 先只放 value，所有写操作收敛到一处：先检查 key，再更新主表。delete 不要保留半失效标记，否则后面的扫描和 TTL 都要额外判断。每个操作结束立刻跑一组小测试：覆盖、删除不存在的 key、删除后再写入。
复杂度：四个基础操作都是 O(1)。
第二题：加入 prefixScan
题目描述
新增 scan(prefix)，按字典序返回指定前缀下仍然存在的 key-value 对。题目会把基础读写和扫描混在同一组测试里。
解题思路
先保持主表为唯一事实来源。输入规模不大时，遍历 key 后用 startsWith 过滤，再按 key 排序，逻辑短而稳。若接口说明给了大量扫描压力，再增加 TreeMap 索引；不要为了提前优化把读写路径拆成两份状态。
这里可对照 Coinbase 的四级 CodeSignal 递进题：每一级都依赖前一级的行为一致性，排序规则必须在第一版就写进测试。
复杂度：一次全表扫描为 O(n log n)，其中排序占主要成本。
第三题：TTL 过期和读路径清理
题目描述
setWithTTL(key, value, ttl) 写入带到期时间的记录；get、scan 和 update 都不能把已过期的数据当成有效数据。
解题思路
给 Record 增加 expiresAt，用单调一致的当前时间比较。写一个 readLive(key, now) 辅助函数：发现过期就从主表删除并返回空值；所有读取、更新、扫描都只经过它。这样不会出现 get 看不到、scan 却还返回的分叉行为。
TTL 边界要明确：now >= expiresAt 就过期。测试里至少放零 TTL、刚好到期、覆盖旧 TTL、扫描时碰到过期记录四种情况。
第四题：undo 和 redo
题目描述
在前面接口之上增加 undo() 和 redo()。撤销后再执行新写入，旧 redo 历史必须失效。
解题思路
每次改变状态前，把受影响 key 的完整旧快照压入 undo 栈：包括不存在、value 和 expiresAt。执行 undo 时恢复快照，并把当前快照压入 redo 栈。新写入成功后清空 redo 栈。不要只记录 value；TTL 是记录状态的一部分，漏掉它会让撤销后的过期时间不对。
这类递进题的关键不是背接口，而是让每次变更都可逆。写完后按“写入、更新、撤销、重做、再写入、重做失败”顺序走一遍，能很快抓到栈方向错误。
做题过程怎么安排
前二十分钟只做基础接口和测试，不给第三、四级留下隐藏债务。进入 TTL 后，先统一读路径，再补扫描。最后再做 undo/redo；即使最后一层未完成，也要保证已提交的层级没有回归。
Coinbase 的候选人记录里既有四级递进实现，也有工作风格题与 CodeSignal 组合出现的情况；一份美国 SWE 流程记录提到的也是按等级逐步解锁。准备时把“读写一致、过期一致、回滚一致”练成固定检查项，比只刷孤立题更有用。
FAQ
Coinbase OA 的后半段做不完，先保什么？
先保证已解锁层级的样例、边界和回归测试全部通过。递进题里，第二级一个错误会拖垮后面每一级。
TTL 为什么不能只在后台定时删除？
后台清理可以节省空间，但不能代替读路径判断。到期瞬间的 get 和 scan 仍要返回一致结果。
关于 CSINTERVIEWHELP
进 VO 之前，可以找 CSINTERVIEWHELP 做实时面试助攻和备考辅导。CSINTERVIEWHELP 深耕北美 IT 行业多年，已帮助万余名学生进入全球 500 强企业。导师来自一线大厂资深工程师和面试官，对 Coinbase 这类注重工程文化的公司的面试套路很熟悉。无论是 OA 题型解析、OA 辅导、VO 辅助、VO 模拟面试、VO 面试陪练还是系统设计辅助，都可以获得更有针对性的准备方案：CSINTERVIEWHELP · 服务详情
