思路上， Coinbase OA 往往带有很强的业务场景色彩，也就是偏向 OOD和系统实现。代码量虽然偏大，逻辑有些绕，但只要结构设计得当，AC 只是时间问题。下面复盘一下这道题的通关思路，核心是模拟一个账户系统的资金流转，每一关都在上一关的基础上叠加新需求。
Overall feeling
- 时间限制比较充裕，但代码量不小，需要耐心写清楚各种 edge case 和合法性检查。
- 题目描述比较清晰，但细节多（尤其是合法性条件），一定要先把所有规则读透。
- 语言不限，我用 Java 写的，Python 也完全可以。
Level 1：基础账户系统
Core requirements：维护多个账户，支持开户、转账、查询余额等操作。
Ideas:
- 用 HashMap<String, Long> 存用户名 → 余额。
- 每次操作前严格按题目要求校验合法性（账户是否存在、余额是否足够、金额是否合法等）。
- 转账成功后更新双方余额即可。
这个 Level 主要是热身，注意不要漏掉任何校验条件，写清楚 helper 方法会让代码更整洁。
Level 2：查询转出金额 Top N
在 Level 1 基础上，新增查询转出总金额最多的前 N 个账户。
Key points:
- 只有转账成功才累加转出金额。
- 需要额外维护一个 HashMap<String, Long> 记录每个账户的 totalOutgoing。
- 查询时，把所有账户信息收集起来，按转出金额降序、用户名升序排序，然后格式化输出指定格式。
排序可以用 Java 的 List + Comparator，或者收集到数组后排序。注意输出格式要严格匹配题目要求（包括空格、换行等）。
Level 3：延迟扣款（Scheduled Payment）
引入了定时扣款功能，难度明显上升。
核心设计:
- Use PriorityQueue（最小堆）维护所有待执行的扣款事件，按时间戳排序。
- 每次操作前，必须先把当前时间戳 currentTime 之前（含等于）所有到期的扣款全部处理掉。
- 处理扣款时：
- 检查账户余额是否足够。
- 成功则扣款、更新 totalOutgoing 等统计。
- 失败则按规则处理（题目一般会说明）。
- 扣款事件需要记录 payer、amount、scheduledTime 等信息。
优先队列的 Comparator 要按时间升序，记得处理完的事件要 poll 掉，避免重复执行。状态更新要和 Level 1、2 复用同一套逻辑。
Level 4：账户合并 + 历史查询（最难）
这是整个 OA 的高潮，增加了账户合并（Merge）和历史余额查询。
账户合并:
- 把 source 账户的所有资产（余额、totalOutgoing、未执行的定时扣款）转移到 target 账户。
- 转移后要把 source 账户标记为“已合并”或“无效”，后续操作到 source 时要返回失败。
- 定时扣款事件也需要重新绑定到 target 账户。
历史查询:
- 每次余额发生变化（转账、扣款、合并等）时，都记录一条历史记录（timestamp, newBalance 等）。
- 查询某个账户在某个时间点的余额时，遍历该账户的所有历史记录，找到最后一个 timestamp <= 查询时间 的状态。
Implement recommendations:
- 可以给每个账户维护一个 List<History>，History 类记录时间和余额。
- 合并时要把 source 的历史也合理处理（通常是把 source 的历史“快照”转移或标记）。
- 优先队列里的定时任务也要更新 payer 为 target。
这个 Level 代码量最大，状态比较多，建议把账户类封装一下（Balance, Outgoing, Histories, ScheduledPayments 等），代码会清晰很多。
Summary and suggestions
Coinbase 的 OA 整体玩的就是一个增量开发。强烈建议大家在 Level 1 和 Level 2 的时候就把面向对象的架子搭好，把异常处理和校验逻辑封装成独立的方法。如果不封装，到了后面满屏的条件判断和连环更新绝对会让你抓狂。沉下心来理顺逻辑，搞定它是没问题的。
若您正在攻坚此类高难度大厂笔试，我们团队——由牛津、普林斯顿背景及一线大厂（Google、Amazon、阿里）资深工程师组成，提供 OA ghostwriting 、笔试代考及 VO 辅助服务。我们深耕 HackerRank 等平台，通过远程无痕技术确保测试用例 100% 通过。无论遇到何种绕人的逻辑难题，我们都能助您稳扎稳打，高效通关。直接联系学长，让我们为您提供精准的实战支持，助力斩获心仪 Offer。
