“同工不同酬、遭遇职场打压...3 年前我放弃了苹果的高薪工作！”

对于许多人来说，苹果公司是梦寐以求的职业归宿，人人都想挤进去一展宏图。然而，本文作者 Varun Gandhi 却选择了在三年前从这家科技巨头跳槽，投身规模远小得多的 Sourcegraph。如今他不仅没有后悔，反而感到庆幸。那么，是什么促使他做出了这个看似大胆的决定？

在这篇文章中，Varun 将从拿到苹果 offer 的过程、参与开源项目、推动职责外的工作，以及薪酬待遇等多个角度，深入剖析了他为何最终选择离职，也希望给更多的职业发展一些建议。

原文地址：https://typesanitizer.com/blog/leaving-apple.html

作者 | Varun Gandhi 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

以下为译文：

2019 年 7 月- 2021 年 9 月，我任职于 Apple 公司的 Swift 团队工作。这是我职业生涯中的第一份工作，共计维持了 2.25 年的时间。

如今距离我离开 Apple 已经整整三年了。此前，我从来没有想过要写一篇“我为什么离开 Apple 公司”这样的博文，因为我觉得公开谈论在前雇主手底下工作的一些负面经历，可能会影响我未来的职业前景。

但最近有一次，当又有人问我为什么离开 Apple 公司时，我跟他一聊就是一个多小时，情绪也有些激动。同时，经过这次和朋友聊天，我回想起了过去几年里自己几次被一些人咨询过有关求职和职业发展的建议，所以我觉得应该将一些经验分享给其他人，特别是那些刚踏入职场的新人。

这就是我为什么会写这篇文章的原因。不过，这篇文章主要围绕促使我离开 Apple 的前因后果展开的，所以偏不愉快的内容会比较多。但我想明确一点，这并不代表我在 Swift 团队的大部分时光。

当时我所在团队开发的代码非常复杂，有时我甚至在做一些看似很小的改动时都会遇到困难，但我的辅导员们很有耐心，尽管他们手头的工作也很多，仍愿意抽时间在各自的专业领域给予我指导。日常与同事们的互动大多也很愉快，我学到了很多。在工作 9 个月左右的时间里，我从 ICT2（相当于初级职位）晋升到了 ICT3（相当于中级职位），据说对于应届毕业生来说，这个速度算是快的。

直到今天，我仍然怀念和 Swift 团队一起吃午餐的日子，听大家分享一些关于追踪 bug、破解基准测试以及揭示应用程序中的运行时问题的奇闻轶事，这些应用程序的下载量可能高达数百万甚至上亿。

话虽如此，接下来我要分享的是我在 Apple 期间影响我决定离职的经历。

工作机会

还记得当我收到 Apple 的工作邀请时，我如释重负。当时我已经找了大约 9 个月的工作了，同时还在以蜗牛般的速度攻读硕士学位，因为我已经失去了继续做研究的动力与热情。

但与此同时，我对这些大厂雇佣合同的具体条款有些担忧。这是我第一次签订长期的雇佣合同，我担心自己是否能够拥有业余时间所做的个人项目的知识产权，以及合同中是否有条款会影响我将来在其他科技公司工作的机会，等等。

在收到口头同意后但还没有通过邮件收到合同之前，我提前把这些顾虑告诉了招聘人员，并表示我希望在签约前先与律师讨论合同。

我还请求招聘人员通过邮件与我沟通，而不是通过电话，这样我就有时间思考问题，避免重复沟通。此外，我所在的办公楼有时信号也不太好。

招聘人员没有理会我提出通过邮件沟通的请求。后来，当他发给我最终的合同时，已经是周五快下班的时候了，而且合同附带了一个 3 天的期限，签署合同后可以获得 1 万美元的签约奖金。即便是在 2019 年，1 万美元的签约奖金对于硅谷一家大型科技公司的软件工程师职位来说也算不上丰厚。然而，考虑到过去两年我主要依靠助教的薪水生活，而且我的第一笔工资还要几个月后才能发放，眼前的签约奖金在当时感觉像是一大笔钱。

我设法在周一找到了一个当地的律师进行合同审查。这位律师表示，他通常只为更高层的职位做这种合同审查。他建议我和招聘人员进一步确认合同中的一些条款，但他对开源项目和知识产权归属等问题并没有给出明确的答案。我并不觉得这位律师完全理解我的问题，也不确定他是否真的站在我的利益角度考虑。而且因为我住在一个大学城，附近也没有太多律师。我为这次约 1.5 小时的服务支付了大约 500 美元，相当于我当时一个多星期的助教工资（税后）。

