北美生活引擎北美生活引擎
Page cover

亚马逊四年：非科班出身如何从SDE II晋升为SA II的蜕变之路

Loading component...

亚马逊四年：非科班出身如何从SDE II晋升为SA II的蜕变之路

本文作者将分享其在亚马逊 (Amazon) 四年间的职业旅程，从一名非计算机科学 (CS) 专业背景的工程师，如何在Fire TV (FireTV) 团队中从最初的挣扎求存，逐步成长为团队的“顶梁柱”，并最终成功转型为解决方案架构师 (Solution Architect)。

职业背景与亚马逊 (Amazon) 之旅的起点

作者的职业生涯并非典型的计算机科班出身，其背景多元而曲折：

•
本科阶段 (2006-2010年)：就读于国内某航空院校的航空相关专业，与计算机科学 (CS) 几乎零关联。大学一年级时仅学习过一学期的C语言编程。
•
初期工作经验 (2010-2012年)：在国内某小型私企担任弱电工程师一年半，期间仍与计算机科学 (CS) 无直接关联。曾尝试自学Java，但因环境配置困难而放弃。
•
硕士阶段 (2012年)：转专业申请并进入美国排名前20的大学攻读工程管理 (Engineering Management) 硕士学位，此时依然与计算机科学 (CS) 无直接关联。
•
自我转型 (硕士期间)：出于对编程的兴趣，在硕士二年级开始自学计算机科学 (CS)，修读了四门核心本科课程：数据结构 (Data Structure)、算法 (Algorithm)、数据库 (Database) 和面向对象软件开发 (OO Software Development)。
•
求职与首份软件开发工程师 (SDE) 工作 (2014年)：在毕业前通过刷大约80道力扣 (Leetcode) 题目，成功获得了某老牌美国企业 (美企) 的软件开发工程师 (SDE) 职位，正式开启了软件开发工程师 (SDE) 职业生涯。
•
加入亚马逊 (Amazon) (2016年)：跳槽至亚马逊 (Amazon)，直接获得了Fire TV (FireTV) 团队的SDE II (软件开发工程师二级) 职位，并在该团队工作了四年。期间经历了从团队“吊车尾”、备受质疑，到最终成为团队核心、独当一面的转变。作者于2020年决定平级转岗至另一个组织 (org) 担任解决方案架构师 (SA II)，正式结束了其软件开发工程师 (SDE) 的职业旅程。

SDE II 的“地狱”开局与挣扎求存

作者在亚马逊 (Amazon) 的初期可谓举步维艰。与之前工作强度接近于零的环境相比，亚马逊 (Amazon) 的工作节奏带来了巨大的反差。作者在上一家公司工作不到两年，技术基础薄弱，却在面试四轮后获得了SDE II的职位，这在当时令作者感到意外。

作为一名非计算机科学 (CS) 出身、Java经验不足三年、正式工作经验不足两年、Android开发经验仅一年的新人，作者被直接安排到一个由平均工作五年以上、全是SDE II和SDE III级别“大牛”组成的团队。初期在技术方面，作者连单元测试 (Unit test) 都写不熟，敏捷 (Agile) 开发流程从未实践，面向对象设计 (OO Design) 仅限于理论，对多线程和操作系统等核心概念也知之甚少。

为了跟上团队节奏并生存下来，作者在第一年拼命学习：从头补习Android知识、深入学习多线程、代码设计 (Code Design) 和单元测试 (Unit test)，并轮流担任敏捷教练 (Scrum Master)，甚至硬着头皮与其他团队沟通需求和预期。每天工作到晚上8点半或9点才离开公司，回家后继续阅读团队代码到深夜。周末至少有一天加班，甚至在通勤路上也会拿出电脑实践想法。长达两年时间，作者连做梦都在思考如何优化代码。

然而，即使如此努力，技术上的差距并非一朝一夕能够弥补。作者独立完成的第一个中型功能，其代码审查 (CR) 报告长达五页，完全缺乏设计，经团队资深工程师 (senior) 两天审阅、70多条评论、13次修改后提交，仍出现多线程 (multithreading) 错误，最终不得不推倒重写。第二个功能也因设计问题多次返工。担任敏捷教练 (Scrum Master) 时也疲于应付，难以有效优化流程。

更甚者，由于自卑和脸皮薄，许多不懂的问题不敢及时提问，导致在第三年仍会发现一些本应初期就了解的工具却一无所知。然而，作者也庆幸遇到了一个“绝世好组”：团队发展迅速，高可见度 (high visibility)，且长期缺人，从未有员工被淘汰 (pip)。当时的经理 (manager) 能力出众且耐心十足，愿意等待作者成长。团队中的资深工程师 (senior) 也提供了大量帮助和指导。

Loading component...

身心俱疲的“死局”与重获新生

高强度的工作和持续的压力导致作者在第一年结束后身体亮起了红灯：长期失眠、注意力不集中、记忆力下降、持续头痛，甚至出现情绪低落、对生活失去兴趣等症状，最终被医生诊断为重度焦虑。尽管医生建议治疗，但作者并未遵医嘱服药，而是通过参加冥想课程、获得老板批准的两个半月无薪假进行中印旅行 (印度和中国旅行) 以及家人朋友的支持，最终九死一生般地走了出来。

作者以过来人的身份强调：如果正在经历焦虑或抑郁状态，请务必寻求心理医生 (psychologist) 的帮助，并为自己争取长期病假。健康是革命的本钱，任何工作都不值得以牺牲健康为代价。

