這篇用輕鬆聊天的語氣，在不違反保密協定的前提下，聊聊我過去12周在亞麻遜AWS實習的感想，最後有一些面對壓力的經驗整理和小技巧分享。對我如何找到這份實習有興趣的朋友，可以參考我之前寫的這篇: Landing a FAANG Internship - 2022美國暑期找實習分享

行前心理準備

在正式上工前總是各種揣測，一畝三分地和Blind裡眾多前輩文章我是刷了又刷。不熟習FAANG文化的朋友們可能不知道，但一句總結AWS就是江湖上壓力鍋代表，狠一點的組即為軟體工程師加班的人間煉獄，好一點的組又不免成政治鬥爭的戰場。學期中我讀了網上幾篇講同事間如何”鉤心鬥角”的教程文，想當初還學了不少怎麼在組裡適當處世以”鞏固地位”的小撇步。

喜憂參半

真的到了我灣區的辦公室後，記憶中的都市傳說卻彷彿描述另個世界一般：組裡同事彼此間氣氛禮貌融洽，每天下午五點不到就自己下班，電腦關上、手機靜音。我隊上十多個工程師，每天進辦公室的人，一隻手數的出來。默默觀察幾天後，我的總結是這兒的同事們work/life分明，上班工時雖短但專注極高，公私界線劃的很清。

我的mentor和manager也在第一周就撂下狠話，說我們的組文化雖好(上了Amazon內部某優良滿意度排行榜)，對人才要求也稍高，往年實習生一般拿return offer的比例只有AWS其他組的一半左右。這言下之意是提醒我要拚一點，我和組裡另一個實習生估計最後只會留下一人，也可能一個都不留。

實習進度分配

我在AWS這12周可分為三個階段：

• 前3周熟悉組裡各部位軟件架構，以及依據給我的project生出一個design document，需包含系統設計、資料庫架構、演算法效率分析和代碼流程。

• 第4~10周為internship重點，所謂”全力寫程式”階段，包含核心算法實現、上游和下游資源串接、資料庫架構實現和算法優化、撰寫unit tests、從零開始架設pipeline、以及初步銜接部分region(例如美國東岸)的high traffic壓力測試。Mentor表示，以我project的規模來說，只花7周時間寫代碼無法容許開頭設計上的缺失，因為沒有砍掉重練的時間。加上其中一周還安排去西雅圖出(遊)差(樂)，更加壓縮了進度。這也是為甚麼mentor和manager在第一階段push我比較重。

• 第11~12周則是實習收尾，除了在大老闆面前的final presentation/demo，也將我寫的service包裝部署到貨真價實的伺服器上運行(以US East 為首要壓力測試目標，隨後部署全球data center)，整理了real-time metrics dashboard以監控軟件效率和穩定度，再寫些wiki和documentation，方便同事日後在理解我的內部設計之後接手我的project。這麼一來，我就能除了貢獻一個新service之誕生，也學習到software development life-cycle的重點。

先苦後甘的真實體現

頭三周是最辛苦的。

因組裡技術偏硬，且mentor又將我onboarding的時程從兩周壓縮為四天以便我盡快開始趕design document，我連著十幾天都加班到深夜，試圖苦讀大學沒學過的系統設計 (system design)，才勉強在第三周提交了三十多頁的設計文稿，其中包含high-level system architecture 和 low-level design。

好處是基礎穩了之後，第二階段”代碼實現”照著設計就上手輕鬆多了。我通常早上十一點左右進辦公室讀讀郵件，和同事們吃完午餐，下午再專注工作到四點半或五點下班。沒有上下班打卡的壓力，工作時程很有彈性，只要自己對進度負責、確保在軌道上，不會有人質疑你工作時間長短。這七周奠定了我對我AWS這個組的感情，也讓我喜歡上了軟體工程師獨有的高成就感卻能自由愜意的生活步調。

總結

十二周下來，我寫了約一萬行代碼，交了三四十個code review，生出了數十頁的文本。當主管在最後一天將我叫進會議室，微笑著歡迎我畢業後回到這個組時，我覺得所有努力都值了。

實習注意事項

趁這機會我想分享一些實習好用的小技巧，供參考。

Return offer評分重點，以我主管的說法，不外乎就是實習生所繳交“code review (CR)的質與量”。我在第二階段代碼實現時，基本保持一天交一個code review，內容約數十至上百行代碼，通常是三四個git commit的結果 (這裡要說，每個組文化不同，還是以組裡習慣為主)。這時，鎖定幾位回復率高的同事格外重要。如果一個code review被block，遲遲無法merge的話，對隔天的開發效率會有影響。 我的作法是在心裡鎖定三位同事當code reviewer，其中一位是主要的reviewer，我每天都會請他抽空讀我的代碼，如果他當天忙，我就請另外兩位其中一位幫忙。我也會時不時和這三位同事分別更新我的進度，確保他們隨時了解我做的事情，這麼一來，請他們review我的CR時單位成本較低，他們也相對樂意一些。

第二個評比標準是“CR的平均修改次數” (average no. of revisions)。主管說，最佳狀況是壓在0~1次。一開始我有時因為和組裡所用convention不同，或是代碼邏輯上的粗心謬誤，CR被改到四五次以上，記得那時主管在期中評鑑時還特別指出這個數字，說這樣太高不行，要我改進。熟悉了組裡的編程習慣之後，加上每次細心檢查才交CR，我後期連續幾個CR都零改動，直接approve and merge。實習結束的那天，我的數字已壓低到約0.7次改動，與組裡平均持平。

我也強力推薦多向同事請教各種問題，溝通討論，努力吸取senior SDE的工作智慧。我在前三個禮拜，因為太短的時間需要趕出design document，我決定每天至少和一位工程師約一對一，請教system design不同層面的考量，以及組裡適合我研究的代碼範例。兩周之後，我的設計文稿漸漸變得言之有物，說白了就是集組裡同事智慧大成。我也不忘在文檔最後強調credits，這麼一來，同事們在第四周design review meeting讀到自己沒有白花力氣教我，心裡開心，日後或許也更願意幫我。

除此之外，多研究組裡優良代碼和前輩的design doc也是我覺得很重要的習慣。俗說 ”要寫好歌，必廣泛涉獵音樂；要寫好書，必多讀經典文學”。在軟件工程的職場上有好的設計和品質好的代碼我想也不外乎這個原則。

想對軟體工程師工作生態、應對進退、辦公室文化等技巧(包含溝通，談判，寫作，項目管理 etc)有更深入興趣的朋友，可以參考這篇一畝三分地的文章：4年AWS工作总结：从collegehire到senior的一点感悟。