最后，我说服自己，基于我在网上搜索到的关于我的未来同事（通过他们在 GitHub 的 PR、Swift 论坛讨论和 Twitter 上的发言）的相关信息，他们看起来都是很好的人，所以我应该签下合同，尽管我非常不喜欢招聘人员的做法。

加入 Apple 几个月后，我和一位差不多同时入职的同事讨论了这段经历。他提到自己也有类似的想法，并且也有过一次与招聘人员之间不太愉快的沟通。基于这次谈话，我写了一封邮件给我的经理和上级经理，描述了所发生的事情。我相信我的同事也做了类似的事，因为我们都觉得让招聘人员为未来的候选人提供更好的体验是对部门有利的。

至于之后发生了什么，我没有得到任何反馈。那位招聘人员继续在那里工作，而我则在他之前离开了公司。

入职后，无法自由地为开源项目做贡献

在加入 Apple 做软件工程师之后，我发现，自此你的开源项目（OSS）活动会彻底消失。

要知道当初我加入 Swift 团队，主要原因之一是我非常喜欢参与开源项目。在面试时，我也特别问了 HR 以及另一位高级工程师，入职后是否可以在业余时间用自己的设备为其他非 Apple 的开源项目做贡献，或者开发自己的开源项目。得到的回复是，公司内部有一个审批流程，但可能会比较漫长，而且他们不认识有谁成功通过过这个流程。

当时我想，哪怕要等几个月甚至一年，只要最后能在自己的开源项目上“搞搞事情”或者为其他感兴趣的项目做贡献，我也是愿意的。

然而，等我正式加入公司并询问这个流程时，才发现所谓的开源项目审批流程似乎只是“空中楼阁”。已经有好几位比我资历深得多的人等了好几年，但他们的申请都卡在了某个环节，迟迟得不到批准。我加入后不久（可能是几个月后吧），公司成立了一个开源项目办公室，大家都希望这个办公室能加快开源项目审批流程，但在我任职期间，这个理想从未实现过。根据我 2023 年底和仍在 Apple 工作的前同事的交流，这个情况至今依然没有改善。

经历了这件事后，我在下一次求职时，明确要求公司给出具体例子，证明工程师们确实能够在开源项目上“搞点副业”。

我在离开 Apple 公司后的某一天，当我在 GitHub 上提交了一个 PR，才终于感受到了“解放”。

举个例子，在 Apple 工作期间的一个周末，我在用另一种编程语言“搞代码”时，遇到了一个编译器的 bug。当时，我已经习惯了处理编译器 bug，脑子立刻转向了创建最小化的重现代码。不久后，我发现已经有人在 GitHub 上提交了看似相同的 bug，但示例范围很大，还没有进行最小化处理，于是我在评论里发布了我的最小化重现代码。

大约一个小时后，我意识到这可能在技术上违反了公司的政策，想到如果被发现，我可能会被解雇。当时考虑到我的签证问题以及第一次求职花费了很长时间，我在 Apple 工作时非常害怕被解雇。

于是我立刻删除了那条评论。

在离开 Apple 之后，每当我随意评论或提出新问题时，我总会回想起之前的那个时刻。哦对，我现在可以毫无压力地这么做了。

有些人说，只有失去了某样东西之后，才会真正意识到它的价值。但根据我的经历，我觉得这种说法并不完全准确。其实，当你重新获得失去的东西时，也会有类似的感悟，尤其是当失去是逐渐发生的，而重新得到却是清晰可见的时候。

随着我逐渐意识到自由感对我的重要性，我认为自己今后不太可能再选择加入那些政策同样严格的公司了。

基准测试引起的矛盾

有一次，我们团队内部通过邮件讨论如何进行基准测试并提升编译器性能，我和一位经验丰富的同事之间出现了意见分歧。平时我们接触不多，这次的分歧主要集中在应该如何以及测试什么内容。

这位同事认为，我们应该以终端用户在 Xcode 中的整体性能为核心标准（比如从按下一个键到看到编辑器中更新的错误/警告提示的延迟时间）。而我则主张应该更专注于编译器本身的性能。我当时提出的两个理由是：（1）我们团队负责的是 Swift 编译器，而不是 Xcode；（2）如果将 Xcode 纳入基准测试，会引入更多复杂性，可能导致更多无关干扰因素。（需要说明的是，至少在当时，从源码构建 Xcode 在我们使用的苹果 M1 芯片发布前的 Mac 上是非常慢且资源消耗巨大的，如果设置不当还可能遇到一些难以调试的构建错误。）

