这篇是我准备 Google Cloud Consultant / Data Analytics 方向面试后的复盘。它不是标准答案，也不是逐字背诵稿，而是我自己把过往项目整理成 consultant 视角时用到的方法。
我原本的背景更接近 Data Engineer：做过 ETL、DWH、data lake、cloud migration、data quality、reporting 和一些运用改善。准备这个岗位时，我最大的变化不是补了多少新技术，而是重新整理了自己讲项目的方式。
面试中不要只把自己讲成“会写 pipeline 的人”。Cloud Consultant 更关心的是：
我最后给自己的定位是：
Data Engineer background, moving toward a customer-facing Cloud/Data Consultant.
也就是：我有数据工程的实际经验，但不只关注实现，也关注数据质量、运用、架构、成本、维护性和 stakeholder alignment。
我把自己的项目按下面几个角度重新整理了一遍：
| 角度 | 要回答的问题 |
|---|---|
| Business goal | 客户或业务真正想解决什么问题 |
| Current architecture | 原来的系统是什么样，有什么限制 |
| My role | 我负责实现、设计、review、协调还是说明 |
| Technical decision | 为什么选这个服务或架构 |
| Trade-off | 这个选择牺牲了什么，避免了什么风险 |
| Data quality | 数据正确性、缺失、重复、不一致如何处理 |
| Operation | 如何监控、重跑、告警、权限管理、版本管理 |
| Result / learning | 项目带来了什么改善，我学到了什么 |
这个整理方式比单纯列技术栈有用很多。面试官不是只想听“我用过 BigQuery / Dataform / Looker / Airflow”，而是想知道我为什么这么设计，以及这种设计在真实项目中解决了什么问题。
最适合作为主项目。因为 migration 天然包含现状分析、目标架构、成本、风险、运用、客户说明和分阶段切换。
我准备时会重点说明：
这个类型的项目非常适合展示 consultant 思维，因为它不是“把 A 服务换成 B 服务”，而是要解释客户为什么需要换、怎么换、风险在哪里、团队以后怎么维护。
这类项目适合展示基础能力和 DataOps 视角。
我会重点讲：
这类项目的价值在于，它说明你知道真实数据平台不是一开始就完美的。很多时候是先能跑起来，再一步步补齐可靠性、可维护性和治理能力。
现代化项目适合展示对企业数据基盘演进的理解。
我会避免简单说“旧系统不好”。更合理的表达是：
这个表达会比“我们用了新的技术”更成熟。
不管是讲项目、看架构图，还是做 code review，我都尽量用同一套框架：
Data Quality
Security
Scalability
Reliability
Maintainability
Cost
这个框架的好处是，面试中即使遇到没准备过的问题，也不会完全没有方向。
例如被问到一个数据 pipeline 设计，我会先想：
我没有把所有回答写成完整演讲稿，而是给每个项目准备了 STAR 骨架：
真正面试时不会完整照读，但这个结构可以防止回答散掉。尤其是 technical interview 中，讲着讲着很容易陷入服务名和实现细节，STAR 可以提醒自己回到问题、行动和结果。
我觉得最有帮助的不是死背 GCP 服务，而是把每个项目改写成“客户问题 -> 架构选择 -> trade-off -> 运用结果”的故事。
Data Engineer 面试更容易被问“你怎么实现”。Consultant 面试则更常看：
如果要准备类似岗位，我会建议先不要急着刷很多新知识点。先把自己的项目重新整理一遍，尤其是每个项目背后的业务目标、架构权衡、数据质量和运用问题。这样回答会自然很多，也更像真实做过项目的人。