2013/8/20

來自程式的試煉 Cracking The Coding Interview by Gayle Laakmann McDowell

作者以她自身第一手與數百位求職者的面試經驗,加上由求職者與面試人員提供的數千個問題,整理出一套 Programmer 的求職攻略本,正如作者在前言中一開始就提到的,即使擁有一份完整的履歷,完整第複習了CLRS,如果不熟悉現場面試時可能會發生的狀況,也會在面試中敗北。

這樣的狀況體現出學校教科書的教育,跟職場中實用的技能與規則,的確有不少落差,換句話說,學校的教授自己也只是一直在學術界打滾,怎麼能期待能從教授那邊學到什麼實用的技能?怎麼會知道,屏除了教科書的限制之後,在實務上,最常遇到的問題與狀況是什麼。最重要的原因就是,面試人員只會問他最常用,也認定最一定要會的東西,先反過來瞭解面試人員的生態與狀況,就能掌握一部分求職的最佳技巧。

作者明顯是把求職這件事作到某個極致,除了出一本書持續改版之外,還開立了一個專門收集與討論所有求職相關問題的網站CareerCup,包含了面試會遇到的問題、薪水、履歷表。但最受大家關注的,還是指標科技公司 Apple、Amazon、Facebook、Google、MicroSoft、Yahoo 的面試內容。

從這本書的內容可得知,在求職的過程中,最在意的是首要是履歷,再來是要準備回答行為式問題,然後是技術問題,最後則是工作條件的評估與協商。

對我們公司來說,面試的時候會分先區分為兩種求職者,第一是有經驗的轉職人員,第二種是沒有經驗的畢業生,在履歷中很快就可以得知這方面的資訊,接下來,就是行為式問題的部份,有經驗的轉職人員可快速根據他履歷中披露的專案經驗,來設定一些問題的內容,沒有經驗的畢業生就比較麻煩,因為沒有經驗,如果再加上在學校中沒有做過什麼專題研究,就很難形成一些行為式的問題。

接下來,通常我們就會詢問求職者,興趣、社團活動等等活動的內容,藉此取代專案的項目進行行為式問題的問答,在問答的過程,我們通常會觀察求職者的個性與習慣動作,藉此判斷究竟他適不適合進入這個團隊中。最重要的一點,就是要問自己,願不願意跟這位求職者一起工作,這部份在問答的過程中,就能很明顯地感受到,彼此之間的溝通與互動有沒有障礙。但或許是目前公司還不大,其實能夠容忍的成員個性與範圍就比較狹窄,如果公司大一些,相信這個部份的考量,接受度會高一些。

行為式問題的內容,通常是根據不同的專案,再搭配以下這些最常會被問到的問題項目:
  1. 最大的挑戰
  2. 獲得什麼、學習到什麼
  3. 最有趣的部份
  4. 最困難的程式錯誤
  5. 最享受的部份
  6. 與團隊成員間的衝突
  7. 你的缺點是什麼,如何克服它

書本提到了 Situation Action Result(SAR)環境、行動、結果 法則,來判斷求職者的表現,求職者必須在回答問題時,能夠很明確地,思慮與邏輯清晰的狀態下,把自己的答案與意見表達出來。

這些行為式問題,對我們來說,影響的範圍佔了一大部分,甚至比求職者的技能高低還重要。不過。

轉換角色,假設我現在是求職者的身份,當面試者要評斷我的職能等級時,當然得準備基本必備的 programmer 常識問題,關於架構、Pattern方面的問題,看了很多,但或許我應該要花些時間,重新的去review關於資料結構、概念與演算法的東西,即使是 Java 某些時候,也該盡可能地去節省資源,不過還得先判斷 OO 設計跟資源節省之間的得失,在書本裡提到四類技術方面的面試考題:
資料結構、概念與演算法、知識型、其他

資料結構方面,必備常識列表為
  1. Linked List
  2. Binary Tree
  3. Tries
  4. Stack
  5. Queue
  6. Vector/ArrayList
  7. Hash Table

演算法方面,必備常識列表為
  1. Breadth First Search
  2. Depth First Search
  3. Binary Search
  4. Merge Sort
  5. Quick Sort
  6. Tree Insert/Find/etc.

觀念方面,必備常識列表為
  1. Bit Manipulation
  2. Singleton Desgin Pattern
  3. Factory Design Pattern
  4. Memory [Stack vs. Heap]
  5. Recursion
  6. Big-O Time


對應到實際上的工作內容,我們實務上會遇到很多邏輯上的先後與條件判斷的問題,但是卻比較少遇到特別的演算法問題,資料結構的部份就常常遇到,因為總是得思考,在該功能開發的過程中,應該怎麼在記憶體中存放足以描述問題的資料,得選擇並決定要使用什麼樣的資料結構,這時候,就會需要有 Collections Framework 的知識,在 Server Side 的程式設計考量中,還得加上要判斷會不會有多個 Thread 來存取這個資料,當遇到 multi-thread 的狀況時,判斷什麼時候要同步處理就很重要了。

Design Pattern 跟 Refacting 我們視為是 Software Design 的基本常識,我不需要也沒辦法記得所有 Pattern 的名字跟 Refacting 的方法,但是必要時,我會查到應該使用什麼 Pattern,在什麼時機,應該適時地進行 Refacting。

沒有留言:

張貼留言