這樣的狀況體現出學校教科書的教育，跟職場中實用的技能與規則，的確有不少落差，換句話說，學校的教授自己也只是一直在學術界打滾，怎麼能期待能從教授那邊學到什麼實用的技能？怎麼會知道，屏除了教科書的限制之後，在實務上，最常遇到的問題與狀況是什麼。最重要的原因就是，面試人員只會問他最常用，也認定最一定要會的東西，先反過來瞭解面試人員的生態與狀況，就能掌握一部分求職的最佳技巧。
作者明顯是把求職這件事作到某個極致，除了出一本書持續改版之外，還開立了一個專門收集與討論所有求職相關問題的網站CareerCup，包含了面試會遇到的問題、薪水、履歷表。但最受大家關注的，還是指標科技公司 Apple、Amazon、Facebook、Google、MicroSoft、Yahoo 的面試內容。
從這本書的內容可得知，在求職的過程中，最在意的是首要是履歷，再來是要準備回答行為式問題，然後是技術問題，最後則是工作條件的評估與協商。
對我們公司來說，面試的時候會分先區分為兩種求職者，第一是有經驗的轉職人員，第二種是沒有經驗的畢業生，在履歷中很快就可以得知這方面的資訊，接下來，就是行為式問題的部份，有經驗的轉職人員可快速根據他履歷中披露的專案經驗，來設定一些問題的內容，沒有經驗的畢業生就比較麻煩，因為沒有經驗，如果再加上在學校中沒有做過什麼專題研究，就很難形成一些行為式的問題。
接下來，通常我們就會詢問求職者，興趣、社團活動等等活動的內容，藉此取代專案的項目進行行為式問題的問答，在問答的過程，我們通常會觀察求職者的個性與習慣動作，藉此判斷究竟他適不適合進入這個團隊中。最重要的一點，就是要問自己，願不願意跟這位求職者一起工作，這部份在問答的過程中，就能很明顯地感受到，彼此之間的溝通與互動有沒有障礙。但或許是目前公司還不大，其實能夠容忍的成員個性與範圍就比較狹窄，如果公司大一些，相信這個部份的考量，接受度會高一些。
行為式問題的內容，通常是根據不同的專案，再搭配以下這些最常會被問到的問題項目：
- 最大的挑戰
- 獲得什麼、學習到什麼
- 最有趣的部份
- 最困難的程式錯誤
- 最享受的部份
- 與團隊成員間的衝突
- 你的缺點是什麼，如何克服它
書本提到了 Situation Action Result（SAR）環境、行動、結果 法則，來判斷求職者的表現，求職者必須在回答問題時，能夠很明確地，思慮與邏輯清晰的狀態下，把自己的答案與意見表達出來。
這些行為式問題，對我們來說，影響的範圍佔了一大部分，甚至比求職者的技能高低還重要。不過。
轉換角色，假設我現在是求職者的身份，當面試者要評斷我的職能等級時，當然得準備基本必備的 programmer 常識問題，關於架構、Pattern方面的問題，看了很多，但或許我應該要花些時間，重新的去review關於資料結構、概念與演算法的東西，即使是 Java 某些時候，也該盡可能地去節省資源，不過還得先判斷 OO 設計跟資源節省之間的得失，在書本裡提到四類技術方面的面試考題：
資料結構、概念與演算法、知識型、其他
資料結構方面，必備常識列表為
- Linked List
- Binary Tree
- Tries
- Stack
- Queue
- Vector/ArrayList
- Hash Table
演算法方面，必備常識列表為
- Breadth First Search
- Depth First Search
- Binary Search
- Merge Sort
- Quick Sort
- Tree Insert/Find/etc.
觀念方面，必備常識列表為
- Bit Manipulation
- Singleton Desgin Pattern
- Factory Design Pattern
- Memory [Stack vs. Heap]
- Recursion
- Big-O Time
對應到實際上的工作內容，我們實務上會遇到很多邏輯上的先後與條件判斷的問題，但是卻比較少遇到特別的演算法問題，資料結構的部份就常常遇到，因為總是得思考，在該功能開發的過程中，應該怎麼在記憶體中存放足以描述問題的資料，得選擇並決定要使用什麼樣的資料結構，這時候，就會需要有 Collections Framework 的知識，在 Server Side 的程式設計考量中，還得加上要判斷會不會有多個 Thread 來存取這個資料，當遇到 multi-thread 的狀況時，判斷什麼時候要同步處理就很重要了。
Design Pattern 跟 Refacting 我們視為是 Software Design 的基本常識，我不需要也沒辦法記得所有 Pattern 的名字跟 Refacting 的方法，但是必要時，我會查到應該使用什麼 Pattern，在什麼時機，應該適時地進行 Refacting。
沒有留言:
張貼留言