有个朋友最近面试，卡在一个很普通的问题上。
面试官问他：“你这个项目里，最难的一步是什么？”
他愣了一下。
不是不会答。他学过很多东西，SQL 窗口函数、Spark 调优、数仓分层、指标口径、BI 看板，收藏夹里教程多到可以开个小卖部。可真让他说一个项目里最难的一步，他只能说：“主要是数据清洗比较麻烦。”
这句话不能说错。
但它太轻了，像一张没盖章的纸。
教程教的是知识点，面试问的是证据
很多数据从业者有个误会：学得越多，项目就越好讲。
实际不是这样。
教程通常按知识点组织。今天学 join，明天学分区，后天学拉链表，再后来学一个完整电商数仓案例。学的时候很充实，像把工具箱塞满了。
可面试不是让你背工具箱目录。
面试官真正想听的是：你在什么场景里遇到了什么问题，为什么选择这个方法，过程中怎么判断对错，最后留下了什么结果。
这四件事，教程往往不会替你准备。
所以很多人学了 30 个教程，最后讲项目还是像在背课程大纲：
- 用了 MySQL；
- 用了 Spark；
- 做了离线数仓；
- 做了可视化大屏；
- 最后提升了效率。
听起来很完整，细问就散。
面试官只要追一句：“你为什么这么分层？”“这个指标为什么这么算？”“异常数据怎么处理？”“结果怎么验证？”很多回答就开始发虚。
不是人不努力，是学习没有变成证据。
一个能讲清的项目，至少有 4 个钉子
我比较建议把项目复盘成 4 个钉子。
第一个钉子，是场景。
不要一上来讲技术栈。先讲这个项目为什么存在：业务每天手工导数，销售和财务对不上，活动复盘要等 2 天，还是老板每周都在群里问同一个数。
一个项目没有场景，就像没有地面的梯子。技术再多，也不知道往哪里靠。
第二个钉子，是选择。
你为什么用这套方案？为什么不是另一套？为什么先做离线而不是实时？为什么先修口径而不是先做大屏？普通数据从业者最容易漏掉的，就是这一层判断。
第三个钉子，是证据。
你怎么知道自己做对了？是新旧口径对比过，还是抽样核对过？是和业务确认过异常规则，还是用历史数据回放过？如果只说“上线后运行正常”，这个证据太薄。
第四个钉子，是结果。
结果不一定非要写成“提升 80%”。很多数字没法证明，就不要硬编。你可以写得更朴素：
- 原来每周手工汇总 5 张表，后来固定成 1 个口径；
- 原来活动复盘要等到周三，后来周一上午能出第一版；
- 原来两个部门各算一套销售额，后来至少知道差异来自哪里。
这些数字没有那么刺激，但可信。
你缺的可能不是新教程，而是项目复盘习惯
很多人学新东西有快感。
打开一个教程，跟着跑通，截图，收藏，心里很踏实。可是项目能力不在“跑通”那一下，而在你能不能解释它为什么这样跑。
下一次你做完一个需求，不要急着把它扔进“已完成”文件夹。
花 15 分钟写一张复盘卡就行：
- 这个需求最开始是谁提的？
- 如果不做，会造成什么麻烦？
- 我做了哪 2 个关键选择？
- 中间出现过什么分歧或异常？
- 我怎么验证结果没错？
- 下次别人接手，最该看哪份材料？
这张卡不一定给别人看。
它是给未来的你看的。面试、晋升、写简历、跟老板复盘的时候，你会感谢现在这个有点麻烦的自己。
因为到那时，你讲的就不是“我学过 Spark”，而是“我在一次订单口径重算里，为什么没有直接改 SQL，而是先做了新旧口径对照表”。
这两句话差很多。
前一句像学生。
后一句像做过事的人。
学习要落到一个真实题场里
如果你现在正在学数据分析、数仓、Spark、AI 问数，我建议你给自己找一个真实题场。
真实题场不一定来自公司大项目。可以是一个公开数据集，一个你熟悉的业务场景，一个过去做过但没复盘好的需求。
关键是别只跟教程走。
你要逼自己回答几个不舒服的问题：这个指标为什么重要？数据缺失怎么办？口径和业务说法不一致怎么办？如果老板明天问“为什么这个数变了”，我能不能拿出证据？
教程让你知道工具怎么用。
题场让你知道工具什么时候该用，什么时候不该用。
这才是面试里真正能讲出来的东西。
我叫石头，在数据行业里摸爬滚打了十几年，也见过太多学得很认真、却没把项目留下来的人。这里写的，就是这些教训——我觉得值得说出来的那部分。