讨论中，我引用了一些关于基准测试的研究演讲或论文（具体记不清了）。当时我想表达的观点是，正确进行基准测试将是一个庞大的工程，随机的内存分配决策和对齐变化可能极大地影响测试结果，而我们现有的工具难以将这些因素与干扰项分开来。因此，我建议我们专注于指令计数，因为它们更加稳定，即便与终端用户体验的改善关系没那么直接，但可以衡量出小的性能提升。

没过多久，我收到这位同事发来的 1 对 1 会议邀请，但没有明确的议程。

当我加入会议时，他首先询问了我的背景，比如我在大学学了什么，是什么让我对编译器产生了兴趣。接着，他开始问我一些与编译器和运行时相关的问题，还有一些关于某些技术实现原理的问题。我尽力回答，但对话的方向让我感到困惑。每当我回答除了“我不清楚”以外的内容时，他似乎感到不耐烦；而当我说“我不清楚”时，他反而追问更多后续问题。

接着，他问了一些历史性的问题，比如我是否知道谁开发了某些广泛使用的系统。我回答说不清楚。这种问答持续了一段时间，直到他说，他自己在这些系统的开发中扮演了关键角色。

然后他问我，基于这些情况，我觉得他和我以及引用到的基准测试的研究者，谁更懂基准测试。此时，我感到非常屈辱。我之前在邮件中并没有对任何人进行个人评价，只是专注于当时的问题讨论。强忍着内心的不适后，我回答了“您更懂”。这种对话模式重复了好几次。他用愤怒的目光和咬牙切齿的语气对我责备，我几乎快要哭了。最后，我勉强道了歉，虽然我并不觉得有错。

通话结束后，我独自哭了一会儿，然后写了一封邮件，尽可能详细地记录了整个对话，保存为草稿。我记得后来，我更新了之前的邮件讨论，表示我和这位同事讨论了分歧，解决了一些误解，并同意了他的观点。

在接下来的 1 对 1 会议中，我向经理提起了这件事。他也在之前的邮件讨论中，所以我请他看看，询问我的沟通方式是否有问题。他的回应是，那看起来像是一次正常的技术讨论，我的论点也合情合理。

随后，我向经理透露了与那位同事的对话，并问他我是否应该发出我保存的草稿。他说如果我觉得合适，那就发，并表示他会把邮件转发给更高一层的管理者，我同意了。最终，我发出了那封邮件。之后的情况我记不太清了，好像收到了来自更高级管理者的安慰性回复，表示他会和那位同事谈谈。

我再也没有收到任何后续反馈。那位同事继续留在公司，而我在他之前离开了公司。从头到尾，我没有收到过一句“抱歉”，更别提更长的道歉了。

之后的几个月里，我在和其他经验丰富的同事讨论问题时格外小心。

在 Apple 剩下的时间里，我避免在邮件讨论中回复这位同事的意见，也尽量避免选择与他一起合作的项目。后来我得知，团队中一些年轻成员也偶尔有过和他相处不愉快的经历，但具体情况他们没详细说。

推进自己工作职责之外的事情频繁遇阻

在硅谷的科技公司，工程部门的员工大多是男性和白人，苹果公司亦是如此。对于 Swift 团队来说，我们的很多求职者是通过 Twitter 上的职位发布申请的（包括我自己）。

当时，拥有编译器课程的大学的计算机科学（CS）学生通常也是以白人男性为主。虽然编译器知识不是实习和入门级职位的先决条件，但由于申请者中有很多人具备编译器相关的知识和兴趣，其他背景的申请者很难脱颖而出。

随着多元化、平等和包容性（DEI）的意识不断增强，注意到苹果开发工具部门内部的同质化，我认为如果能得到他人的支持并付出努力，我们有机会吸引更多来自不同背景的候选人。

当时，苹果确实与一些历史悠久的黑人大学（HBCU）有合作项目，但这些项目由公司内的另一个组织负责，招聘工作则是由另一个部门负责。

最初，我认为公司内部经常提及 DEI，这样会激发人们对改善我们候选人群多样性的兴趣，例如让我们的实习和职位招聘信息（公开可见）能够直接展示给HBCU 的学生。由于 Swift 是一个开源项目，Google Summer of Code 和 Outreachy 项目也提供了不错的机会，但这些项目在某些大学之外的学生中似乎知名度不高。

