Amazon Connectivity 軟體工程師工作日常：員工公開工作內容、公司文化、工作風氣｜工作甘苦談
無論你正面臨面試挑戰，或是在職場中努力站穩腳步，這裡整理了實用經驗與建議，協助你釐清方向、提升應對力，並在每個職涯轉折點做出更明智的選擇。
文章目錄
▲簡單介紹 Amazon 工作的內容和公司內的文化及一些心得。圖片來源: freepik
文/Matt Chiang
前言
由於今天請特休休假，但又找不到事做，就想到好久沒更新我的Medium了，所以想要來介紹一下現在的工作內容。如果撇開實習經驗不算的話，這應該是我第一份工作，而這篇文章是用來記錄我正職工作快一年的心得。這篇文章主要會簡單介紹工作的內容和公司內的文化及一些心得。
What is Connectivity
我目前正在Connectivity部門擔任軟體工程師，在加入Connectivity部門之前，我跟一般人一樣，肯定會問說什麼是Connectivity呢？根據Google翻譯的結果是連接性，但這個詞彙還是讓人無法很清楚知道在做什麼。
▲Google 翻譯的結果
所以這邊我想引用當初面試官問我的問題，來跟大家介紹什麼是Connectivity。
當你在連線WiFi、點下瀏覽器的搜尋後，會有哪些連線被觸發？
當時我在面試時聽到這個問題時，只知道要回答TCP三段握手、TLS的四段握手而已，但當時候的面試官卻一直往下問說還有哪些連線呢？沒有修過無線網路的我其實已經答不出來了。
不過好在實習過了幾個月，所有Connectivty相關的issue都有解過，所以我把目前所知的Connectivity Flow描繪在下面（大推同事推薦的PlantUML）。主要而言，會分作WiFi、802.1X、DHCP、DNS、Socket、TLS加密及HTTP。
Connectivity Team在做的事情，除了上述偏向Computer Network外的Connectivity，還有RF相關的Connectivity，而這個部門就是圍繞在上述方向的Debug或是Development。
在這個部門，我認為需要有與人合作及溝通和Dive Deep的能力，以前陣子在忙的案例，某個QA報了一個問題出來，首先SDE一定是要想辦法Reproduce出來，但試了兩三天後，我們發現無法重現出來，所以就需要仰賴與QA的合作，舉凡包更多的Debug Information請QA把問題Narrow Down，然而這個案例並不是這麼簡單從軟體層面可以解決的，所以我們又請QA利用WiFi Sniffer把環境封包撈出來，從封包層面來進行分析，進一步發現，我們的裝置有送出封包，但AP傳回來時，我們的裝置無法成功的收進來。在此階段，我們就需要開Ticket給WiFi Vendor請他們Debug是否有關WiFi Driver或是WiFi Firmware，來回Debug數次後，最後才發現到是某個訊號下，WiFi Firmware有些問題。
比較簡單的案例來介紹的話，在做測試的時候發現到AP的Scanlist是空的，但是可以成功的用隱藏網路連上去，以Connectivity的立場來看，本以為是應用層的Regression，但後來Dive Deep後，發現到是WiFi Driver的問題，當在開始某個Compiler Flag的時候，Scanlist Copy的流程會不一樣，進而導致Scanlist變成空的。
近期，由於NPI的開發到了一個段落，缺乏Wireless RF相關經驗的我，也被主管調去做Wireless RF相關的驗證及開發。由於我還在熟悉這方面的知識，所以不會在此篇文章介紹這方面的Connectivity。
16 Leadership Principles
在每週跟主管1 on 1的時候，我們都會討論工作上的事情，有一次主管傳了L4 SDE的Roadmap給我，才意識到在Entry Level最重要的是Dive Deep、Ownership和Deliver Results。
Dive Deep
如同上述介紹，在Amazon工作的時候，我們特別講求Dive Deep，要儘量找到Root Cause，而不是在問題的發生點上下Workaround，如果用Workaround解掉的話，到開發後期時，有很高機率會有Regression，到時候要解一個Regression，可能就要在用幾個Workaround解掉，使得程式碼變得不乾淨，不如在一開始發現問題時，就將問題定義清楚，找到Root Cause並把他解乾淨。
在剛成為Entry Level的工程師時，我會為了想表現自我，所以快速的遞交成果，卻不把事情看清楚透徹，直到年底的Peer Review時，我才發現大家對我的評價都是不夠Dive Deep，也有幾次因為不夠Dive Deep，導致Mainline的FW爛掉，被罵過才意識到Dive Deep的重要性XD
Ownership
什麼是Ownership呢？根據Amazon官方的回答
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job.”
其實還是很抽象，但簡單來說，就是主人翁精神。以一個簡單的例子來說，如Scanlist變成空的這件事來時，這件事情是因為打了WiFi Driver的Patch才導致這個問題，所以言簡意賅，這並不是我們的問題，我們大可以把這個問題丟給WiFi Vendor去找出Root Cause。但當我們看到這個問題時，我們必須要有主人翁精神，即便這不是我們的問題，我還是花了半天的時間幫WiFi Vendor Debug，在有Ownership的過程中，即便會比較辛苦，但對自己也有好處，如同我可以更了解WiFi Driver是怎麼寫的，流程是怎麼跑的，從中學習別人寫扣的邏輯。
Deliver Results
工作最重要的目的，就是要交付結果，但要如何交付結果，根據我主管的說法，最好的話是把做好做完美又做快，接著才是做好做完美但慢慢來，最後才是做很快卻漏洞百出。
以之前開發的一個Feature為例，因為我看的不夠深，而且又想快點完成，所以整個Process Flow沒有看透徹，就簡單的改了一行扣，當時甚至還認為自己改的扣很漂亮，最後沒想到導致Mainline的FW爛掉，又花了兩天才把Root Cause找出來，自從那次之後，我就意識到要把事情做好做完美才是重點，至於速度，除非有很急的Deadline，否則不如把事情做好比較重要。
工作風氣及時長
不諱言的說，我和同事的工時很彈性，忙的時候我會從早上九點做到晚上十點，但比較沒事的時候，早上會去健身，中午再進公司開始工作到六七點。像是在寫這篇文章的這週，我同事也請了一個星期的假去日本玩，根據我主管而言，不會有人在意做了多久，只會在意你有沒有把事情做好做完。
補充一點，Amazon很常用文件工作法，在開會討論事情的時候，通常不會有人在報Slide，而是先丟出自己寫的文件，給與會者一小段時間閱讀，然後圍繞在這份文件上討論事情；或是在遇到技術問題時，也會把解問題的流程記錄下來；在做新的Design的時候，也是需要寫文件描述你要如何做，會有什麼的Improvement、Side Effect等的Assessment。
我認為文件工作法是滿有效益的，每次都會在公司內部翻到很多很棒的技術文章，所以我也立志成為技術的分享者。有一次，國外同事來台灣出差，雖然我跟他不是到很熟，但去跟他買星巴克的途中，他說你某篇文章的用字遣詞很精確，歸功於前陣子狂磨雅思寫作，練就文法完整性和用字的精確性XDD
The Document Culture of Amazon
此外，我主管說可以申請Relocate去不同國家工作一陣子，但台灣這邊都還沒有人申請，其實我滿心動的，想去美加的Amazon Building工作一個月看看XDD。在寫文章的當下，公司有的福利包含每個月1399的電信費、免費午晚餐、零食櫃、升降桌等，我個人覺得還不錯，但如果有沙發休憩區那就更棒了。
如何申請及結語
願意看到這裡的讀者們，應該也會想知道怎麼申請Amazon吧XD
其實很簡單，只要上https://www.amazon.jobs/en/ 就可以申請了。
至於面試應該都是rounded-interview，大概會有四五輪吧？畢竟我是Internship Return Offer，所以我也不太清楚，如有需要的話，PTT或Dcard應該會有滿多面試心得的。但有需要幫忙Referral也可以私訊我的LinkedIn https://www.linkedin.com/in/cymattchiang/
總覺得出社會後，時間過得特別快，一轉眼在Amazon就待快兩年了，希望可以快點升L5，和有機會待五年換成黃色的Badge。
推薦文章>>
※本文由 Matt Chiang 授權勿任意轉載，原文《Amazon Connectivity 軟體工程師工作心得分享》
