距離被裁員都快滿一年了，但這幾天與朋友剛好提到Google本身產品上線速度偏慢，然後他也舉了Meta連實習生的程式碼都可以兩小時就推到production這件神奇的事情，真的是把速度完全擺在第一位。總之，聊著聊著還是決定在不涉及機密的程度稍微寫一下Amazon的整體狀況大概是如何。
以一個SDE來說，你會需要最基本的寫程式，寫程式具體環境怎麼設置每個組都不一樣，基本上這件事應該都會有個document去處理，只要follow step by step就能設置好，我就略過。
寫完程式基本測試沒問題之後，Amazon的流程一般會是送Code Review，Code Review本身就會試跑你的程式去檢測一些東西，比方說你寫的程式能不能build起來、unit test有沒有cover到你新增的所有程式碼。在特定的情況下即使unit test過不了有時候也會被准許通過(Ex: solve ticket, no time to add unit test)，總之跑完以後接下來就可以請同事過來Review給意見，如果他們留下一些很重要的意見，比如說請你縮減code或是符合組內的coding style，你可能就會需要送new Revision，然後從頭跑一次流程，如果沒意見就會approve，通常只要approval達到requirement就可以Merge進到pipeline了。但這裡其實會有個tricky的小技巧，有時候直接留下意見→送new Revision可能會被manager當作日後證明你能力不行的證據，所以有許多人其實都會在正式Publish CR前先跟需要Review的同事討論，這樣一來最後實際Publish的CR看起來就會只有1-2次的Revision，且Comment不多，對你本人就會加分。但也不能讓同事完全不留Comment，因為其實留Comment也是對自身能力的一個證明，所以最後就會達到一個默契的平衡。
進到Pipeline以後在我的組會先後進兩個測試環境，理論上進到測試環境以後我們就會開始測試開發的新功能，這時候就必須要做出一份document，不只列出新增的每個功能要如何測試，也必須要測試所有有關的舊功能，目的是為了確保這個改動不會導致舊功能出錯，也就是為了確保backward-compatibility。通常這一步會先跟組員還有有關功能的team討論，確定所有細節都有被測試到以後，可能就會開個meeting找一群組員一起花個1-2小時測試這些功能，如果沒問題就可以從A測試環境進到B測試環境，然後再測試一次，如果沒問題，就可以準備進入到正式的產品端了。
在Amazon，尤其是AWS，進產品端是非常重要的一件事情，畢竟號稱millions of customers，所以在測試環境沒問題以後，我們必須要寫一份MCM，詳細列出我們每一個Region(對，AWS服務區域很廣，需要分區推進度)會怎麼等待pipeline推進度，同時我們會怎麼測試每個區域的功能，這份MCM必須被所有這一個pipeline version有改動程式碼的人approve，除此之外還會需要專門的Test Engineer跟更高Level的人檢查過，確定沒問題，都approve以後我們才能開始推送到產品端，這也是我第一段說Meta兩個小時就能推到產品端是個很厲害的事情，至少在AWS這是不可能發生的XD(老樣子，Solve ticket除外，solving ticket會試another situation)。
現在回頭過來看在Amazon的這段時間，確實犯了不少錯誤，已經過了一年多的現在我其實也不覺得manager有做錯什麼事情，我當下對於整個組確實是完全沒貢獻的狀態，會造成這個有很多原因，但最主要的原因還是自身太過於傲慢，導致錯過了最佳的容錯學習時間，就舉個最簡單的例子，我一直到被裁員前，我都沒有架設local test environment，什麼意思？就是我每次理論上送Code Review的時候，其實都不知道我的程式碼跑起來究竟會是什麼樣子，我只能在瀏覽器上自己手動改API、條件去簡單測試，所以工作初期我有過CR完送到測試環境直接炸掉的案例，那這件事會發生就是因為我工作的前兩個月帶我的L6工程師很忙，我一直不敢問他問題，然後他覺得架設環境很簡單交給別的L5工程師帶，別的L5工程師又誤會他的意思沒有幫我架設，我又不好意思再問一次，其實這完全是我一開始就跟manager還有他們反應就能解決的事情，但我卻沒有這樣做，怪誰呢？當然是怪自己，communication is very important，別害怕出錯，要害怕的是沒有改善，但當下就是處在一個不敢麻煩別人的心態，最後既然不敢麻煩別人，那麻煩就會找上我。
當然Amazon本身文化是相對有毒的，有待過的人大致上也不會否認這一點，像是PIP還有各種互相牴觸的principle，以及daily standup都算是會讓裡面的員工難以完全坦承互相幫忙的幫兇(比方說有個資深工程師幫你花了一兩個小時Debug，他就會在隔天的standup中提出這一點，這會顯得好像你很爛，可是如果他不說，就會變成他為什麼昨天只做了那麼少的事情)，但撇除掉這些東西，我認為待過Amazon整體還是一個加分的體驗，無論喜歡與否，畢竟不是每間公司都會有一個完善的制度來應對幾百萬個客戶的情況，尤其對象是business的時候通常又要比對一般使用者更嚴謹(通俗一點的講，面對企業用戶出錯了要賠的錢多很多)。
這大概會是我最後一篇提到Amazon的事情，被裁員之後的現在跟未來都很難想像我還有機會回去Amazon，希望我下一篇是分享被裁員後如何找到工作的文章。