Stripe 从Intern到Senior，几乎都在使用同一套 integration 题库。区别只在于面试官的期望和你能走到第几步。整场面试时长通常为一小时，形式和传统的 LeetCode 式面试完全不同。

你会被要求从 GitHub 下载一个公开的 repository，本地用自己的 IDE 打开。题目的说明藏在 GitHub 的 issue 里——不能下载、不能复制，想看只能不停在浏览器和 IDE 之间切换。这种设置其实是有意的，它模拟了真实开发中在阅读代码、调试、查文档之间不断切换的场景，也能看出你在有限时间内的节奏掌控能力。整个面试过程不会要求算法推导，也没有复杂的数学思维，考察点完全是你作为一名工程师的 integration 实战能力：能否快速理解已有代码、在不破坏结构的情况下扩展功能、是否能读懂文档、发起请求、解析数据，以及是否能在 debug 时保持思路清晰。

题目一般分成五个部分，但几乎没人能完整写完五个。Stripe 非常清楚时间紧张，他们更看重候选人的实现质量、代码整洁度、以及面对未知需求时的反应方式。每个 Part 都在向更真实、更贴近生产环境的方向推进。典型的高频题之一就是 “Bikemap”。这个题的背景很简单——一个骑行路线的可视化系统，需要你逐步实现从数据解析到地图渲染的完整链路。虽然题目支持多语言实现，但过往经验显示，用 Python 能节省一半以上的开发时间。Java 或 C++ 版本写起来非常冗长，尤其是涉及到 JSON 解析和 HTTP 请求的时候。

第一部分主要是 JSON 数据解析与坐标提取。给定一个名为 ride-simple.json 的文件，格式是 GeoJSON，包含大约 500 个 GPS 点。题目要求你解析文件内容，提取前十个坐标点，并将结果按格式输出到标准输出。这个任务听起来简单，但面试官会在乎你是否合理地组织了读取逻辑，比如是否考虑文件路径的可配置性、是否用异常处理保证健壮性、以及是否在解析时能识别数据层级结构（Feature → Geometry → Coordinates）。不少人会在这里浪费时间，因为 JSON 的嵌套层级比想象中深。

第二部分进入 HTTP 请求处理。要求向指定 URL 发送一个 POST 请求，请求体是 JSON（通常与上一部分生成的内容类似），服务器会返回一张地图图片，格式为 PNG。你的任务是将这张图片保存到本地。面试官会观察你是否熟悉常见的 Python HTTP 库（如 requests）、是否能正确设置 headers、序列化 JSON，并在异常时打印合理的日志。很多人卡在这里的原因并不是逻辑错误，而是对第三方库的使用不熟悉，或者忘记处理网络错误和文件保存路径。

第三部分是 使用 staticmap 库绘制地图。

第四部分则进一步引入 地标标记与最近点查找。题目通常会给出一组地标坐标，让你在地图上标注出来，并计算离骑行路线最近的地标。虽然题目没有明确要求复杂算法，但考官会看你是否能合理使用数据结构，比如在计算最近点时，是否直接暴力遍历（O(n)）还是采用了更高效的空间结构。

Stripe 的这一套面试体系其实是一种工程思维与真实开发习惯的考察。他们不在意你是否能写出最优算法。因此，准备时最重要的不是刷题，而是熟悉 Python 的 I/O、HTTP、JSON、文件系统、异常处理、模块化设计等基础。能展示出 clean code、分层清晰、日志完备、命名规范，往往比写出高效算法更重要。