4年AWS工作總結：從collegehire到senior的一點感悟

導語

近期一畝三分地裡關於亞麻的負面評價很多，有來分享糟糕的實習體驗的，也有來講述自己兩年內兩次被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，男女比例平衡，是各位發展的好去處。

如果有興趣的話請在一畝三分地裡私信你的簡歷。

經驗總結

新入職場，如何擺脫學生思維

加入 AWS是我的第一份工作。之前因為一直準備出國，並且在 PhD program 裡，所以一直以來從來沒有實習過。我很幸運地快速認識到了學生和工作的不同：

1、在學校裡，多數的學習是透過老師。

老師會負責系統地講述一個方面的知識，並且安排足夠的練習來鞏固知識。在工作中學習必須要靠自己，沒有人會來主動教你任何事，也沒有人有義務教你。

2、在工作中你透過完成領導給你的任務來賺錢，而在學校裡你付錢來讓老師和助教幫助你完成課業任務。

所以工作中的任務必須按時高質量地完成，切不可偷懶。

3、學校中的作業和專案都是 well-defined, well-understood，而工作不是。

接到的任務可能非常地模稜兩可，或者你不是完全懂該怎麼做。去弄清楚弄懂如何完成這個任務是你的工作的一部分，而不是別人的。

做到這幾條可以讓你快速地給你的組和你領導留下一個好的印象，你的初始 performance 不會太差。

然而，如何在組裡站穩腳跟並且逐漸成為組內更加重要的一員，則又需要其它的技能。

入職新組，如何站穩腳跟

這些技能不僅對剛開始工作的人適用，對在職跳槽或者加入其他組的也同樣有幫助。

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的升職報告。

提升軟實力，助力升職

作為一個非科班出身，從未獲得過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 內被邊緣化，那麼你的升職報告很有可能會被其他組的比下去。

所以，下一節我來聊聊政治生態的內容。

如何看待政治生態

有句話說得好，有人的地方就有江湖，在公司裡更是如此。

在一個 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 打斷還是要來找你解決問題，為何要讓你老闆丟失面子和浪費時間呢。