來源：一畝三分地Warald
導語
關於亞麻的負面評價很多，有來分享糟糕的實習體驗的，也有來講述自己兩年內兩次被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 tombe 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.與諸位共勉。