这篇记录我准备 Google Cloud Consultant / Data Analytics 方向英文面试时的方法。我的目标不是讲得像 native speaker，而是能清楚、稳定、有结构地说明自己的经历和判断。
我准备后最大的感受是：英文面试不只是语言考试。它更像是在确认三件事：
所以我没有把重点放在复杂词汇上，而是准备了一套简单但稳定的表达方式。
我给自己准备的主线是：
I have mainly worked as a data engineer, but in recent projects I have been increasingly involved in architecture discussions, stakeholder coordination, data quality issues, and operational improvement.
That is why I am interested in moving toward a cloud data consultant role.
这段话的重点是把“过去的 data engineering 经验”和“未来的 consultant role”连接起来。否则听起来会像突然转职，缺少逻辑。
我没有准备很长的自我介绍，只按这个顺序讲：
英文自我介绍不需要塞太多技术名词。技术名词太多，反而会让重点变散。我的目标是让面试官在一分钟内知道：
讲项目时，我尽量使用固定结构：
The customer had ...
The main challenge was ...
My role was ...
We designed ...
One important decision was ...
What I learned from this project was ...
这个模板很简单，但很有用。因为英文面试中最怕的是句子越说越长，最后自己也不知道落点在哪里。
例如讲 migration 项目时，可以这样组织：
The customer had an existing analytics platform on AWS.
The main challenge was operational risk and maintainability.
My role was tech lead, so I was responsible for architecture design, implementation, code review, and client-facing technical explanations.
We designed a GCP-based analytics platform using BigQuery, Dataform, Looker, Airflow, and Pub/Sub.
One important decision was to separate scheduled batch processing and event-driven processing.
What I learned was that cloud migration is not only service replacement. It also requires careful consideration of operations, cost, maintainability, and team skill set.
不需要很华丽，但逻辑必须清楚。
这个问题不要只说“Google Cloud is powerful”。我会从自己的经历出发：
这个问题要解释为什么从 Data Engineer 转向 consultant。
我会强调：
我准备的 strength 不是“学习能力强”这种泛泛答案，而是：
I can connect hands-on data engineering with a broader business and operational perspective.
这和岗位更相关。因为 consultant 需要能和技术团队、业务团队、客户一起工作。
我没有假装自己已经是成熟 consultant，而是诚实说明：
这个回答比“我的缺点是太认真”更可信。
英文面试里，短句比长句安全。
不好：
Because there were many different stakeholders and the architecture was complicated, I had to investigate many things and communicate with many teams...
更好：
There were many stakeholders.
The architecture was complex.
So I first clarified the data flow and the ownership of each component.
被问到技术选择时，我会先回答结论，再解释原因。
I would use Airflow for scheduled batch workflows, and Pub/Sub for event-driven processing.
The reason is that they solve different problems.
如果问题超出经验范围，不要硬编。可以这样说：
I have not implemented that exact service in production, but based on my experience with data pipelines, I would first clarify the requirement, data volume, latency, and operational constraints.
这比假装做过更安全，也更像真实工作中的沟通。
我最后没有继续写很长的英文稿，而是只反复练这些短块：
每个回答控制在 1 到 2 分钟。重点不是逐字一致，而是每次都能讲出同样的逻辑。
对我来说，英文面试准备的关键不是背高级表达，而是把项目讲简单、讲清楚、讲得有判断。