Atlassian 软件工程师面试实录 2026：真实面经完整复盘
Atlassian面试第一人称完整复盘：涵盖算法Coding、系统设计、Behavioral面试。还原真实面试对话、高频题目与解题思路，附准备策略与注意事项，助你高效备战Atlassian技术面试。
公司：Atlassian 岗位：软件工程师 (SDE) 面试形式：Virtual Onsite 结果：Pass → Offer
系统设计快问快答
自我介绍之后我们就进入了系统设计环节，大概有十五到二十分钟。面试官问了几个比较简单的题目，比如第一个问题 “如果你要设计一个系统，让团队成员可以互相留言、点赞、标记重要评论，你会怎么做？”我没有急着讲技术架构，而是先确认了一下功能范围，比如是否要支持实时通知、是否要权限控制这些。面试官说先从简单的核心功能讲起。我就从数据模型说起，然后讲了下怎么做评论分页，评论排序是按时间还是按点赞数之类的。接着我说了一下点赞的幂等处理（不能重复点赞）、怎么避免用户刷点赞这种问题，最后再讲了一下如果要 scale，可以加缓存、异步处理等。
其实这个设计题没有特别深入，不太像那种高强度的 system design 面试，更像是在考你有没有基本的系统设计思维和组织思路。你只要讲得逻辑清晰，能解释你的每一个决策是为什么做的，基本就能让面试官满意。剩余的几个题目也是类似的结构，每个五分钟。
第一题Coding
第一个coding题目是典型的字符串处理类题目：给一个字符串，比如 “aabbccdde”, 要你找出出现次数最多的字符，并且返回它们组成的新字符串，要求顺序不变。例如，“aabbccdde” 里 a、b、c、d 都出现两次，e 只出现一次，所以你最后要返回的是 “aabbccdd”。这题一开始我用了 HashMap 统计频次，然后再做了一次遍历，按顺序把那些频率等于最大值的字符挑出来拼接。代码很快写出来了，面试官让我解释了一下为什么需要两次遍历，我说因为要保留原始顺序，而且要处理多个字符频次相等的情况，不能直接按频率降序排序。写完之后我还自己测了几个例子，比如空字符串、全是相同字符、多个频率并列最大这些边界情况，跑起来都没问题。
第二题Coding
第二题就稍微 tricky 一点，是一个关于多维数组的题。给你一个二维数组，比如 [[1,2,3],[4,5,6],[7,8,9]]，要你按对角线顺序返回所有元素，也就是说你要从左上角开始，走斜对角，从 (0,0) → (0,1)-(1,0) → (2,0)-(1,1)-(0,2) 这样的路径输出成一个一维数组。这个题我开始没完全理解题意，花了一点时间和面试官确认好规则。想清楚之后我用了两个嵌套循环控制对角线的起点和遍历方向，还好写得比较顺，最后输出正确。写完我也跑了几个 1x1、1xN 和 Nx1 的数组，确保不会出错。面试官似乎也更看重你思路讲得清不清楚，代码风格是不是易读，我就尽量把变量名取得有点意义，也加了一些注释说明思路。
总结下来，Karat 这一轮的重点还是在算法题，不光是写出答案，而是要现场调试出一个可以跑的代码，还得自己写 test case 验证逻辑。系统设计讲得清楚就可以，不需要太 fancy 的分布式架构。准备的话，建议重点练习中等难度的算法题，并且在练题的时候多练用你熟悉的语言写出能运行的解法，然后自己写几个 test case 试一试，这个习惯会在面试中帮到你很多。
第一阶段：两轮 Coding（数据结构与算法）
第一轮 coding 的题目是 实现一个支持 push、pop、min 的栈（O(1) 时间复杂度）。这题是比较常见的变种数据结构题，我的思路是设计两个栈，一个主栈保存所有值，一个辅助栈保存当前的最小值。每次 push 的时候更新辅助栈，pop 时也要同步 pop 两个栈，min() 直接返回辅助栈的栈顶即可。写完后，面试官会故意给一些 edge case，比如重复 push 相同最小值、连续 pop 导致辅助栈为空的情况，问你是否考虑到了。
第二轮是数组+二分的题，具体是 在一个无限长的 sorted array（只能通过 API get(i) 访问）中查找一个目标值的位置。由于不能直接获得数组长度，我先通过指数增长的方式找 upper bound（即 i=1,2,4,8…
直到 get(i) > target），然后在这个范围内做标准的 binary search。面试官在意的是你对边界的处理是否严谨，以及是否能处理 target 不存在、数组为空、或者所有值都小于目标值等情况。
第二阶段：System Design
System design 轮的题目是 设计一个In-app Notification System，要求支持发送、存储和展示通知，包括读未读状态、展示顺序和 TTL 过期。因为时间比较紧，我先从 high-level component 开始讲，分成 producer（业务服务触发通知）、notification service（负责去重和调度）、storage（MySQL + Redis）、frontend query（支持分页与筛选）。面试官关注点包括：数据模型怎么设计、Redis 缓存怎么做、一个用户有几千条通知时怎么优化 query latency。我还补充提到了 Kafka 作为异步 pipeline、支持 batched write 到 DB，整个方案尽量简单可落地。
面试流程整体结构
第一个 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，用字符或者简单的打印来展示蛇的移动和增长过程。
面试总结
成功经验
- 充分准备高频题：Atlassian 的面试题目集中在经典算法和数据结构上，提前准备 LeetCode 高频题非常有必要。
- Behavioral 故事要准备充分：使用 STAR 框架准备 5-8 个核心故事，覆盖 Leadership、Conflict、Innovation 等场景。
- 沟通表达要清晰：解题过程中要主动与面试官沟通思路，不要闷头写代码。
- 边界条件要主动讨论：面试官很看重候选人对 edge cases 的考虑。
面试注意事项
时间管理：每轮 45-60 分钟，需要合理分配时间给题目、讨论和 follow-up 问题。
技术深度：Atlassian 的面试官对技术细节要求很高，边界条件、性能优化、系统设计能力都是考察重点。
推荐阅读
- Atlassian 面试全流程指南 — Atlassian 面试流程、高频题目与准备策略- System Design 面试完全攻略 — 分布式系统设计的核心原则与高频题目
- 行为面试 STAR 故事模板 — Leadership、决策、冲突解决等高频行为问题的回答框架
💡 需要面试辅导？
如果你对准备技术面试感到迷茫，或者想要个性化的面试指导和简历优化，欢迎联系 Interview Coach Pro 获取一对一辅导服务。
👉 联系我们 获取专属面试准备方案
📝 最新面试经验补充（2025-2026年面经）
面试流程整体结构
第一个 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 综合评估所有面试官的反馈再给出结果。
第二题Coding
第二题就稍微 tricky 一点，是一个关于多维数组的题。给你一个二维数组，比如 [[1,2,3],[4,5,6],[7,8,9]]，要你按对角线顺序返回所有元素，也就是说你要从左上角开始，走斜对角，从 (0,0) → (0,1)-(1,0) → (2,0)-(1,1)-(0,2) 这样的路径输出成一个一维数组。这个题我开始没完全理解题意，花了一点时间和面试官确认好规则。想清楚之后我用了两个嵌套循环控制对角线的起点和遍历方向，还好写得比较顺，最后输出正确。写完我也跑了几个 1x1、1xN 和 Nx1 的数组，确保不会出错。面试官似乎也更看重你思路讲得清不清楚，代码风格是不是易读，我就尽量把变量名取得有点意义，也加了一些注释说明思路。 总结下来，Karat 这一轮的重点还是在算法题，不光是写出答案，而是要现场调试出一个可以跑的代码，还得自己写 test case 验证逻辑。系统设计讲得清楚就可以，不需要太 fancy 的分布式架构。准备的话，建议重点练习中等难度的算法题，并且在练题的时候多练用你熟悉的语言写出能运行的解法，然后自己写几个 test case 试一试，这个习惯会在面试中帮到你很多。
第一阶段：两轮 Coding（数据结构与算法）
第一轮 coding 的题目是 实现一个支持 push、pop、min 的栈（O(1) 时间复杂度）。这题是比较常见的变种数据结构题，我的思路是设计两个栈，一个主栈保存所有值，一个辅助栈保存当前的最小值。每次 push 的时候更新辅助栈，pop 时也要同步 pop 两个栈，min() 直接返回辅助栈的栈顶即可。写完后，面试官会故意给一些 edge case，比如重复 push 相同最小值、连续 pop 导致辅助栈为空的情况，问你是否考虑到了。 第二轮是数组+二分的题，具体是 在一个无限长的 sorted array（只能通过 API get(i) 访问）中查找一个目标值的位置。由于不能直接获得数组长度，我先通过指数增长的方式找 upper bound（即 i=1,2,4,8… 直到 get(i) > target），然后在这个范围内做标准的 binary search。面试官在意的是你对边界的处理是否严谨，以及是否能处理 target 不存在、数组为空、或者所有值都小于目标值等情况。
贪吃蛇：最高频的经典题
在所有 code design 题目中，出现频率最高、几乎可以说是人尽皆知的，就是贪吃蛇。核心功能一般围绕两个点展开。第一个是支持用户通过按键输入来改变蛇的移动方向，比如上下左右，同时要避免非法方向切换（例如直接从左转右）。第二个是支持蛇在特定条件下自动增长 size，比如吃到食物。另外一个非常关键的逻辑是碰撞检测。如果蛇头撞上了自己的身体，游戏需要正确结束。这部分通常需要你自己主动和面试官确认边界条件，比如是否有墙、是否允许穿墙、棋盘大小是否固定等。很多细节都需要通过沟通来最终敲定，因此不同 candidate 的实现细节有所差异是完全正常的。 面试的最后阶段，通常需要你实际运行代码来证明功能的正确性。由于时间非常有限，几乎不可能实现一个 GUI，所以最常见、也是最稳妥的做法，是在 terminal 里实现一个 textual UI，用字符或者简单的打印来展示蛇的移动和增长过程。
系统设计快问快答
自我介绍之后我们就进入了系统设计环节，大概有十五到二十分钟。面试官问了几个比较简单的题目，比如第一个问题 “如果你要设计一个系统，让团队成员可以互相留言、点赞、标记重要评论，你会怎么做？”我没有急着讲技术架构，而是先确认了一下功能范围，比如是否要支持实时通知、是否要权限控制这些。面试官说先从简单的核心功能讲起。我就从数据模型说起，然后讲了下怎么做评论分页，评论排序是按时间还是按点赞数之类的。接着我说了一下点赞的幂等处理（不能重复点赞）、怎么避免用户刷点赞这种问题，最后再讲了一下如果要 scale，可以加缓存、异步处理等。 其实这个设计题没有特别深入，不太像那种高强度的 system design 面试，更像是在考你有没有基本的系统设计思维和组织思路。你只要讲得逻辑清晰，能解释你的每一个决策是为什么做的，基本就能让面试官满意。剩余的几个题目也是类似的结构，每个五分钟。