Google Cloud FDE 面试：编程轮、Agent 设计轮，以及 Customer Engineer 陷阱

Google Cloud 的前线部署工程师（FDE，Applied AI 方向）招聘启事里，有一句话几乎直接预告了设计轮：为复杂的 Agent 工作负载构建高性能的评测管道和可观测性框架。而启事里没有任何一句话预告编程轮。

Aced（原名 Exponent）对编程轮的描述是：一道标准的数据结构与算法题，限时完成。FDE Academy 在另一篇关于面试题的文章中也是这样描述的。

所以需要两种准备：设计轮和行为轮，靠读招聘启事；编程轮，还得用老办法练算法。

轮次顺序也不要当成固定的。Scaler Topics 强调，这只是候选人反馈的规律，并非官方流程。Aced 认为总轮数仍大致与 Google 标准的现场面试相当，但由于这套流程刚推出不久，建议向招聘人员确认。

除了各轮本身，还有一个很少有人提到的陷阱：如果回答得像 Customer Engineer，满口演示和签单，等于在告诉面试官你更适合另一个岗位。

下面的练习一个晚上就能做完。需要准备 Python 3、一个编辑器、一个计时器，并把招聘启事打开放在屏幕上。文中所有代码都是简化的练习版本，不是真实面试题。

第一步：像读试卷一样读招聘启事

启事里的每一行都暗示着一道题。关于评测管道和可观测性的那一行，就是设计轮要深挖的内容。加分项部分提到了使用 ReAct、self-reflection 等框架构建的多 Agent 系统。

另外两行属于行为与客户轮，而不是算法轮：排查线上系统故障的经验，以及接受最多 50% 时间出差。两者都要准备诚实的回答，尤其是第二条，因为它关乎生活方式，而不是技能。

如果从没做过多 Agent 系统，也不必就此放弃。ReAct 和 self-reflection 列在加分项里，不是硬性要求，第三步的练习可以作为起点。

第一个任务：把每条要求标出来，然后在旁边各写一个自己工作中的真实经历。写不出经历的那一行，就是需要多练的地方。

第二步：编程题不大，但要准备追问

关于编程轮，各方说法不一。Aced 和 FDE Academy 称之为标准的数据结构与算法题，Scaler Topics 则说它更偏数据处理和 API 集成，代码要干净到别人能直接接手。

稳妥的做法是两类都练。一位候选人在 Blind 上写道，需求澄清之后，编码本身相当简单：一道关于标识符转换的小题。

假设题目是把变量名从 camelCase 转成 snake_case。打开计时器，边写边讲出每个决定，包括缩写词这类边界情况。

def camel_to_snake(name: str) -> str:
    out = []
    for i, ch in enumerate(name):
        if ch.isupper() and i > 0:
            prev_lower = name[i - 1].islower()
            next_lower = i + 1 < len(name) and name[i + 1].islower()
            if prev_lower or next_lower:
                out.append("_")
        out.append(ch.lower())
    return "".join(out)

assert camel_to_snake("userId") == "user_id"
assert camel_to_snake("HTTPServer") == "http_server"
assert camel_to_snake("getHTTPResponse") == "get_http_response"

检查：三个 assert 都必须通过、不报错。如果 HTTPServer 输出成了 h_t_t_p_server，说明漏了缩写词的处理。下次动手写代码之前，先把这个情况提出来。

这位候选人还说，编程题之后，话题转向了一个全仓库迁移的场景：在一个大型代码库里找出所有需要改名的地方。

这只是一个人的经历，不是普遍规律。但准备成本很低，而且这类开放式问题很容易要么陷进细节，要么答得太单薄。

所以提前准备两个版本。一分钟版本讲四点：列出所有需要修改的位置，使用自动化代码改写工具，让测试兜住错误，分阶段上线。

五分钟版本再加上回滚，以及代码通过字符串引用名称的那些地方。先讲短版，再问面试官希望深入哪一部分。

第三步：设计轮也会问失败

Aced 描述系统设计轮考察的是：如何设计把机器学习与 Agent 组件结合、并能规模化的智能系统。FDE Academy 说这一轮评估的是你如何思考多步骤 Agent 工作流中的编排、工具调用和错误处理。

那位 Blind 上的候选人说，这一轮主要在讨论如何构建和扩展 Agent 系统。处理 Agent 卡住或陷入死循环只是话题之一，此外还有运维层面的权衡。

假设客户需要一个能查订单、办退款的客服 Agent。先画出正常路径，再向面试官展示：出问题时，Agent 会在恰当的时机自行停下。下面是一个简化的 ReAct 风格循环，带步数上限和重复检测。

def run_agent(plan_step, act, max_steps=8):
    seen, trace = set(), []
    for step in range(max_steps):
        action = plan_step(trace)      # 由模型选择下一步
        if action["tool"] == "finish":
            return {"status": "done", "trace": trace}
        key = (action["tool"], repr(action["args"]))
        if key in seen:                 # 工具调用完全重复
            return {"status": "loop", "trace": trace}
        seen.add(key)
        trace.append((action, act(action)))
    return {"status": "max_steps", "trace": trace}

检查：写一个每次都返回同一个工具调用的假 plan_step。run_agent 必须在第二步就返回 loop，而不是一直跑到预算耗尽。

FDE Academy 建议主动说明你会如何在生产环境中监控、追踪和调试这个系统。DoiT 在一篇泛谈 FDE 的文章中认为，可观测性工具和基础设施本身同样重要。

done、loop、max_steps 这三种状态就是切入点：在一组样本对话上统计每种状态的比例，保存 trace 用来定位根因，Agent 触发 loop 时转交人工。

时间允许的话，可以提一下 self-reflection，也就是启事加分项里列出的技术。一个简单做法是让 Agent 在重试前重读自己的 trace。

第四步：“这和 Customer Engineer 有什么区别？”

这两个职位很容易混淆。FDE Academy 划了一条清晰的界线：Customer Engineer 支持 Google Cloud 的销售，FDE 则在客户环境中构建生产系统并对其负责。DoiT 同样把 FDE 定义为嵌入客户环境的工程师。

练习一个 60 秒的回答。开头先讲 FDE 的成功标准：一个真实系统在客户的生产环境中运行、被使用、保持稳定。然后讲一次系统上线后你亲自处理事故的经历。

就算代码写得好，也要避开的错误

编程轮，不要闷头解题。题目小容易让人掉以轻心，而面试官只能通过你说的话看到你的思路。代码还要干净到可以交接，这正是 Scaler Topics 提到的评判标准。

设计轮，不要画一张漂亮却无从衡量的 Agent 图。没有评测、没有追踪、没有循环检测的设计，看起来更像演示，而不是可上生产的系统。

这些技能在客户现场怎么用

标识符转换题看起来像新手练习。但想想它的真实版本：在客户的大型代码库里批量改名，还要向不同的对象、用不同的详略程度汇报同一件事。

循环防护函数，也正是排查线上系统故障时要用到的，而这正是招聘启事要求的经验。今天保存的 trace，就是日后客户使用时 Agent 卡住、帮你找到 bug 的线索。

简历上，每条经历都按同一个公式写：什么系统、在生产环境跑了多久、用哪些评测衡量、修过哪些事故。如果做过多 Agent 系统或 ReAct 风格的循环，就写在项目名旁边。

面试当天，不要把精力花在画最漂亮的 Agent 上。要能说清你的 Agent 曾在哪里卡住，以及你做了什么让它不再卡住。