應徵 Rails 工作的心得

這篇是我之前應徵工作的心得，以及我未來還會採用的應徵技巧，還有一些工作上的心得。

我的經驗並不適用所有狀況，看的時請考量自己與所在產業、企業的狀況，不要照單全收。

我在得到第一份正職工作後不久寫了新鮮人找工作的注意事項 & 自己的面試經驗，這篇算是續集，希望對 Rails 工程師新鮮人有所幫助。

關於履歷、面試

這部份基本上是通用的，不限定 Rails 或軟體工程師。

不要寫太多與工作無關的家庭背景

台灣人很喜歡寫「我從小生長在溫馨的家庭…，有三個兄弟姊妹…」之類的自傳開頭，這麼寫通常都沒有好處，反而讓人覺得「除了這些對工作無關痛癢的事情外，你沒什麼好說的嗎？」。是的，家庭很重要，但是在商言商，企業給薪資與福利，想買的是你的勞動，又不是你家人。除非交代家庭背景能透漏你在工作上帶來的好處，例如從小在家裡開的店幫忙，或有很多政商人脈之類的。

就我所知日本跟美國求職都沒有這種習慣，雖然這裡是台灣，但我覺得沒有必要繼續這種慣例。例如我應徵第二份工作、也就是我目前任職的 T客邦時，就根本不附上自傳。但不少公司還是會要求（T客邦也是），因此仍要先準備。

但真的要寫自傳時，我也會把自我介紹放在最後一段。因為大家都有的是工作可忙，而且也很可能讀幾分鐘就失去注意力，因此應該把重要的排在上面，例如工作經驗、重大成果等。但面談時的自我介紹則應該從名字開始，畢竟有些面試官可能沒有認真看履歷表，要是搞半天還不知道你叫什麼名字就好笑了。

履歷自傳這部份很推薦閱讀以下文章:

2014-11-12 補言：附檔履歷請不要只放一個 .doc 或 .docx，最至少也要轉出一份 .pdf，因為對方公司的主要作業系統可能是 Linux 或 Mac，如果對方開你的履歷表還要找適合的軟體或閱讀破版的文件，就算沒有立刻刷掉也會在心裡扣分。

不要說「我什麼都不會，但我肯學習」

這樣的話是不是應該繳學費才對呀？

以前有聽過用「我什麼都不會，但我肯學習」來取得機會、並有不錯結果的軼事。但我覺得不能期待用這招，除了大環境、競爭激烈等現況，更重要的是：

如果你真有心學習，怎麼可能什麼都不會？為什麼不先自學？

Rails 工程師的話，可以先透過 Code School, Rails 實戰聖經, Rails Guides, Rails 101, TeaLeaf Academy 等資源在下班時間自學。就算真的不想花錢，上述列表中也有幾個是免費的。

想要什麼工作就靠自己的雙手去爭取一文也有提到該作者是如何從設計轉職成企劃的歷程，簡單來說 ── 沒人教你，但你可以自己想辦法學。

之前在某本書裡也看到一個現象，那位作者常在演講時問聽眾「想學好英文的人請舉手」，接著問「今天回家有打算讀英文的？」、「昨天有讀過英文的？」等，就會發現大多人的「很想」都只是想想而已。

如果你已經自學到一定程度，就可以說「我的程度目前到…如此這般，而且我肯學習」，馬上打趴一堆「我什麼都不會，但我肯學習」的人。

關於應徵 Rails 的工作

公司通常要有經驗的 Rails developer

問題是，經驗只能透過實作取得，結果就變成「沒有經驗就得不到工作，沒有工作就得不到經驗」。

有些公司吝於栽培新人等問題在此不討論，但想突破現狀，自己提昇功力就行了。

雖然我剛好還騎驢找馬（前一家公司雲端線上當時願意接收 Rails 半生不熟的新手）。但這幾年線上課程與教學越來越多，如果經濟狀況、時間允許的話，可以上課並做一些自發專案。 動手實作得到的經驗會比光是聽課來得深刻 。

附帶一提，T客邦一直都有出錢買線上課程給員工學，還蠻不錯的。但依照每個時期的狀況（忙碌度、現職員工的程度等），不是隨時都能接收新手。

所以我覺得運氣也是很重要因素之一，因為有時候需要急徵時就願意接收半熟的，但有時候編制已經全滿就不會收。但無論如何加強能力跟建立名聲是基本第一關。

準備可提供 source code 的私人 project

在學校的時候，常常聽到一些學歷、證照很重要之類的說法，然而 我一直覺得程式方面的工作，真正重要的不是學歷也不是證照，而是實現成果的能力 。高職的時候我們學校有要求考「軟體設計丙級證照」，實在讓我大開眼界，也對勞委會證照制度完全灰心 ── 居然有人靠著背題庫程式碼通過檢定，而且還不少！（上機考的題目是固定的，只是看抽到哪一題而已）

有些人還是堅持學歷、證照很重要，因為很多公司會看。我相信有這樣的公司，但對我來說，看人時注重學歷證照甚於實現能力的公司，要我進去我反而很擔心啊。

如何證明你有實現成果的能力？大規模的公司可能會有上機考，但不能期待中小企業都這麼做。所以就要從另一方面出擊：準備自己的作品集。

最理想的是不但在線上營運、有真實的使用者、而且可以看 code，方便讓公司了解你的程度。

關於工作

把自己丟到好環境

這點我在之前的演講 Better and Better 也有提到。

每個人在不同階段有自己的考量，但往好的環境靠，通常都能幫你一把。反之，如果身在不利於你的目標的環境，那就會事倍功半。

舉例來說，我換到 T客邦以後，學習成長的速度遠遠超過以前自學、也超越我前一份工作在職時。實際上這也是我想換工作的原因之一：前公司的重心轉往手機 APP，然而現階段我想摸熟 Rails，因此想要找適合我的目標的環境。

如果你也想找有助於熟悉某一門程式技術的工作，這幾點很有幫助：

規模夠大、有一點責任壓力
有良好的 infrastructure 跟 code （可以一邊維護一邊參考）
有前輩帶

T客邦長期徵才中

最後就是要幫公司打廣告了，T客邦有在應徵 Rails 程式設計師。

以員工的角度來說，我認為這份工作最大的優點是：

有前人留下來的良好基礎

前面說過，我認為有良好的 infrastructure 跟 code 很有幫助，除了可以讓你免於一接手就常常救火，也可以藉此了解一些原本能力未及的東西。
這裡的管理方式偏向「僕人式管理」

讓工程師可以在無雜事煩惱的狀況下發揮。但相對的，跟僕人式管理搭配最有效果的是「Client 型員工」：自動自發學習、擁有解決問題的能力、很自主、有想法（可以為了好的結果而反對上頭意見），希望 PM 排除雜事問題，好讓他們專注在工作上的員工。

註：我不知道台灣習慣用什麼稱呼這種員工，「Client 型」應該是日本的講法。在奮鬥吧 SE 4 看到的…

因此管理還蠻開明的，只要上下班有準時打卡、工作有做完，其他事情不太會管。

例如想實行現在最夯的「站著工作」？沒問題

上班聽耳機、看 Facebook、看 YouTube 等也沒都問題（這些行為本身沒問題，但不能影響進度）。
上班打卡制，下班還是打卡制

對過去是完全彈性上班的人來說（我就是…）可能覺得要打卡很討厭，但我認為這已經算不錯的，至少不是「上班打卡制、下班責任制」。而且專案時程都抓得算合理，我到現在還沒有因為趕進度被迫晚上加班之類的，真的需要加班的話也可以補休。

來吧來吧～