本文作者是成功轉職軟體工程師的AC畢業生Harry，這篇針對作品集在履歷上的展現以及分享一些面試上的心得，希望能對一些正在轉職路上的讀者未來在找工作或準備履歷上會有些幫助。
面試作品集&面試心得
根據我自己面試下來的心得，對於轉職者，履歷上作品集的重要性絕對佔前兩名(還是會依據公司的類型和喜好而著重的點不同)，當然這不是說作品集一定要做的多特別，或是多讓人驚艷，但是放在履歷上的作品(慎選，選了就要知道自己想要呈現什麼給別人)要盡量能讓面試官產生興趣，甚至能針對這個作品問問題。
前端作品集如何準備：7種累積作品的方法
因為這總比很多其他面試前沒辦法預期的問題來得有把握很多，畢竟這是花時間做出的作品，一定有很多故事可以說，相較個人特質或優缺點之類的問題，更能言之有物而不是一聽就知道只是再塑造形象
以我來說，我主要放了兩個作品，分別是個人專案和協作專案，會把這兩個專案當成主要的作品集展示對我來說想呈現的東西不同，以下我分別簡單說明
個人專案
在做個人專案的時候，方向就是希望除了可以盡量展現出技術能力外，也能夠做自己想做的產品(我自己做起來會比較有熱情，也更願意花很多時間一直重複去修改細節)，這樣的方向在經歷大大小小的面試過後我覺得還不錯，因為通常面試官期待junior的技術能力有達到他們要的門檻就好。
他們更多的是希望知道你做產品時的想法，例如為什麼做、遇到什麼困難、如何解決困難和使用者體驗如何優化等等問題
這些都是相較於產品技術細節，我在面試時更常被問到的問題。
所以常常看到網路上很多前輩建議不要直接把課程中的作業當成作品集，我想並非完全不行，只是必須從這個你也許很得意的作業中，硬擠一些故事出來回答，可能會相對比較沒有內容(先不論有經驗的人一聽就知道在畫虎爛，自己講起來也會心虛吧 )，也就造成無法在面試官眼中脫穎而出。
所以我會建議可以針對你想放在履歷上的作業，加入自己的一些想法，例如你覺得原本寫的code太亂or太老，可以利用最新的語法重構並整理；或是你覺得UI不夠漂亮使用者體驗不夠細緻，重新刻一個自己喜歡的加入一些自己的小巧思又或者是在專案中加入一些你最近覺得很酷的新技術或新功能，這些都是能讓你在面試時幫自己加分的地方。
AC學期三期末協作專案 — Simple Twitter
先簡單介紹一下此專案的User Story，此app具有註冊/登入功能，登入後可以設定更改自己的個人資訊(如頭像、名稱、email、密碼等），在首頁可以看到其他使用者的貼文並可以針對貼文做出回覆及按讚/收回讚，首頁的一側有使用者推薦名單，可針對使用者追蹤/取消追蹤，首頁的另一側則是選單，可以進入個別使用者頁面、個人資訊設定頁面以及發送推文的按鈕。其他更細節的使用者體驗我就不一一贅述，讓讀者保留一點想像空間。
協作專案分工 (GitHub)
專案協作主要為三人一組，可以分兩種合作形式進行，分別為三人全端及一人前端兩人後端的前後端分離模式，而我由於已經體驗過以全端的形式做出專案，本著想體驗看看前後端分離是如何協作下，我與另外一後端位夥伴找了一位前端夥伴就開始進行實作。
在協作裡，我負責後端中的API文件撰寫、API基本架構的建立、後端git的整合以及通過各條路由的自動測試，另一位後端夥伴則是負責在前後端分離下實作註冊/登錄/認證功能、種子資料的設計以及專案工具建立(如Slack、Trello等)，而前端夥伴則是利用Vue框架建立前端畫面以及以API串接後端資料。
協作中的收穫
此次協作中的我和另一位後端都算是兼職和全職進行專案協作，而前端夥伴則是還有軟體工程師的工作，且協作專案的限時內又恰巧遇到前端夥伴工作繁忙的時期，故前端夥伴要能抽出時間進行前端進度實作和進行小組協作討論會比較困難，加上我與另外一位夥伴能幫忙前端的部分有限，造成最後的成品完整度不如預期。
有了這樣的經驗，讓我反思自己在做選擇前要先評估自己的能力，此次由於不熟悉Vue框架，故即便後端部分完成後要協助前端，也只能依靠忙於工作的前端夥伴提出架構解釋和需求才能進行部分協助，並無法直接就前端專案進行實作，造成很多能夠利用的時間無形中浪費了。
黑客松挑戰 (GitHub)
完成了基本功能後，AC發出了限時兩天的挑戰功能-即時公開聊天/私人聊天，在完全沒有提示的狀況下，由組員們自行上網查找資料完成功能規格，而我們這組主要是以socket.io技術融合現有的Node.js/express+MySQL資料庫的架構來完成，詳細的實作技術內容我會額外再開一篇分享，這裡想用來分享實作的心路歷程。
有了先前的經驗，在了解前端夥伴工作繁忙下，若要能提交較完整的作品，勢必要以我與另位夥伴較熟悉的全端方式進行，這樣不僅能進行socket.io技術的攻略也能以Handlebars進行畫面的呈現，於是在我與另外一位後端夥伴的討論下，決定讓前端先於有空時專心把基本功能完成，而我與後端夥伴來完成限時兩天的挑戰題。
我們的分工為，我負責攻略sokcet.io的技術以及前後端邏輯架構的建立，而另外一位夥伴則是負責登錄認證機制的更動以及刻出要求畫面。
Socket.io實作心得
一開始按照socket.io官網提供的資料及說明，照著做很快就把公開聊天室的功能做出，接下來則是必須開始加入自己的一點想像及額外資料，需融入資料庫CRUD的功能和Node.js/express的架構。
這之中最難也最多BUG的部分就是私訊功能的實作了，原先以為公開聊天室做完，也於官網上有稍微了解私訊功能，實作上應無大礙，沒想到這個功能竟讓我兩天可能睡不到六小時，哈哈！
實作後才了解私訊功能必須對socket.io技術有更正確的認識，以及於官網上查找更多語法的幫助才有機會完成，途中好幾次都以為自己好像完成了，但其實都會有很多不合理的Bug存在，隨著程式數不清的debug，我腦中對socket.io運作邏輯的認識也一步一步的在debug，直到最後從原本的自以為了解到「原來是這樣運作！」的感嘆時，才終於算是完成私訊的挑戰功能。
協作專案與面試
對於Junior面試者來說，我參與過這麼多場面試後驚訝的發現，有協作專案的經驗是非常亮眼的一個部份，這其實工作後就不難理解，大部分的工作(尤其又是應徵Junior)想必都會要與其他同事合作，公司除了希望應徵者技術達到門檻外，大部分都希望能找一個在工作協作上不會有太大問題的人。
所以通常光看到專案裡有”協作”兩個字，面試官就會非常有興趣，甚至我遇過很多沒仔細看履歷的面試官，也都會問是否有協作的經驗並請你分享。
我將協作專案放入履歷的目的是希望除了能告訴面試官我有協作經驗，更多的是希望面試官針對協作專案問我問題，因為這些問題的方向通常都是比較可以預期，而我也有很多經驗和故事可以回答(不是要回答的多浮誇或多動聽，而是我建議盡量真實，因為繼續追問時你才會與面試官行成一個很好的會話)，當然這些回答可以找人練習過，以不至於給人感覺都像是在抱怨隊友或是呈現整個作品都是自己的功勞的模樣。
以我來說，因為參加 ALPHA Camp 而有經歷到協作專案(對細節有興趣的人可以看我前言提到的那篇)，雖然當時其中一個隊友因為工作的關係，幾乎無法參與專案進行，導致最後成品可能跟預期中的完美有些落差。但事後來看，也是因為這樣的經驗反而更貼近實際工作上的狀況(人手不足、工作量大等等的狀況)，更能引起面試官好奇並往下追問。
而最常被問到的問題大部份都不是專案的產品內容，而是著重在合作上面，例如如何進行分工、你負責/貢獻的部分為何、協作方式為何(例如運用GitHub、Slack等等)、專案如何管理、如何進行溝通、是否有遇到合作上的困難和如何解決困難等等問題(所以沒遇到合作上的困難反而不一定是好事，因為沒東西可以回答 )，這些是沒經歷過真的唬爛不出來的東西(起碼我不行 )。
所以若在找工作時有時間，建議自學的讀者可以試著找看看朋友，或是勇敢到網路社群找人組隊等等方法一起協作個專案體驗看看
不管合作的過程中順利與否，只要你能好好處理每次的溝通和合作而不是放棄或擺爛，都是一個可以讓你在面試中轉換成很棒故事的經驗並且可以很好的展現自己。
後記
目前正式開始工作已經一個半月左右，很感謝當時的自己有努力過和一路上大家的幫助才能進入自己想進的新創公司，到目前對於自己工作的心得是很慶幸自己有決定轉職，不論是工作型態、新創公司的工程師氛圍、學習環境等等都有照著自己腦海中的樣子進行。
成為軟體工程師的條件：每日工作內容、重要技能、面試如何準備
工作後的小小小心得
我覺得我們公司有個文化滿酷的，每個月都會有個與leader 1on1的小會談，過程很輕鬆，不像是主管和員工，更像是前輩的分享，可以把握機會問任何想問的問題(當然平時也可以問啦)，包含公司對你的期望/規劃、工作或職涯上遇到的問題和薪水/職位的調整等等，都滿真實的。
對於公司的角度當然是希望你能往好的方向發展(不要拖很久才發現雙方的預期越差越遠)，而對剛新進的我來說，最關心的當然是自己是否和公司當初錄取的預期一致(也順便得到了當初會錄取的原因，真的很有趣 )。
而相較於工作前和工作後，感受到和自己在做專案上最大的差別在於寫code時，需要考慮到維護性和易讀性(雖然我在工作前覺得能做出功能最重要，其他都是一塊小蛋糕，但我才發現好像不是這麼一回事 )，另外就是需要與QA、後端和UI/UX設計師等等其他專業合作，必須要一直溝通以確保產出是有效的，不然我覺得若是悶著頭照著自己以為的方式做，會很容易要重做。
會看到這裡想必你也是在考慮轉職或是正在轉職的路上(或是我的朋友?)，之後過一段時間，等有比較多工作上的心得再獨立一篇分享給大家，預祝各位讀者轉職&面試順利囉
