12周数据工程师面试学习计划模板：从SQL到系统设计

正确的判断是：在12周内完成从SQL基础到系统设计的全链路准备，必须把“刷题”变成“结构化复盘”，而不是盲目刷题；把“面试演练”当成“情境复盘”，而不是单纯的自我介绍；把“薪资期望”写成“分段谈判”，而不是一次性抛出。只要坚持每周固定产出复盘文档、模拟面试和一次系统设计深度练习，就能在技术面、行为面和薪资谈判三条线上同步突破。

一句话总结

适合谁看

本模板针对以下三类读者：

已有1‑2年数据工程实战经验、准备转入FAANG或独角兽的工程师；
计算机或信息管理硕士毕业、但缺乏系统设计实战的新人；
在此前面试中被技术深挖卡住、需要一套可量化进度的复盘框架的求职者。

如果你符合以上任一画像，并且对自己的学习时间只能投入每周15‑20小时，那么这份12周计划的每一步都能直接落地。

核心内容

第1‑2周：SQL 基础与高阶查询

目标：在两周内从 SELECT * 到窗口函数、递归 CTE 完全掌握。
场景：在上周的 debrief 会议中，Hiring Manager 直接指出：“候选人如果连基本的窗口函数都写不出来，就别想进入我们的数据管道团队。”因此，这两周必须把 “不是只会写单表查询，而是能在 5 分钟内写出带分区的累计指标”。
产出：完成 30 题 LeetCode SQL（难度从 Easy 到 Hard），每题写 200 字复盘，尤其标注“时间复杂度”和“可索引列”。
练习：使用公司公开的 Kaggle 数据集，自己设计一个 ETL 流程，至少包括一次子查询和一次窗口函数。

第3‑4周：Python/PySpark 数据处理

目标：从 Pandas 基础到 PySpark DataFrame 的分布式算子，做到“不是只会本地脚本，而是能写出可横向扩展的 Spark 作业”。
场景：在一次 HC（Hiring Committee）会议上，Data Platform Lead 说：“我们不想面试只会 pandas 的人，必须看到你能在 10 GB 数据上跑完一次聚合”。因此，这两周必须在本地搭建 mini‑cluster，跑一次 20 GB 的 Parquet 合并。
产出：完成 5 项 Spark 作业，每项作业包括代码、执行计划截图和调优笔记。
练习：把第2周的 SQL 题目迁移到 Spark SQL，记录性能差异。

第5‑6周：数据建模与仓库设计

目标：从 Star Schema 到 Data Vault，能够在 30 分钟内绘制完整的模型图。
场景：在一次面试官的现场白板环节，面试官常问：“如果业务要求实时查询用户最近 30 天的活跃度，你会怎么设计表？”正确的判断是：不是直接在事实表加大量冗余，而是使用分区 + 预聚合表。
产出：为一个电商订单系统设计 Star Schema，写 1000 字设计说明，列出每张表的主键、分区键和常用索引。
练习：使用 dbt（或 Airflow）实现模型的每日增量加载，并在本地跑一次完整的测试。

第7‑8周：数据质量与监控

目标：掌握 Great Expectations、Monte Carlo 等工具，能够实现“不是只写一次校验脚本，而是把校验嵌入 CI/CD”。
场景：在上一次系统设计面试的 debrief 中，面试官指出：“候选人如果只说监控指标，却没有自动化校验，方案缺乏可落地性”。因此，这两周必须把每个关键表的质量规则写成 Expectation Suite，并在 GitHub Actions 中跑。
产出：为第5‑6周的仓库模型编写 20 条数据质量规则，生成监控仪表盘的截图。
练习：模拟一次数据回滚，验证质量规则是否能捕获异常。

第9‑10周：系统设计（大规模数据管道）

目标：从需求拆解到容量估算、选型、故障恢复，完整呈现一个可扩展的数据流水线。
场景：在一次 hiring manager 对话里，经理说：“我们现在一天要处理 500 TB 的日志，你的设计必须在 2‑3 小时内给出数据流向、分区策略和容错方案”。因此，这两周必须练习“不是只给出组件列表，而是交付完整的时序图和成本模型”。
产出：完成 2 份系统设计文档（每份约 2500 字），分别针对实时流处理（使用 Kafka + Flink）和批处理（使用 Spark + Delta Lake），并在文档末列出 3 项关键指标的监控方案。
练习：在本地使用 Docker‑Compose 搭建 Kafka‑Flink‑Postgres 环境，跑一次 5 GB 的模拟日志。

第11‑12周：行为面、薪资谈判与全流程模拟

