在 Google Early Career 的面试过程中，每一轮都明显围绕着两个核心：clarity of thought 和 engineering rigor。整体流程没有特别强调算法题的“难度”，反而更在意你怎么理解问题、怎么沟通需求、以及在实际工程环境中你会如何处理模糊的场景。这点从第一轮的设计题就可以感受到。

第一轮给的是一个和 Google Docs 场景有关的问题：给一段文本和页面宽度，要求我们计算文本会在页面上占用多少行。题目表面看起来像是一个字符串处理或排版模拟的问题，但其实考得是你如何理解 Google 文档中排版的真实逻辑。我花了不少时间去 clarify，比如要不要考虑字体和字号，是否有自动换行，标点符号处理有没有特殊规则，行之间的空隙怎么算。在明确了假设之后，我开始写一个line-wrapping的模拟逻辑，在遇到单词过长无法断行的情况时，也讨论了几种处理方式（比如强制换行 vs hyphenation）。Follow up 是关于 layout optimization 的：如果我们有两段文字，如何设计一个双栏表格的列宽，以最小化整张表格的总行数。这一题不仅需要前面的排版逻辑，还要做一定的搜索和优化策略，属于比较偏工程的复杂度控制问题。

第二轮则是一道经典的区间最大子数组和问题：给一个数组，找出两个索引 i 和 j，使得从 i 到 j 的子数组之和最大。这题本身可以用前缀和配合哈希表解决，但面试官的重点其实不在算法对不对，而是你是否真正考虑到了各种边界情况，比如数组中全是负数、数组为空、只有一个元素等等。他还要求我 dry run 自己写的代码，在每个关键点说明我的边界判断是如何起作用的。Follow up 问的是算法在实际设备上的运行时间，我解释了时间复杂度是 O(n)，但也提到了在真实数据量比较大的时候，空间占用和 cache locality 会不会成为性能瓶颈。

第三轮是图搜索题：给定一组航班，一个起点和一个终点，问是否可以通过这些航班把包裹从起点运到终点。这个其实就是一个典型的 reachability 问题，我用了 BFS 来判断是否可达。Clarify 的部分主要集中在航班之间有没有最小转机时间，但面试官说可以忽略，这也让我能更专注在 graph traversal 上。真正有意思的是 follow up，他问如何“最小化在机场的等待时间”，而不是通常会问的“最早到达时间”。这里我设计了一个 cost function 是当前航班的 departure time 减去前一个航班的 arrival time，把问题转化成了最小化总等待时间的路径问题，最终用 Dijkstra 来解。

整体体验下来，我的感受是 Google Early Career 的面试并不只是判断你会不会写代码，更强调你是否具备构建真实系统的意识。Clarify 的过程是不可跳过的核心，不仅要问对问题，更要展示你是如何思考工程中的 tradeoff 和细节的。这比单纯的算法速度更重要。