近期关于亚麻的负面评价很多，有来分享糟糕的实习体验的，也有来讲述自己两年内两次被dev开除的。
出来分享的同学们，并没有刻意丑化亚麻，相反，态度平和，描述客观，所以我们把这些帖子全站置顶了。
但是，亚麻也有好的地方，有些同学加入亚麻之后，也很适应。我们也全站置顶了两篇讲如何在亚麻生存的文章，今天推送给大家的是其中的一篇。希望能帮助大家了解亚麻这个复杂体。
justwell 发表在职场达人板块
经历介绍
说来实在惭愧，拿了CMU PhD的offer读了一年就转成了Master跑路，跑路时候也没有刷什么题拿什么大包裹，最后随便就从了亚麻的标准new grad包结束了自己的学生生涯。
说到签亚麻也实在是机缘巧合。本来也是随便投的，结果电面OA啥也没有，recruiter 一封邮件让我去西雅图面试。
我当时一边上着3门load很重的课一边面试，根本抽不出时间飞西雅图（当年匹兹堡到西雅图还没有直飞）去面试，所以找了个理由跟recruiter说不去面试了。
然后刚好又有了两个西部的面试，中间多一天，就跑过去面试了。面试当时是群面，给了一台很破的ThinkPad写代码，然后跟面试官讲解自己的代码。
4个小时时间我好像1个多小时就写完了，剩下的时间都在写注释和unit test。然后第二天就拿到了一个标准包。
选组也是很有意思，因为家庭原因我必须呆在匹兹堡附近地区，所以问 recruiter 东部有没有AWS的组。
Recruiter告诉我在一个叫做 Herndon, VA 的地方有 EC2 组。我从来都没听说过这个地方，但是开车离匹兹堡只要4个小时，就从了。
就这样，我就加入了一个很小的 remote office，然后亲历了它变成 AWS 除了西雅图外最大的 office 和 HQ2 的过程。
先报一下 Timeline
2015年5月 - 2017年2月 SDE1
2017年2月 - 2019年2月 SDE2
2019年2月 Senior SDE
前排插播广告。
Herndon, VA office 有大量 SDE 及 SDM 和 TPM opening。
无论你对前端，后端，或者底层实现感兴趣，想参与 AWS 最强的 infra 工作还是新兴的 security（AWS CISO就在这个office），这边都有合适的岗位。
DC地区气候宜人，风景优美，房价税率不高，学区极佳，路上没有 homeless 和 needle，男女比例平衡，是各位发展的好去处。
经验总结
1
新入职场，如何摆脱学生思维
加入 AWS是我的第一份工作。之前因为一直准备出国，并且在 PhD program 里，所以一直以来从来没有实习过。我很幸运地快速认识到了学生和工作的不同：
1、在学校里，多数的学习是通过老师。
老师会负责系统地讲述一个方面的知识，并且安排足够的练习来巩固知识。在工作中学习必须要靠自己，没有人会来主动教你任何事，也没有人有义务教你。
2、 在工作中你通过完成领导给你的任务来赚钱，而在学校里你付钱来让老师和助教帮助你完成课业任务。
所以工作中的任务必须按时高质量地完成，切不可偷懒。
3、学校中的作业和项目都是 well-defined, well-understood，而工作不是。
接到的任务可能非常地模棱两可，或者你不是完全懂该怎么做。去弄清楚弄懂如何完成这个任务是你的工作的一部分，而不是别人的。
做到这几条可以让你快速地给你的组和你领导留下一个好的印象，你的初始 performance 不会太差。
然而，如何在组里站稳脚跟并且逐渐成为组内更加重要的一员，则又需要其它的技能。
2
入职新组，如何站稳脚跟
这些技能不仅对刚开始工作的人适用，对在职跳槽或者加入其他组的也同样有帮助。
1、在你的 launch plan 里，你老板大多数情况下都会让你跟组里的每个人聊一聊。
不要小看这个过程，这是你给你组里的同事留下的第一印象，而且取决于这个第一印象，他们会在潜意识里透露出更多的信息或者在接下来的过程中对你提供更大的帮助。
其次，每个人在组里的情况都是不一样的，每个人给你提供的角度都是不太一样的。但是如果好几个人都跟你提到某个事，可能这是一个所有人都觉得重要但是没有时间去做的事。
这一点非常重要等下还会再提到。
2、你的前几个 project 都是给组里干一些没人愿意干的脏活累活，基本不可能有什么好的内容。
你想想吧，组里有那么多可干可不干的杂活，当你老板手下突然多了一个人（虽然这人基本没啥用但也是个人吧），是不是可以让这个人去做做这些事情。
而且，你能不能按时，保质保量完成工作谁的心里都没底，怎么可能把重要的活交到你手上。
所以，你必须把这些活勤勤恳恳任劳任怨不折不扣地完成，因为你如果做的不好还不自知的话，你在这个组的初始印象就很差了。
在做的过程中不断了解组的 software stack 和 business，去理解为什么这个活需要完成（而不是其它的）。
3、不动声色地观察组内的情况，鉴别组内大佬、帮派，以及组内关系。
通常老板都会指定一个人带你，但是带你的人可能本身不愿意带人，带人的能力有限，或者在组内缺乏话事权。
所以盲从带你的人的指导有时可能适得其反。
注意，我说的是盲从，在绝大多数情况下带人的人都是好的，但是还是要鉴别少量的坑，因为一旦你进去了就要花大把的力气把自己挖出来。
4、问过的问题如果不能保证全部记住并且理解，请把答案记下来。
切记不要问重复的问题！所有人都很忙，回答你的问题或者帮助你不是他们的本职工作。
组员拒绝帮助你不是他们不乐善好施而是他们有其它的工作要去完成，帮助你则是他们乐于助人。
所以，千万不要问重复的问题来浪费他人的时间。但是，有问题如果自己不能快速地在内外网找到答案就尽管问，没有人会因为你问很傻的问题而看轻你。
在他们解答你的问题，或者帮助你寻找答案的过程中，观察他们解决问题的方法，工具和途径。这是一个很好的学习的机会。
所以，通过前几个项目，你应该完成以下一些内容：
1、展现你按时，保质保量完成任务的能力；
2、提高你对系统的知识，以及相关技能的理解；
3、 增进与组员的关系，给他们留下一个好印象；
4、了解公司内部和外部常用的解决问题的方法和方式。
但是，光完成这些会让你的角色停留在一个很好用的打杂工上。你需要另外的几点来提高你的影响力：
1、留意如何解决前面提到的，大多数组员提到的某个事。
这个事基本上都不难解决（如果很难解决或者理解他们跟你说没有用），但是都不在任何人的工作列表上。如果你能试着在剩余时间解决它，你将瞬间获得组里人的好感。
2、阅读组内的代码，了解各个组件是如何工作的。
这不是像看小说一样浏览代码，而是能够了解实现的细节，并且知道相关代码的位置。这是一件非常耗时耗力的工作，但是对你的下一阶段工作非常有帮助。
3、发现一些新知识，扩展组内的知识合集。
其实你会发现不是所有人都懂所有的事，很多事情可能你知道别人并不知道，以至于代码中会出现很多很蠢的设计。但是如果应用了新知识，可能某些部分的 performance 可以大幅提高。
这几点都能增加你获得更好的 project 的几率。
当老板分配任务的时候，她考虑的内容有谁能在最短时间内完成这个任务，给某人的风险有多少，某人现在做的事和这个事相比哪个更重要，等等，并且很多时候会问组里核心人物们的意见。
这个时候，如果有人愿意举荐你，并且你能再此之前展现出足够的 domain knowledge 和能力去完成这个任务，那将它分配给你的风险降低而几率上升。
介绍一下我自己的经验。
我2015年5月入组的时候，分配到的任务是搭一个测试环境。
除了各种杂活（比如创建数据库，设置运行环境）以外，唯一的 coding 就是把所有系统中的 ID 从 int 改成 long。
虽然这个项目烂到爆，但是能让我熟悉AWS内部的各种环境，工具，以及流程，并且可以打开熟悉各个组件。
其次，在跟组员 1:1 时候所有人都说组内的系统没有 document，因为所有懂的人都忙着干活。
于是我向每个部分的 domain expert 了解各个部分的细节和实现，并且把所有的内容汇总成一个 wiki。
虽然写得很烂还有错误，但并不妨碍组内每个人都把这个破烂 wiki 向外推广，以至于时至今日，这个 wiki 还是组内软件架构的主要参考资料。
在同年8月某次讨论如何提高某个重要组件性能的讨论上，组内最资深的 engineer 说到了关于 throttling 的内容，而且他的理解是错误的。
我刚好前几天看到相关 wiki，于是提出不同的见解并展示了这个 wiki，使大家对我刮目相看，并且我提出的改进很小，但是直接获得了3倍的性能提升。
自此以后，我没有继续打杂而是开始做好项目，继而在16年底就有足够的内容提交SDE2的升职报告。
3
提升软实力，助力升职
作为一个非科班出身，从未获得过CS学位，Leetcode 也只停留在340题的人，我来谈谈除了硬实力外的部分。
软件工程，首先作为一个工程项目，注定需要协调各方，多人合作。
所以尽管代码、设计、实现和 debug 能力很重要，其它的软实力是让项目进展顺利的重要部分。
而项目的进度则是你老板的指标。 所以在硬实力达标的情况下，软实力很大程度上决定了你能否升职，以及多久可以升职。
1、公司文化。
无论Amazon 的 leadership principle 多么洗脑，无可否认的是大大小小的事都用它来衡量。于是深刻理解公司文化并掌握其精髓则是 align 并提高自己 performance 的一条捷径。
2、沟通能力。
英语能力非常重要。这里不是说你的口音或是你的语法，而是你是否有能力在有限的时间内简洁明了地表达自己的想法和观点。
如果你说话结结巴巴或者用词不准确，让与会者或者阅读邮件的人感到困惑甚至不耐烦，那么你将逐渐被边缘化，丧失话语权（或者无法进入组内核心获得话语权）。
同时，如果不能有效地跟你的同事扯淡聊天，你将无法跟他们增进感情。所以，能够清晰表达自己观点、感情、和意图的英语能力至关重要。
3、写作能力。
特别是在 Amazon 大大小小的事都会被写成文档，开会的时候供与会者阅读和讨论。
另外，engineer 的 documentation 也是衡量技术能力的重要依据之一，甚至比代码更加重要，因为相比于代码，审核这些内容的人更容易读懂文档。
如何撰写直击人心的文档，画出简洁清晰的配图，则跟PPT一样重要地技巧。
4、写作意识。
除了能力，意识到什么时间，什么内容需要被记录下来也是非常重要的。
特别是跟老板谈升职的时候，如果工作记录非常清晰的话，撰写升职报告会非常的容易。
相反，如果你自己都无法定性定量地描述你做过的工作的话，你无法指望老板会意识到你的工作内容，并且提交令人信服的升职报告。
此外，记录某些设计，实现，或者想法会对今后的工作和对外的合作产生很大的帮助。
5、合作能力。
和组内同事高效合作是一个合格的工程师的基本素养，而和 org 里其它组，甚至不同 org 的组合作则更有讲究。
首先，根据组之间的关系远近和先前的交集，两个组之间的合作意愿大不相同。
其次，不同组的 priority 不同。如何说服其他组正确理解你的需求，估计所需时间则需要一些技巧。
我的经验是了解对方的行事方式和语境，并将需求用对方可以轻易理解的方式表达出来，也就是所谓的 speak in others’ language。这个在大公司里更为常见。
做到这些可以让你成为一个称职的SDE2，而要升到 senior level 则需要一些其它的技能。
1、项目管理能力。
大多数情况下，你的老板，或者 program manager 会进行项目管理。
但是很多时候他们太忙管不过来，或者项目不大他们不想亲力亲为的时候，项目管理能力将会起到很大的帮助。
试想一下，如果你的老板可以放心地将一个多人，甚至跨组的项目交到你手上，可以信任你将技术设计和项目进度都搞定，他就可以减少工作量并花更多时间在其它事情上，提高组内的总体产出。
2、鉴别风险的能力。
如果你能运用你对技术和系统的深入理解来准确预测系统风险，比如 scaling 或者 operational 的风险，并及时向上提出，那么即使没有被采纳而发生事故，它也会是证明你技术能力的重要依据。
此外，如果能够在早期甄别项目管理中的风险并及时应对，可以帮助优化项目进度。一个例子就是鉴别项目中 unknown unknown 的能力。
3、对自己的认知有清晰的认识。
知道你自己不知道的并不可怕，但是如果不知道你什么不知道则是很大的风险。
比如错误估计自己在组内和领导心中的地位和印象，错误估计（高估和低估同样致命）项目的复杂度和所需时间，等等，会对你的职业生涯造成不小的挫折。
4、谈判能力。
无论是与其他组交流，还是和老板沟通，如何通过谈判实现自己想要达到的目的是一个很重要的能力。
很多时候，在合适的时机以恰当的沟通方式表达出自己的意愿可以达到事半功倍的效果。
5、学习能力。
随着级别的提升，工作的广度和深度都有大幅度地提高。如何快速地理解你原本不熟悉的内容，并根据经验判断方案的可行性和合理性是衡量一个 engineer 是否达到更高层级的重要能力之一。
6、商业的敏锐力。
除了日常的修修补补之外，如何扩展组的 scope 开辟新的领域，新的 feature 也是非常重要的。
和其他组核心成员、老板，及领导层的良好关系。大家都愿意和 no BS 的爽快人合作，不是吗。
当然，这些能力是提升至高级别的必要不充分条件。特别是升至L6及以上的级别，其它的因素也必须要考虑在内。
大部分公司的升职报告都需要经过某种 committee 讨论通过，如果 committee 是由 org 的 leadership 带头，那么上层的政治斗争也会起到很大的影响。
如果你的老板 performance 不好，或者在 org 内被边缘化，那么你的升职报告很有可能会被其他组的比下去。
所以，下一节我来聊聊政治生态的内容。
4
如何看待政治生态
有句话说得好，有人的地方就有江湖，在公司里更是如此。
在一个 org 里机会总是有限，各个组之间的关系也非常微妙，领导平衡各路诸侯的手段也各式各样，所以 了解、分析、掌握上层政治生态十分重要。
首先，了解跟你相关的直系 org 的分界线，比如某个VP，Director，和 senior engineer。
了解每年的计划和 head count 的分配是怎么运作的，以及你所在组的 visibility 的边界。
其次，了解你的老板和你老板的老板在 org 内的表现和地位，以及这两者的趋势。
如果你老板和你的组在 org 中处于边缘地位，没有什么 visibility，或者常年没有新的 head count 和较大的成就，那么你就要小心了。
毕竟在整个 org 中，你的 performance 是基于你老板（甚至是你老板的老板）的。
再次，了解和你的组合作紧密的组的情况。
如果两个组分属不同 org，那么你作为 engineer 必须和对方 engineer或者 manager 维持一个良好的关系，哪怕做到脸上笑嘻嘻，心中mmp也是必须的。
特别是你的老板被对方压制，而且你的组还有求于人，那么就算跪舔也得做。毕竟你把关系搞差了，影响工作的是你的老板。
如果是同个 org，那通过比较两个组的话事权可以大概分辨出它们在 org 中的地位高低。
最后，了解每个组的决策者和最有话语权的人并与之建立良好的关系可以在关键时刻为你的工作或者升职锦上添花。
所以，作为 IC 的 engineer 们，选择一个好的老板至关重要。
一个有能力有远见有进取心的老板会完全改变你的职业生涯。
就像 Sheryl Sandberg 所说，When companies grow quickly, there are more things to do than there are people to do them. When companies grow more slowly or stop growing, there is less to do and too many people to be doing them. Politics and stagnation set in, and everyone falters. He told me, “If you’re offered a seat on a rocket ship, you don’t ask what seat. You just get on.”
如果不选择 start up，那么大公司里迅速发展的组也可以实现一样的目标。
一个好老板可以在较短时间内提升你的能力，提供足够大足够多的机会来满足你的发展，剩下的就靠你自己了。
最后说说和老板的关系。
一个有远见的老板需要有能力的人来实现她的梦想，而一个人的精力总是有限。
那么你需要做的是帮助你的老板实现她的目标，减少让她操心的内容。比如：
汇报发现的问题的时候提供解决方案。没有解决方案的问题基本上等同于牢骚.
所以在向你老板报告发现的某个问题的时候，请使用以下格式：我发现XXX问题，我认为该YYY来解决。如果你没有解决方案，可以说：我认为需要ZZZ的加入来解决这个问题。
适时给老板挡枪，但是要让老板知道。
有的时候，由于本组的过失对方组向上 escalate 的时候，如果问题很快就能解决，不妨花几分钟把问题解决一下。
然后给老板写个邮件说XXX组发现了YYY问题，escalate到了ZZZ那里，我已经解决了。
如果你有足够把握能够恰当处理的话，不要盲目地把所有事都推给你老板。
毕竟你老板被 escalate 打断还是要来找你解决问题，为何要让你老板丢失面子和浪费时间呢。
最后忠告
· 没有人因为要欺负你而把你招到组里。如果你觉得自己在组内受到了不公正的待遇，请仔细回想是由什么因素造成的。
· 如果你觉得自己在组里功劳很大而不受重用，很有可能是你的自我感知和对功劳的标准产生了偏差。
· 老印 manager 也是人也得有人给他出活。除非是自上而下全是老印，很难出现一个组都是废人却一人得道鸡犬升天的。毕竟能扯也是一种能力，能靠嘴就把事情做了是不是比写代码可以更快更多地出活。
· 不积跬步，无以至千里；不积小流，无以成江海。Consistency matters in performance.与诸位共勉。