目标：把 STAR 结构化为“不是只说项目成果，而是把每个冲突、决策过程、结果量化”。
场景：在上一次面试的 feedback 中，HR 明确表示：“行为面如果只是讲‘我很合作’，缺乏冲突解决案例，容易被筛掉”。因此，这两周必须准备 5 条冲突案例，每条包括情境、行动、量化结果。
产出：完成 3 场全流程模拟面（技术面、系统设计、行为面），每场后记录 30 分钟 debrief，形成复盘文档。
薪资谈判：明确 base $150K、RSU $80K/年、bonus $30K，采用分段谈判策略：先锁定 base，再根据 RSU 计划谈可变部分。

准备清单

订阅 LeetCode Premium，挑选 80 题 SQL+Python+系统设计。
搭建本地 mini‑cluster（Docker‑Compose 包含 Spark、Kafka、Postgres），确保每周至少跑一次完整的 ETL。
完整复盘模板（包括问题、解法、时间、复盘要点），每完成一题即填。
系统性拆解面试结构（PM面试手册里有完整的[面试环节拆解]实战复盘可以参考），把每一轮的考察点写进表格。
预先准备 5 条行为面冲突案例，使用 STAR 框架，确保每个案例都有量化结果。
薪资谈判脚本：列出 base、RSU、bonus 三项，准备行业对标数据。
每周末进行一次 1 对 1 模拟面，记录面官的即时反馈。

常见错误

错误一：刷题不做复盘

BAD：候选人在 LeetCode 上刷完 200 题后，面试官问 “请解释下你这道窗口函数的时间复杂度”，答不上来。

GOOD：每完成一题后，用 200 字写出“不是只会跑通，而是要解释为什么选择该窗口函数、其时间复杂度以及在大数据集上的可行性”。复盘文档在模拟面时可以直接引用。

错误二：系统设计只列组件

BAD：在系统设计面，候选人画出 Kafka → Flink → Hive 的流向图，却没有说明分区键、吞吐量估算和故障恢复。面官直接打 “缺乏可落地性”。

GOOD：在图旁边附上每秒 200 K 事件的分区策略、Kafka 副本数、Flink checkpoint 间隔以及回滚恢复时间 < 5 分钟的计算。这样展示的是完整的容量规划和容错方案。

错误三：行为面只讲软技能

BAD：面试官问 “描述一次你与数据科学家冲突的经历”，候选人回答 “我们通过沟通解决了”。没有量化、没有具体行动。

GOOD：候选人说 “在 A 项目中，我的 ETL 产出延迟 30% 超出 SLA。与数据科学家沟通后，我把数据抽样比例从 100% 降到 70%，并在两天内将延迟降至 5%”。这里展示了冲突、行动、量化结果。

FAQ

我只有 10 周时间能投入，计划还能完成吗？

结论：可以，但需要把每周的 15‑20 小时压缩到 10‑12 小时，并把“不是全量刷题，而是重点突破”。在第1‑2 周只保留窗口函数和递归 CTE，其他 SQL 题目留到第5‑6 周的系统设计复盘时统一回顾。实际案例是某位候选人在 10 周内只完成 60% 题目，却在每题后写了 300 字复盘，最终在系统设计面获得了 90% 的通过率。

面试官经常问 “如果我们要把每天 500 TB 的日志实时分析，你会怎么选技术栈？” 我该怎么回答？

结论：回答必须包含“不是只说用 Kafka”，而是给出完整的选型理由、容量估算和成本模型。示例答案： “我们会采用 Kafka 作为高吞吐入库层，使用 12 节点的 Confluent 平台，分区数设为 3000，确保每秒 200 K 事件；下游使用 Flink 做实时聚合，状态后端选 RocksDB，checkpoint 间隔 5 分钟；为了容错，Kafka 设置 3 副本，Flink 开启 savepoint，每天自动快照”。这种结构化回答能一次性覆盖需求、选型、扩展性和故障恢复。

薪资谈判时我该如何打开话题，避免一次性被压低？

结论：先锁定 base，再分段讨论 RSU、bonus。一个有效的开场是：“根据我的经验和行业对标，我的 base 期望是 $150K”。如果对方提出 $130K，你可以回应：“我理解预算限制，但我更关注长期激励，是否可以把 RSU 调整到 $100K/年？”这种“不是一次性报价，而是分段谈判”的技巧在内部数据中显示，采用分段谈判的候选人在最终总包上平均提升 12%。

以上即为 12 周数据工程师面试学习计划的完整模板。严格按表执行，确保每周产出复盘文档、一次系统设计练习和一次模拟面，面试通过率将显著提升。祝你在下一个面试季拿到理想的 $150K base + $80K RSU + $30K bonus 的 offer。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。