這是一篇我在Soft_Job版回應的文章。
其實我平時是不逛Soft_Jobs版的，寫這篇文章是因為女友在PTT看到這個主題，好奇我對於這件事的想法。開始動筆後不小心越寫越長，加上那陣子比較忙，結果花了十幾天才段段續續寫完。也感謝女友發揮編輯專業幫我潤稿 :)
以下保留BBS的排版風格，原文轉載於此。
作者: yzugsr (Big Cat) 看板: Soft_Job
標題: Re: [討論] 如何定義 "會" XXX 程式語言
時間: Sun Apr 1 23:43:02 2012
面試一個程式設計師時，要注意的面向很多
像是學習能力、溝通協調能力、實作能力…等等
在下是一名阿宅工程師，有時會需要一起面試未來的同事
在這些面向之中，我個人最重視實作和程式語言的部份（其他部份自然也有其他人把關）
以下就「Coding能力」、「語言的概念」、「語言的細節」、「函式庫的使用」幾項
與大家分享一下我在面試時會注意的事
# 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上做到
當然…不一定是考同樣的題目
我認為這樣的測驗可以看出許多東西（視題目的性質而定）：
邏輯、思考方式、演算法、抗壓性、對寫程式的熟悉程度
我相信在面試的手法中，這樣做最能直接看出寫程式的實力
# 語言的概念
每個語言都是由若干概念組成的，先從一個例子開始說明吧：
當一個只會C的人初學Java時，可能會碰到相當的瓶頸
因為他不只學習了新的語法，還接觸了各種新的概念
包括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
要入門又有好長的一段路要走
我認為重要的不是「會使用多少語言」，而是「對各種概念有多深的了解」
如果對方說會C++和Python，我會問他覺得兩種語言各有什麼特性、優缺點
很多時候對方會講不出來，或許不是面試者完全不了解
可能是對方不夠熟悉，或是不懂特定的專有名詞
這時可以再問一些問題，去試探對方對這些概念的了解程度
前面有版友提到：「我怎麼很少聽到有人自稱會很多程式語言的」
我相信在熟悉各種概念的前提下，要會很多種程式語言並非真的這麼稀奇
但就像Google在某些地區的徵才說明：
请确保你简历中的所有内容都是可被核实的。例如，如果你的主要编程语言是Java或者
Haskell，那么面试过程中就可能被问及此类话题。
如果有人說自己會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)