在某种程度上，我的预想是对的，部门里有几个人确实愿意支持这样的努力。当然，也有一两个人提出了“不要降低门槛”这种典型的反对意见，但我和我的支持者们强调，无论候选人来自哪个大学，面试流程都不会有任何不同。

然而，想要从负责 HBCU 合作项目的部门以及负责招聘的部门获得有意义的支持简直难如登天。即使我在邮件中同时拉上了我的经理和经理的上级，这些努力也没什么效果。

在招聘部门，我们的主要联系人是之前提到过的负责我们部门招聘的那位 HR。他完全不配合。当我们写下类似“我们想要做 X 和 Y 以增加候选人的多样性”这样的计划时，他的理解是“你们是在说我没有招到足够多背景不同的候选人”。

在招聘的过程中，尤其是针对大学生或者像 Google Summer of Code 这样的特定项目，时间是非常宝贵的。我花了不少时间写邮件、发提醒、安排一些会议，但最终并没有取得什么实质性的进展。

感到沮丧和无奈，我决定直接给几所 HBCU 的计算机科学教授发送邮件，看看他们是否有兴趣让我们为他们的学生做一些关于开源和 Swift 的讲座。

我和我的同事们一起准备了一次讲座，并在两所 HBCU 以线上形式进行，有大约 30 名学生参加。然而，除了在 LinkedIn 上与学生们建立联系外，我们并没有进行任何具体的后续跟进。

整个经历让我对试图在自己核心工作职责之外推动变革感到非常失望。我也开始质疑，是否除非绝对必要，否则根本不值得与其他部门的人合作。

这段时间，我反复观看了 Dan Na 的演讲《Pushing through Friction》（突破阻力），可能是在寻求一种认同感，想确认自己做的是“正确的事情”。回想起来，我只希望当时能更清醒地意识到，我以为自己是在突破阻力，实际上却是在做无用功，事倍功半。

举个小例子：当我加入 Sourcegraph 时，有一个潜在的未来项目，我觉得可能需要特别注意法律条款。我能在我们法律团队的 Slack 频道上提出这个问题，收到他们的意见，并很快与我们的法律负责人进行一对一的讨论，这让我感到非常惊讶和震撼。

当然，我明白，苹果的规模大约是 Sourcegraph 的千倍，我也不天真地认为在一家小公司有效的方法能同样适用于一家大公司。

我想，这段经历的整体感悟是：了解自己在哪种环境中能更好地发挥，以及在哪种环境中不太适合，是非常重要的。公司的规模、文化和激励机制，可能对你每天的工作产生比你想象中更大的影响，尤其是当你还是职场新人或刚从大学毕业的时候。

遗憾的是，我看不到有什么好办法能在不实际去不同公司工作前就搞清楚这些问题。

同工不同薪酬

大约在我入职 1 年 9 个月到 2 年左右的时间，我与经理的对话大多围绕项目状态更新和技术问题展开。我读了一些关于如何掌控自己职业发展的书籍，其中一个建议是询问经理如何才能获得晋升，甚至问一些具体的薪资数字，以便让讨论更加具象化。

我记得，起初我比较隐晦地向经理询问他对我的工作表现反馈时，并没有得到什么实质性的回应。因此，我遵循书上的建议，直接问我的经理，基于我目前的工作表现，是否可以在下一个考核周期内（几个月后）获得 10% 的薪资涨幅，如果不行，我还需要完成哪些工作才能达到那个标准。

我的经理当时表示他不确定，会稍后再给我回复。在我们之后的一次一对一会议中，他告诉我继续按照计划完成项目就可以。他还说，像这样的高薪资涨幅通常是晋升时才会有的，表现良好的情况下，正常的涨幅大约在 6%-8% 之间。由于我大约一年前刚刚获得了非正常晋升，所以再从中级（ICT3）升到高级（ICT4）是前所未有的，我需要在这个级别上保持一段时间的稳定表现。

我了解到公司有薪资等级结构，因此询问他是否可以向我提供这些信息。他说这些信息是不能分享的，只有经理可以访问。

当时，我认为这很合理，对他的回答也感到满意。

在我决定离职后，我得知一位与我做类似工作的同事，在我入职大约一年后加入公司，和我同级（ICT3），但他的基本工资比我高出大约 15%-20%（他的初始股票授予也比我所有的股票奖励加起来还要多）。

