Google Software Engineer Interviews: Why Edge Cases Decide More Than the First Solution

The Edge-Case Categories That Show Up Most| 最常见的几类边界条件

• Empty or minimal input, including arrays of length zero or one.

  空输入或极小输入，比如长度为 0 或 1 的数组。

• Duplicate values, repeated keys, or ties that change the intended behaviour.

  重复值、重复 key，或者会改变预期行为的并列情况。

• Boundary numbers such as overflow risks, negative values, or zero denominators.

  数值边界，比如溢出风险、负数、零分母。

• Ordering assumptions: sortedness, stability, and whether data arrives in the order you hoped.

  顺序假设：数据是否有序、是否稳定、是否真的按你希望的顺序到来。

• Performance cliffs where a correct idea quietly becomes too slow or too memory-heavy.

  性能断崖：逻辑虽然正确，但规模一上来就太慢或太占内存。

How to Surface Edge Cases During the Interview| 写题时怎么自然地把边界条件讲出来

• Clarify input assumptions before coding if the prompt leaves room for interpretation.

  如果题目留有解释空间，先把输入假设问清楚再写。

• Call out one or two important edge cases before implementation, then revisit them in tests.

  在实现前先点出一两个重要边界，再在测试里回头验证。

• Use your variable names and guard clauses to make the boundary handling obvious.

  通过变量命名和 guard clause，让边界处理本身就很明显。

• If a trade-off exists, say it explicitly: simpler code now versus stronger guarantees later.

  如果有取舍，直接说出来：现在写得简单一点，还是为了更强的保证多加一些处理。

A Tiny Example| 一个很小但很典型的例子

function average(nums: number[]): number | null {
  if (nums.length === 0) return null

  let total = 0
  for (const value of nums) {
    total += value
  }

  return total / nums.length
}

Testing Discussion Is Part of the Signal| 测试讨论本身就是面试信号

• Name a small set of tests that cover normal, boundary, and failure-like inputs.

  说一小组能覆盖正常情况、边界情况和失败情况的测试。

• Explain why each test exists rather than listing cases mechanically.

  别机械报测试名，要顺手讲每个测试存在的原因。

• Mention performance testing if the algorithm is sensitive to input size.

  如果算法对输入规模敏感，别忘了提性能测试。

• If relevant, talk about maintainability: what future changes could silently break the code.

  如果合适，也可以补一句可维护性：未来哪些改动可能悄悄把它搞坏。

What Often Goes Wrong| 候选人最容易卡住的地方

• They assume the prompt means the most convenient input shape.

  默认题目一定给你最省事的输入形态。

• They wait until the very end to think about tests.

  到最后才想起要测什么。

• They find one edge case and then stop looking for performance or data-shape issues.

  找到一个边界情况就停了，没继续看性能或数据形态问题。

• They treat edge cases as a checklist instead of as part of good engineering reasoning.

  把 edge case 当成清单，而不是工程推理的一部分。