Atlassian 的面试流程整体非常清晰，而且是典型的多 gate 设计。每通过一个 gate，才会进入下一个阶段，节奏偏稳，但对综合能力的考察非常全面。

面试流程整体结构

第一个 gate 更像是 technical screen，通常包括一个简短的 coding 题以及一个轻量级的 system design。整体难度和工作量都明显低于后续的 onsite gate，更多是在验证基础编码能力和思路是否清晰，一般不会在这里卡太多人。

第二个 gate 是一个完整的技术轮组合，总共两个小时。一小时是 code design interview，一小时是 data structure interview。后者就是常规的 LeetCode 风格算法题，难度在中等左右，考察的是基本的数据结构和算法功底，这一部分相对比较标准。

第三个 gate 是一小时的 system design interview，考察点和大厂 system design 基本一致，比如需求拆解、架构设计、可扩展性、trade-off 等。这一轮对 senior 及以上候选人来说权重会更高。

第四个 gate 偏向 soft skill，总体包括 45 分钟的 values interview 和 1 小时的 management interview。两者形式都比较类似，基本是 BQ，围绕团队合作、冲突处理、ownership、影响力等展开，一般不会深挖具体的技术细节。

通过所有 gate 之后，最终会进入 hiring committee review，由 committee 综合评估所有面试官的反馈再给出结果。

Code Design Interview 的整体特点

在所有技术轮中，code design 是非常有 Atlassian 风格、也最容易让candidate措手不及的一轮。这一轮需要在本地 IDE 中完成代码实现，并且全程 share screen。面试官通常只会给出题目描述和 function signature，不会提供任何现成代码或者测试框架，基本就是从零开始实现。整体感觉更像是偏 OOD 的 coding，而不是算法题。这类题目通常不涉及复杂算法，评估重点主要集中在几个方面：功能是否正确、代码结构是否清晰、是否易于扩展、是否有良好的抽象和职责划分。同时，代码的可读性也非常重要，面试官会实时观察你的命名、拆类方式以及思考过程。

贪吃蛇：最高频的经典题

在所有 code design 题目中，出现频率最高、几乎可以说是人尽皆知的，就是贪吃蛇。核心功能一般围绕两个点展开。第一个是支持用户通过按键输入来改变蛇的移动方向，比如上下左右，同时要避免非法方向切换（例如直接从左转右）。第二个是支持蛇在特定条件下自动增长 size，比如吃到食物。另外一个非常关键的逻辑是碰撞检测。如果蛇头撞上了自己的身体，游戏需要正确结束。这部分通常需要你自己主动和面试官确认边界条件，比如是否有墙、是否允许穿墙、棋盘大小是否固定等。很多细节都需要通过沟通来最终敲定，因此不同 candidate 的实现细节有所差异是完全正常的。

面试的最后阶段，通常需要你实际运行代码来证明功能的正确性。由于时间非常有限，几乎不可能实现一个 GUI，所以最常见、也是最稳妥的做法，是在 terminal 里实现一个 textual UI，用字符或者简单的打印来展示蛇的移动和增长过程。

除了贪吃蛇之外的高频 Code Design 题型

除了贪吃蛇之外，Atlassian 的 code design 面试还有一批非常稳定出现的高频题型。这些题目在表面形式上差异很大，但本质上考察的能力高度一致：是否具备扎实的工程建模能力。

1. 偏业务建模的系统设计题：第一大类是偏业务建模的 code design 题，通常会让你实现一个非常简化、但边界清晰的业务系统。比较常见的例子包括简化版的任务管理系统、评论系统、审批流系统，或者权限 / role-based access control 相关的系统。题目本身通常不会复杂到需要大量业务规则，但会刻意留下足够的扩展空间，让面试官观察你如何进行抽象。在这类题目中，面试官真正关注的并不是你是否写完了所有功能，而是你一开始如何拆分 domain object。比如你是否能清晰地区分 entity、service 和 repository 的职责，是否会把逻辑硬塞进一个大类里，还是会通过接口和组合让代码结构保持干净。另外一个非常重要的观察点是接口设计。Atlassian 的面试官通常会非常在意你对 public API 的设计方式，比如方法命名是否表达清楚意图，参数是否合理，是否为未来的功能扩展留出了空间。这也是为什么很多 candidate 在实现过程中，会被面试官不断追问 “What if we want to support X later?”。这类题目几乎不会考你算法能力，但会强烈考验你是否真的写过中大型系统，是否习惯在动手之前先想清楚模型，而不是一边写一边 patch。

2. 偏状态机和流程驱动的设计题：第二大类是偏状态机或流程驱动的 code design 题。这类题目非常喜欢用现实世界的系统作为背景，比如电梯系统、会议室预订系统、排队系统，或者某种事件触发的工作流。这些题目表面看起来很直观，但一旦开始实现，就会很快暴露出设计能力的差距。在这类题目中，面试官通常不要求你实现完整的 UI 或复杂调度逻辑，而是重点看你是否能正确识别系统中的状态，以及状态之间的转换关系。比如某个对象在不同状态下允许哪些操作，非法状态转换如何处理，状态变化是否集中管理还是分散在各个类中。一个非常常见的坑是，candidate 会把所有逻辑直接写在条件分支里，用大量 if-else 来控制流程。这种实现通常在功能上是对的，但从设计角度来看是非常扣分的。相比之下，如果你能明确抽象出状态、事件以及状态转换逻辑，哪怕实现不完整，整体设计也会明显更高级。

3. 偏工具型或库设计的题目：还有一类出现频率略低，但同样值得准备的题型，是偏工具或库设计的 code design。比如让你实现一个简单的 rate limiter、cache、in-memory store，或者某种规则引擎。这类题目往往会刻意弱化算法复杂度，而把重点放在 API 设计和内部结构上。在这种题目中，面试官通常会观察你是否能把“对外接口”和“内部实现”分离清楚，是否会过早暴露实现细节，以及是否考虑到测试、可维护性和可替换性。这类题目非常容易写成“能跑但很难改”的代码，而这正是面试官想要区分候选人的地方。