这让我感到既愤怒又清醒，本来还在犹豫是否要从 Apple 公司离职的，现在感觉没有留的必要了。我并不在乎金钱上的差距，而是觉得这背叛了我对经理的信任。

我知道有时候公开讨论薪资会很尴尬，但如果你真正相信同工同酬，那就应该为此尽自己的一份力量。如果你是我现在或以前的同事，我很乐意与大家交换薪资信息。

我希望未来能够有某个非营利组织管理跨公司、跨国家的匿名薪酬数据。可惜TripleByte 没能如愿，我曾希望它至少可以作为一个“开放”的数据仓库。

“我喜欢远程办公，不喜欢回到办公室工作的方式”

压倒骆驼的最后一根稻草是 Apple 公司的混合办公/返回办公室办公的政策。

在疫情期间，我一直住在南湾的 Sunnyvale，那时不清楚公司什么时候会宣布返工政策，也不确定是否需要在短时间内去办公室拿一些硬件设备用于调试某些问题。

大约在两年左右的时间里，我已经清晰地看清了自己更适合住在一个城市化的区域。然而，我不想把时间浪费在通勤上，这二者我无法兼得——如果我搬到旧金山/奥克兰/伯克利，按照公司混合办公政策要求，我每周至少有 3 天是要到公司去办公，然后去公司的路上单程超过 1 小时。

当我加入 Swift 团队时，已经有一些团队成员是通过远程办公的方式工作，所以我们的大部分协作都是线上进行的，多数会议也都有一两个成员通过视频电话的方式加入。有时候你还会发现，即使是一个团队的，也有人是在不同的大楼里工作。因此，即便大家都在库比蒂诺，开会的时候也不乏有人是在线上以视频的方式接入。

据我了解，在我加入之前，远程办公政策要更加灵活，但几年后这种灵活性几乎消失了，领导们不再批准员工远程办公了。鉴于此，以及看到许多其他公司允许更灵活的远程工作政策，所以当时听到高层说诸如“我们在疫情期间的成功是基于疫情前建立的线下关系”或“我很期待看到大家很快都能回到办公室一起工作”这样的言论，实在让人觉得有点荒谬。

另一个让我原则上感到不满的是所谓的“老员工特权政策”——那些在疫情前已经远程办公的员工并不需要遵守新的混合办公政策。我现在的雇主 Sourcegraph 也有类似的做法，但是在薪酬方面，Sourcegraph 最近从非地域差异化的薪酬政策转变为基于工作地点的薪酬，但对于那些在政策变动前加入的员工，薪酬并没有受到影响。

从逻辑上来说，我理解公司为什么这么做——他们希望降低优秀员工离职的风险。然而，我认为如果你在经营一家以公平为核心原则的公司，那么你应该通过股权或期权（或同等奖励机制）来奖励员工的实际贡献，而不是将工龄或工作地点等次要因素纳入基础工资、政策影响（如带薪休假、返岗要求等）等方面。当然，我也明白各个司法辖区的法律要求不同，因此根据员工所在的司法辖区，可能无法为每个人制定完全一致的政策。

无论如何，由于公司的混合办公返岗政策，我最终决定离职，开始寻找全远程工作或位于旧金山、纽约等大城市的办公室工作。最后，我加入了 Sourcegraph，这家公司主要是全远程办公的。

加入 Sourcegraph 并参与更多的异步协作和以书面沟通为主的文化后，我意识到此前我忽略了苹果为什么执着要求员工返回办公室办公的一些事实。现在我才明白，许多重要的讨论，尤其是涉及多个团队的讨论，往往是在会议中进行的。加上公司文化中对保密和知情权的要求，这意味着要了解某些细节，最有效的方式就是确保你参加了合适的会议。然而，在那些有些人远程、有些人坐在同一会议室的混合会议中，如果不特别留意，远程参会者很容易处于次要地位。

过去几年，我更加清楚地认识到远程办公的利与弊，也许我以后不会完全排除面对面工作的可能性。

最后的想法

很抱歉，我并没有什么完整的结论。

我不想给出像“你要为自己站出来”或者“你需要搞清楚自己想做什么”或者“直接辞职”这样的陈词滥调。因为即便你有幸找到一份好工作，你也可能会在某些时候遇到困难，而且很多事情是你无法控制的。

或许有一点收获是，反思哪些事情是你可以控制的，看看改变这些可控的事情是否能改善你的生活质量，这可能是有价值的。但这么说出来，似乎显得有点平淡无奇。

总之，就这样吧，这就是我之前在 Apple 公司任职的一些感受。