概览

Stripe 的 Bug Squash 面试总共持续一小时，前五分钟通常是双方快速自我介绍，两三句话即可，不需要任何花哨内容。接下来面试官会请你提供 GitHub 账户信息，然后让你从一个指定的 URL 下载一个 GitHub 仓库，这个仓库就是整场面试的核心。大多数候选人会选择使用 Python。整个项目的结构比一般的 integration 面试要复杂许多，目录是比较完整的，包含 example、config、test、doc 等目录，不过实际上这些部分并不需要深入研究。

正确的面试节奏

正确的节奏是先打开 README，快速了解这个项目要完成的任务和核心功能定位。面试官不在乎你懂不懂项目背景，他们更关心你是否能读懂 README 并抓住关键。然后你会花一两分钟浏览整个代码逻辑，不是逐行阅读，而是快速扫过项目结构、核心模块、入口文件，确保自己知道 bug 可能出现在哪几个区域。等你对整体有了大概印象后，就直接运行 pytest，把测试用例跑出来，观察失败信息。Bug Squash 面试的本质是让你根据测试失败定位逻辑问题，因此 pytest 的输出就是你的导航图。

面试官通常会明确点出要你专注修哪几个失败的 test case，这能帮你节省大量时间。你可以在面试期间查 Google 或相关文档，但绝对禁止使用 AI 或 Cursor，这一点是所有 Stripe 面试官都会反复强调的。也正因为不能用 Cursor，许多逻辑上的修补就需要你真正理解模块的行为、熟悉 Python 运行机制、清楚错误来源，而不是依赖自动补全或 pattern matching。

聊聊高频题

最后讨论一个典型的高频 bug case。项目中有一个负责加载配置文件的 ConfigManager，按设计它应该在程序启动时lazy loading，只在第一次被多个工作线程访问时从磁盘读取配置，然后将结果缓存在内存里供后续线程重复使用。测试用例期望的是在高并发环境下，多条线程同时调用 get_config 时，结果应该完全一致，而且加载操作应该只发生一次。但是 pytest 的结果显示，在并发测试中偶尔会出现两个诡异的失败：第一类是小概率的初始化异常，有些线程拿到的配置是 None，因为它们比真正执行加载逻辑的线程更早判断缓存未初始化；第二类是性能相关的失败，因为当前实现使用了一个粗粒度的全局锁，把整个 get_config 包住，导致在高并发压力下性能骤降，不符合测试中对并行度的期望；第三类则是状态污染问题，测试 teardown 后再次运行时，某些线程会看到上一次残留的临时文件句柄或缓存内容，说明线程退出时资源没有被正确清理。这道题的根本原因是对共享状态的并发访问缺乏严谨的设计，而fix则必须围绕lazy loading的原子性、锁的粒度控制，以及线程生命周期中的资源释放来完善同步逻辑。