程式設計師面試的標準答案並不標準
程式設計師面試的標準答案並不標準
Peter Verhas在技術面試時問了一個看似無關的問題，並得到了一個雖然沒錯但並不恰當的答案。隨後，他宣稱，“有時候，我會碰到那些不但不知道答案，還自作聰明地給出錯誤答案的候選人。知道錯誤答案比不知道更糟糕。一些極少數的甚至堅持和試圖向我解釋我應該如何理解他們的答案。這已經成為了一種個性問題，而且毫無疑問是面試中要pass掉的人。”我要宣告的是，Peter不僅是錯了，而且這樣的面試條件完全損害了他所就職的公司的利益，我個人絕對不會工作於有這樣一種態度的公司。
你可以先去閱讀他的原始文章。事實上，用不了多長時間。
好了，既然你已經瞭解了材料，那麼下面讓我們徹底地探討一下吧。
問錯誤的問題
對於初學者來說，在我看來，整個過程從開始就錯了：
有很多關於Java技術面試的問題，即使是最入門級的新手也能給出正確的答案。當我面對不那麼初級的候選人時，我不會問這些問題來浪費時間。我假定候選人知道正確答案。但是，有時也有一些一開始我就認為是新手的候選人，我會削減面試以避免浪費他/她和我的時間，因此，我會問一些簡單的問題。這些問題的答案通常能揭示知識的真正水平，於是我們就可以在較短的時間內評估其水平。
但是，夥計們，有一點要清楚的是：如果你是技術面試的面試官，那麼你必須要求他們寫程式碼，而不是回答問題。除非他們申請的職位就是用來解答程式設計問題的（在這種情況下，你面試的是老師，而不是實際的程式設計師），否則你就得要求他們展示他們的技術能力，而不是他們的口頭知識。
這樣做的原因應該是理所當然的，但如果你還不明白的話，我會從邏輯，例子，和類比這三個方面加以論證。
邏輯：你面試的程式設計師不是每一個都受過傳統訓練。他們可能不知道全部的偏好術語。是“getters and setters”還是“automatically-defined properties”亦或是“accessors and mutators”呢？這在某種程度上取決於你是在什麼語言下成長的（例如，如果是C ++的話，在相當長的一段時間內更喜歡用後者）。這取決於你閱讀的是什麼書。這取決於你有沒有和其他人討論過這些——也許是從一本書上學來的，並且是在網路上閱讀相關內容。（StackOverflow最近的民意調查顯示，求職者中約三分之一或更多的開發人員自認為“自學成才”。）因為他們沒有用對詞，你就要踢掉完全合格的候選人嗎？而這還不包括那些因為在面試時過度緊張而導致甚至簡單的問題也回答得亂七八糟的人。
例子：有一個為我工作了兩年的開發人員是一個相當有能力的C#開發人員。這是一個能領導小組，能指導一些比較初級開發人員，並想出一些相當得力的設計的傢伙。然後，當潛在客戶在會議中要求他講解靜態方法是什麼的時候，他完全搞砸了，他牛頭不對馬嘴地開始談論起建構函式和其他一些文不對題的東西。直到他終於意識到自己在說什麼的時候，我已經坐在那裡用一臉“見鬼了？！？”的表情看了他幾分鐘。如果按照Peter的標準，那麼毫無疑問他會面試失敗。然而，在那次會議之後，他依然為那個客戶擔任了9個月的團隊領導，對於他的技術，他的能力，以及那些靜態問題的答案（諷刺的是，從來沒有人談到這一點！）沒有人提出異議。換句話說，在沒有面試壓力時，他做的很好，他的工作也說明了這一點。
類比：比方說，如果你要僱傭樂隊來為你的婚禮演奏，那麼你真的介意他們講解音樂理論和作曲的能力嗎？或者說你更關心的是他們能不能演奏你最喜歡的舞蹈音樂，能不能演奏你的配偶選擇的歌曲，能不能讓你的祖父祖母也跑到舞池中跳起來？很多樂隊（甚至我敢說是所有樂隊！！）是因為他們的工作表現和/或樣帶才得到的演出機會，而不是他們回答問題的能力。
期待錯誤的答案
接著，Peter說，
知道錯誤答案比不知道更糟糕。一些極少數的甚至堅持和試圖向我解釋我應該如何理解他們的答案。這已經成為了一種個性問題，而且毫無疑問是面試中要pass掉的人。
呵呵，真是狂妄自大，索性你就叫“程式設計面試上帝”得了。我的意思是：
有這樣一個簡單的問題：一個類的靜態方法能不能呼叫同一個類的非靜態方法？如果你稍微懂點Java，你知道答案是：no，不能。靜態方法屬於類，而不屬於例項。你甚至可以直接使用類的名稱執行靜態方法，而不需要任何類的例項。甚至在整個JVM中沒有類的一個例項，它也可以執行。因此，哪裡能夠呼叫一個執行連線到例項的普通方法？
狂妄自大的傢伙，沒有理由認為靜態方法不能呼叫例項方法，好不好。這裡Peter的問題基於這樣一個事實，靜態方法沒有特定物件的引用（通常是“this”引用），這是給出的答案的理由：“沒有this，沒有方法呼叫”。
然而：
話又說回來，這時出來一個候選人他的回答是：yes。他甚至開始解釋這樣的情況可能發生在靜態方法訪問例項的時候。它可能會得到一個例項作為方法引數，並且通過那個引用，它可以呼叫例項方法。他說的是對的。
但是：
這樣的回答並不能改變他對Java知之不深的事實，雖然在這個非常特定的問題上，他的回答是對的。
所以，請原諒我的直言不諱：這個答案可以說是對的，但你也可以說是錯的，因為“這個候選人沒有深刻地瞭解Java”？但是反過來我也可以說，這個候選人就是因為充分地理解Java，才能找到一個雖然出乎你的意料、但實際上卻是正確的答案。
接下來會發生什麼就顯而易見了：對自己的技術自信滿滿的面試官，準備好了一系列已經規定了答案的問題來詢問候選人，如果候選人沒有按照他的答案回答，那就被認定為是“不合格”。
舉一個我親身經歷過的例子。幾年前我到一家公司去面試一個C ++的職位，當被問到“私有欄位能不能從類的外部訪問時？”，正常的回答應該是“No，private會把這個欄位封裝起來，就好像與世隔離了一樣。”
#include <iostream>
#include <string>
using namespace std;
class Person
{
public:
Person(const char* fn, const char* ln, int a)
: first_name(fn), last_name(ln), age(a)
{ }
string description() {
return first_name + " " + last_name + " is " + to_string(age) + " years old";
}
private:
string first_name;
string last_name;
int age;
};
int main() {
Person ted("Ted", "Neward", 45);
cout << ted.description() << endl;
}按照原意的話，“age”欄位是不能從其他地方訪問的，是不？
不過，我的回答是：“當然可以。你只需要將物件例項轉換成void指標（void*），然後從物件的開始位置計算偏移量，這樣就可以訪問到它了。”
int main() {
Person ted("Ted", "Neward", 45);
cout << ted.description() << endl;
void* pTed = (void*)&ted;
int offset = sizeof(string) + sizeof(string);
char* pTedAge = (static_cast<char *>(pTed) + offset);
cout << static_cast<int>(*pTedAge) << endl; // prints 45
}我甚至向他們展示瞭如何將此歸納成為一個模板（我把它叫做“THackOMatic”，並認為這是我在這門語言中的得意之作之一。）
好了，你的迴應可能是：
- 哇，想不到你能想到這一點。很有意思。我在想…
- 好吧，這樣的確可以，但它不算是一個好主意。
- 你完全沒有領會這個問題的精神。所以，你還是錯了。
如果你的迴應是前面兩個中的一種，那麼我和你在同一陣營。它是一種嘗試，無論如何這是一種嘗試，而嘗試通常是你正在做錯事情的標誌，除非是在非常狹窄的情況下，沒有其他辦法，以及除非從今往後你是唯一一個接觸那些程式碼的人。
但是，如果你是第三種迴應，那麼你可能沒有抓住要領。問題的要領就是，候選人指出了一種繞過絆腳石的方式。如果你不能認識到這一點，那麼我認為錯在於你，而不在於候選人。
你僱用的人與你面試的判定標準相關
不管是對是錯，你給出你的問題，候選人用他們的方式想問題，然後想出一個新奇的答案。但是隻關注答案的話，你就會錯過重要組成部分——他們找到的繞過它的辦法。
面試可用於發現那些滿足一定技術門檻的候選人，也可以用來找到那些有辦法繞過障礙物的求職者。Bug，生產中斷，設計缺陷，不管是什麼，你需要找尋那些不會墨守陳規的迂腐之人。
但是當候選人真的這麼做了的時候，你又把他刷了下來。
所以，其實你想要的是那種普通的，乏味的，沒有主見的答案，而他們給出的卻是一個“開箱即用的”，有創意的，令人耳目一新的答案。
你是否聲稱你只聘請“最好的”？但是要知道，如果你這樣做的話，那麼你聘請的只是那些中間的普通的程式設計師，在最理想的情況下。那些鶴立雞群的程式設計師往往是一些開箱即用的思考者，因為他們知道有時候以及在一些特定情況下，規則是用來打破的。
在這一點上，你認為他們會滿意你這樣中規中矩的面試官嗎？我想也不會。
總結
所以這裡的挑戰是：如果你是面試官，你要面試什麼呢？
順便說一句，還記得我提到過的多年前面試過的那家公司嗎？面試官的迴應非常典型：“不好意思，正確的答案應該是’不’，但是我知道你的意思。你是第一個給我這樣一個回答的人。”此後不久，他們就僱用了我。並且在我離開公司之前，我使用了不少語言技巧來幫助顯著精簡了他們的程式碼庫體積。