目录
正在加载目录...

Oracle SDE 四轮面经｜8.31，一天连着四小时打完

这个星期的面试，一天连着四个小时面了四轮。Oracle SDE 的面试风格比较务实，技术题难度偏 LC Medium，系统设计更看重你能不能说清楚 trade-off，BQ 也比很多公司问得更细。

Oracle SDE 四轮面经｜8.31，一天连着四小时打完

Oracle SDE 备考 Timeline

Oracle 的招聘节奏偏慢，这是候选人普遍反馈的特点，提前规划好时间线很重要。

投递之后等 OA 邀请通常是 2 到 4 周，有时候更长。OA 是 HackerRank 平台，两道 Medium 级别的算法题，60 到 90 分钟。OA 通过之后，recruiter 会联系安排 phone screen，这一步又要等 1 到 2 周，部分候选人反馈等了将近一个月才有消息，可以在一周后主动跟进。Phone screen 通过之后安排 VO，通常是四轮集中在同一天打完。从投递到 VO 整体算下来，快的 6 到 8 周，慢的可能超过 3 个月。VO 结束之后 1 到 2 周出结果，Oracle 有时候会要求额外的背调轮次或 team match 对话，等待周期可能进一步拉长。

建议：Oracle 流程慢是正常现象，不要因为没有消息就假设凉了，保持多线并进，同时准备其他公司。

Round 1：Coding

两道算法题，这轮是全场最硬核的。

第一道：二叉树最大路径和

经典的 LC 124。用 DFS 后序遍历，对每个节点计算左右子树的最大贡献值，负贡献直接舍弃（取 max(0, 子树返回值)），在递归过程中更新全局最大值。

Follow-up 是打印路径——在递归时额外记录当前最大路径对应的节点序列，全局最大值更新时同步更新路径。这里有一个全局变量更新顺序的小问题，加了一个锁来保证并发安全，面试官对这个细节反应比较正面。

第二道：首个非重复字符

给定一个字符串，找到第一个不重复出现的字符，返回其下标。用哈希表统计每个字符出现次数，再扫一遍字符串找第一个次数为 1 的，O(n) 时间 O(1) 空间（字符集固定 26 个字母）。

面试官追问了如果字符串非常长、内存受限怎么处理——分块读取，维护滑动窗口内的频次表，不把整个字符串都加载进内存。

Round 2：BQ

Oracle 的 BQ 把行为题和技术讨论混在一起问——不是纯粹的故事时间，面试官会在你讲完之后追问具体的技术细节。

第一个问题是”Tell me about a challenging project you worked on”，追问方向是你具体负责哪块、做了什么技术决策、决策背后的原因是什么。我讲了一个分布式缓存优化的项目，面试官听完追问：你当时为什么选择这个方案而不是直接加机器？这逼着你从资源成本、延迟瓶颈、可维护性几个维度说清楚判断链路，背故事是过不了的。

第二个问题是”Tell me about a time you worked with someone whose personality was very different from yours”——这是 Oracle Bar Tender 轮的高频题。考的是你能不能在真实的协作摩擦里找到有效的沟通方式，不要只说”我们最终达成了共识”，要说你具体做了什么、对方的顾虑是什么、你怎么处理分歧的。

第三个问题是”How do you prioritize tasks when you have multiple deadlines?”——Oracle 很在意 ownership 和执行力，这道题的坑是很多人只讲方法论，面试官真正想听的是你用什么具体标准做取舍、有没有主动和 stakeholder 对齐。

Round 3：Bar Raiser

Oracle 的 Bar Raiser（内部有时候叫 Bar Tender）是来自另一个 team 的资深工程师，主要看 problem ownership 和跨团队协作能力，但也夹了一道技术题。

这轮面试官先深挖了简历——API Gateway 的架构、Microservices 怎么拆分、有没有用过 Docker 和 Kubernetes、做过什么扩展性优化。然后给了一道排列组合的思路题，不需要写完整代码，只需要说清楚解题思路。

BQ 方向是两道：

“While working on a team, how did you deal with a conflict?”——面试官不只是听”通过沟通解决了”，会追问：那次冲突的根源是什么、你当时的第一反应是什么、如果重来你会提前做什么。这个追问链路是 Oracle Bar Tender 轮的标准打法，提前把故事想到第三四层是这轮最重要的准备。

“Tell me about a time you had to learn something new quickly to deliver a feature”——考的是快速上手和自驱动力，重点是”quickly”和”deliver”，要体现你在压力下能落地，不只是说学了什么技术。

Round 4：System Design——文件转换系统

这轮题目是设计一个文件转换系统——用户上传文件，系统将其转换成目标格式并返回结果。Oracle 2025 年的高频系统设计题，和”海量文件存储”方向一脉相承。

我先 clarify 了几个问题：支持哪些格式转换、文件大小上限、转换结果要存多久、并发量预期。面试官给了参数之后开始讲架构。

整体架构：用户上传文件到对象存储（S3）→ 触发转换任务入队（Kafka）→ Worker 池拉取任务做格式转换 → 转换结果写回对象存储 → 通知用户（Webhook 或轮询）。

面试官追问了三个方向：

错误处理和重试——转换失败要有重试机制，超过重试次数的任务进死信队列，通知用户失败原因，不能让用户不知道发生了什么。

可扩展性——Worker 池根据队列积压量自动扩缩，大文件可以分片转换再合并，避免单个大文件阻塞整个 Worker。

性能优化——对相同内容的文件（hash 相同）直接复用已有转换结果，不重复计算；热门格式的转换结果加 CDN 缓存加速下载。

这轮面试官明确说了”我们更看重你的分析过程和 trade-off，而不是画出一个完美的架构图”，把每个设计决策背后的理由说清楚比什么都重要。

出来的感受

Oracle 整体不像 Google、Meta 那样对算法难度有执念，LC Medium 打扎实就够了。真正拉开差距的是系统设计里能不能说清楚 trade-off，以及 Bar Raiser 那轮能不能展示出深度的 ownership 意识。

BQ 那轮建议把项目故事准备到第三四层追问的深度，Oracle 对 code quality 和 ownership 相关的问题追得很深。

有在准备 Oracle 或其他北美大厂的同学，可以来找我们聊聊。InterviewShow 做过 Oracle、Microsoft、Google 这些公司的面试，系统设计 trade-off 的表达训练、BQ 项目故事打磨都有覆盖，一对一跟着走。有需要的来聊。

参考资料

END
Posted to: vo
In the last three days