---

面試一個程式設計師時，要注意的面向很多
像是學習能力、溝通協調能力、實作能力…等等

在下是一名阿宅工程師，有時會需要一起面試未來的同事

與大家分享一下我在面試時會注意的事

# Coding能力

個人認為測驗Coding能力最有效的方式是「紙筆測試」
也就是不靠電腦/編譯器/除錯器的狀況下，請對方當面完成一段精簡的程式

有人覺得這樣考太難，面試考紙筆寫程式太殘酷
我聽聞不少公司會這樣考(ex. Facebook, Google, 國內一些軔體公司)
約耳趣談軟體中，也有一篇談論到這樣的測驗方式 http://goo.gl/YSCGy
我的標準也比約耳等人要寬鬆許多

拿約耳書上用C語言來考字串反轉的例子說明好了
我會在白板上寫下 void reverse(char * s)，然後提問：

(1). 請實作將字串原地反轉的函式，不得呼叫其他函式
(2). 承上，不得進行動態記憶體配置
(3). 承上，不得使用數值(numeric)型別及運算

並且告訴對方：
不用緊張，沒有一次寫對沒關係，許多人都無法一次寫對。
但希望你能認真思考、除錯。

我會先從(1)問起，如果對方寫對，就再加上(2)和(3)的限制
如果是C語言高手，你給他(1)的限制，他通常會精簡的直接寫出(3)的答案

如果有錯誤，我會告訴面試者會出現什麼樣的錯誤
(Ex. Segmentation fault, compile error)
再詢問對方遇到這種狀況會如何除錯

P.S.提問者至少需要能夠人腦compile&emulate這些程式
    我可以在C/C++/Java/Ruby/Python上做到
    當然…不一定是考同樣的題目

我認為這樣的測驗可以看出許多東西（視題目的性質而定）：
邏輯、思考方式、演算法、抗壓性、對寫程式的熟悉程度
我相信在面試的手法中，這樣做最能直接看出寫程式的實力

# 語言的概念

每個語言都是由若干概念組成的，先從一個例子開始說明吧：


  包括object oriented, garbage collection, class, interface, …


  當他再學習C#時，他會發現他只需要學習Java一半的時間，就能熟習C#的基本概念
  在看到某些設計時，他會想到：「喔喔，C#也有類似的設計」

  有一天他突然對腳本語言有興趣，所以他學習了Python，然後又遇到了撞牆期
  他同時接觸了以indent為block的語法
  還要學習dymanic typed, duck typing其實相關的設計方法

  當這個人再去學習Ruby時，他會發現他只需要學習Python一半的時間就學會基本
  當他再學習Lua時，他發現他只需要半天就可以看完語法，可以寫些簡單的小程式了

  數年後，他又因為興趣開始學習Erlang
  第一次接觸到Single-assignment, Functional Programming
  要入門又有好長的一段路要走


可能是對方不夠熟悉，或是不懂特定的專有名詞
這時可以再問一些問題，去試探對方對這些概念的了解程度

前面有版友提到：「我怎麼很少聽到有人自稱會很多程式語言的」
我相信在熟悉各種概念的前提下，要會很多種程式語言並非真的這麼稀奇

但就像Google在某些地區的徵才說明：
请确保你简历中的所有内容都是可被核实的。例如，如果你的主要编程语言是Java或者
Haskell，那么面试过程中就可能被问及此类话题。 ( http://goo.gl/ifeko )

如果有人說自己會C++
但發現他不懂template，甚至講不清楚物件導向的基本概念
列出C++不但不會加分，還會倒扣一些分數

很多時候，對方對程式設計的了解深淺，只要聊幾句就可以摸清楚
有時還是會碰到不確定對方實力的狀況，這時就看對方在紙筆測驗的表現當參考了

我不會因為對方在履歷上列出很多程式語言而扣分
但會希望列在履歷上的技能都是真材實料的，並會努力（笑）核實這些技能

# 語言的細節

我將初學時比較不會碰到，而在實戰、或看書深入研究才會了解的知識分為此類

舉例來說，像前面版友提到的：
* variable shadowing http://goo.gl/uy9In
* object slicing http://goo.gl/Gk6Ud



就我而言，對junior engineer來說這些是bonus，而不是requirement

只要基本概念、邏輯好，這些應該都很容易pick up

對於senior enginner而言
若團隊需要的是精通特定語言、技術的人，這點就很重要
換句話說，若是看重其他經驗/學習的potential
而需要能夠快速上手pick up各種技術的員工，這點就可以比較不看重

但若對方自稱擁有四年C++業界經驗
卻沒碰過、也沒聽過object slicing, variable shadowing
我也會對他的實力產生很大的疑惑

# 函式庫的使用

寫程式的人應該都聽過這句話：「不要總是重新發明輪子，要站在巨人的肩膀上。」
固然，為了練功去重刻底層函式庫是值得鼓勵的
但身為程式設計師，學習迅速利用、整合現有的工具，也是重要的課題

若團隊需要專精某Library/Framework的人材
面試者如果原本就精通那些函式庫，會有很大的加分作用

這點與「語言的概念」相似，每個函式庫都可以拆解成一些核心概念


比方說，Spring核心最重要的概念，或許是Inverse of Control和Dependency Injection
若對方說用過Spring，我會對方為什麼選用Spring，他有什麼重要的特性
如果他說不出專有名詞，我會試著以例子測試他是否理解這些概念

接下來，我可能會問對方覺得Spring有什麼優點與缺點
能講出一些優點，算是基本的合格條件
有時被官方文件/書籍洗腦的結果，大多數的人都可以掰出一些優點
但如果優點/缺點都能侃侃而談言之有理，就代表他真的懂了

我同意約耳說的：「不會因爲應試者不掌握一種特定的技巧而拒絕他」
這裡我看重的有兩點：

1. 如果真正了解函式庫的概念，學習其他概念相似的函式庫時，很快就能上手
2. 如果對方本身碰的東西夠多，又在許多領域都能提出良好見解
我會相信對方對於學習新概念，也比較具有熱情跟效率的

此外，使用函式庫的時候，難免遇到種種問題
這些問題會來自於自身邏輯的錯誤、對函式庫的誤解、甚至函式庫本身的bug
這部份可以請對方談談之前的開發遇到的問題，以及解決問題的流程
試著了解對方是否擁有獨立解決問題的能力

----

不同的人，不同的團隊風格，在面試時會在意不同的事
以上是我的觀點，分享給大家參考

後記：
其實這篇文章十幾天前就開始動筆寫了
不過越寫越長，加上最近太忙，所以到今天才寫完

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.204.175.125
※ 編輯: yzugsr          來自: 101.12.211.142       (04/16 21:42)

--