面经 | Backend / Data Platform | 🔥🔥🔥 | Snowflake
2026(9月) Software Engineer @ Snowflake US | Virtual Interview | 😐 Neutral | Medium-Hard | Pending
三轮：coding、system design，然后是 data / system deep dive。
Round 1 — Coding
题目是一个 task executor，支持两个操作：
addTask(taskId, priority, timestamp)
executeTask()
executeTask 每次返回当前 priority 最高的 task。如果 priority 一样，就按 timestamp 决定。
比较麻烦的是同一个 taskId 可以被 add 多次。一个 taskId 只要已经执行成功，后面 heap 里剩下的同 id record 都要跳过。
follow up：completedTaskIds 会不会一直变大。
这里开始讨论 history 怎么清理。如果 taskId 永远可能重新出现，那不能随便删。如果系统能定义 task lifecycle / retention window，就可以按 retention 做 cleanup。
最后又加了 cancelTask(taskId)。cancel 以后，已经在 heap 里的 record 不要求立刻删，execute 时跳过。
Round 2 — System Design
Design a job scheduler。
用户提交 job：jobId、tenantId、priority、resource requirement、scheduled time。scheduler 负责把 job 分给 worker。
先聊最基本的 submit / queue / dispatch。
worker 拿到 job 以后挂了怎么办。
用了 lease。worker 拿任务的时候记录 lease expiration，没 heartbeat 就重新变成 runnable。
如果 worker 实际已经跑完，但是 completion message 丢了呢。
这就到 retry 和 duplicate execution。
还问了 multi-tenant。一个 tenant 一次提交很多 job，不能让其他 tenant 一直饿死。
最后是 scheduler failover。job state、lease、retry count 都不能只放进程内存里。新的 scheduler 接管以后，需要知道哪些 pending、哪些 running、哪些 lease 已经过期、哪些已经 completed。
Round 3 — Data / System Deep Dive
题目是：两个 database 都有 PB 级数据，怎么做同步。
然后是一串 follow-up：
- 如果目标端处理比源端产生 change 慢怎么办
- schema change
- 某个 partition 同步失败了，但其他 partition 已经走到很后面
最后几分钟聊项目。问之前有没有做过 data consistency / migration 类问题。怎么验证 source 和 target 一致，如果数据量太大没法逐行 compare 怎么办，怎么知道 migration 可以 cut over。
BQ：Tell me about a project where the original plan had to change.