尽管经历了身心俱疲的阶段，作者对编程的热情并未消退。她始终认为编程是一种纯粹的逻辑游戏，没有模糊不清，只有逻辑严谨的推理和问题解决过程，这正是其魅力所在。两年后，随着旅行归来，焦虑症状逐渐缓解，记忆和思考能力也慢慢恢复。团队陆续有新人 (SDE I / SDE II) 加入，作者的经验得以发挥，通过带领新人获得了价值感。团队中一位能力超群的资深工程师 (senior) 小姐姐 (实际具备SDE III实力，后晋升) 的到来，成为作者职业生涯的真正转折点，让她从“负面典型”转变为“正面典型”。

SDE II 职场发展与突破

在亚马逊 (Amazon) 的第三年，作者迎来了事业上的真正突破。原团队因快速发展，需要剥离出一个新的子团队专注于与第三方对接的业务。作者答应加入新团队，因其对编程的热情有所减退，但又不想转管理岗，心态随遇而安。新团队的经理 (manager) 是一位能力出众的TPM (技术项目经理)，他积极争取资源，帮助作者主导了一个对第三方有重要影响力的新功能开发项目。

Loading component...

主导大型项目：从技术概念到落地实施

这个为期一年的大型项目，作者倾尽全力：

•
将一个新功能从技术概念转化为项目提案 (project proposal)。
•
与各个依赖团队 (dependent group) 协商，争取合作承诺。
•
担任技术负责人 (tech lead)，手把手指导各团队工程师 (engineer) 进行实现。
•
亲自完成了团队负责的数页代码实现。
•
兼职担任了一段时间的TPM (技术项目经理)，协调三四个依赖团队 (dependent group) 之间不同的发布计划 (release schedule)。
•
应对产品经理 (PM) 提出的各种新奇想法，并帮助其安排任务优先级。

尽管过程中状况不断，如其他团队的推诿、匪夷所思的错误 (bug)、质量保证 (QA) 测试环境搭建困难、依赖团队 (dependent group) 延迟、甚至原定客户的退出，以及设计和代码中的隐患。作者曾遇到工程师 (engineer) 在代码即将提交时质疑整个设计，甚至发现Google Android源代码中的错误 (bug) 需要协助修复等，作者仍保持了积极的心态，兵来将挡，水来土掩。经过大半年的努力，项目终于在功能上实现完整 (feature complete)。

目前，团队正在与第一个合作伙伴 (partner) 进行入职培训 (onboarding)，开启了新一轮的解决方案架构师 (SA) 和业务发展 (BD) 教育工作。尽管作者即将转岗，但对这个即将上线的项目充满期待。

破局之后：晋升SDE III 大型项目管理经验

主导涉及多个团队的大型项目，需要平和的心态和充分的心理预期：

•
合作挑战：其他团队可能会找各种理由推脱合作。作者曾与一个依赖团队 (dependent group) 协商三个月，甚至帮他们写了一半的技术文档，最终需要经理 (manager)、产品经理 (PM) 和高级经理 (skip manager) 共同介入才得以解决。
•
问题频发：项目过程中必然会出现各种意外状况，例如难以置信的错误 (bug)、质量保证 (QA) 测试环境问题、依赖团队 (dependent group) 延迟、甚至原定客户的退出，以及设计和代码中的隐患。作者曾遇到工程师 (engineer) 在代码即将提交时质疑整个设计，甚至发现Google Android源代码中的错误 (bug) 需要协助修复等。
•
时间管理：个人计划的任务往往难以在预期时间内完成，因为日常工作常被协助其他团队和质量保证 (QA) 解决问题所占据。

因此，作为项目负责人，必须沉着冷静，压得住场子，也能压住自己对不确定性的恐惧。

在项目需要其他团队协助时，以下几点至关重要：

•
先技术沟通，后经理承诺：可以先与工程师 (engineer) 简单讨论技术可行性，但最终一定要获得对方团队经理 (manager) 的承诺 (commitment)。
•
确保经理知晓贡献：务必让对方经理 (manager) 知道其工程师 (engineer) 在你的项目上所做的工作，无论是编写代码、代码审查 (CR)、研究 (investigation) 还是设计评审 (design review)。这能确保对方工程师 (engineer) 获得应有的认可 (credit)。可以通过会议、邮件抄送 (cc) 等方式提前告知，并在事后发送感谢信。这种换位思考的合作方式，不仅能建立良好关系，也能在管理层 (Management level) 留下积极印象，对未来的晋升反馈 (feedback) 大有裨益。

终章感悟与职业转型

在即将离开亚马逊 (Amazon) 之际，作者对这个工作了四年的地方充满了不舍。从团队初建、首个产品尚未发布，到如今团队的产品运行在每一个Fire TV (FireTV) 设备上，并为第三方开放了接口，这里是作者除了大学之外停留时间最长、成长收获最大的地方。与一群聪明、勤奋、优秀且友善的人共事，尽管经历了“天堂地狱”般的磨砺和“脱胎换骨”的痛苦，但作者深知一切都值得。

在亚马逊 (Amazon) 的四年，作者自觉没有辜负当年“貌似给错了”的SDE II录用通知，没有辜负团队提供的良好平台，也没有辜负自己所有的泪水和拼搏。作为程序员的这段旅程即将画上句号，作者想给所有在路上的朋友们几句话：

•
坚持：如果认定了方向，就坚持走下去，坚持总会带来好事。
•
转变：如果明显感觉不对劲，即使理性上说得通，但感性上极度别扭，那么就换一条路走走看。放弃一些在他人眼中不可多得的机会，选择一条别人无法理解的路，也许正是认识自我的起点。
•
耐心：如果模棱两可、犹豫不决，可以耐心一点，静观其变。一切都在变化，所以一切皆有转机。

作者最终选择平级转岗至解决方案架构师 (SA II) 岗位，预计于2020年10月正式开启职业新篇章。她认为，升职加薪都是浮云，人生最重要的是开心地做自己此刻想做的事。

Loading component...