538
史上最難的麵試謎題
史上最難的麵試謎題
你曾經在應聘一份編程工作的麵試中被問及一些解謎類的問題嗎？反正我碰到過。我被問到的那個問題是：
你最喜歡的那個牌子的蘇打，有多少是在這個州被消費的？
拜托，正確的答案不能是"關我什麼事"，除非你不想得到這份工作了。我當時對這個問題毫無頭緒，後來才知道這是一個"費米 問題"（Fermi Question）。
謎題作為一種新生事物，在20世紀90年代的程序員麵試裏風靡一時。這在《如何移動富士山？》（《How Would You Move Mount Fuji？》）一書中有很好的記載，書中還強調微軟公司在招聘過程中就使用了謎題。
如果你已經知道你將去應聘的公司會問這類謎題，預先研究一下常見的麵試謎題是很明智的。如果你覺得你已經對一般的謎題很在行了，那我就要來考驗你一下，看看下麵這道史上最難的麵試謎題吧：
3個海盜把100名囚犯分別關在100間牢房裏，其中一名囚犯將在早上走跳板（海盜處死俘虜的一種辦法）。每名囚犯有10瓶葡萄酒，其中1瓶是有毒的；每個海盜有12枚硬幣，其中1枚是偽造的，它比真硬幣或重或輕。每個牢房裏都有一個開關，囚犯可以不碰它，也可以把它翻轉過來。在被帶入牢房之前，囚犯們都被戴上了紅帽子或者藍帽子；他們可以看到其他所有囚犯的帽子，但就是看不到自己的。同時，一個6位素數這麼多的猴子在不停繁殖，直到它們的數字翻轉過來，然後所有猴子都要借助一隻獨木舟橫穿過河，而獨木舟一次至多隻能載兩隻猴子。不過，半數的猴子總是說謊，而另外一半的猴子總是說真話。現在假設，第N名囚犯知道猴群中有一隻猴子，它不知道：第（N+1）名囚犯在知道了哪瓶酒有毒和他所戴帽子的顏色之後，海盜隻有知道了這名囚犯是否翻轉了他房間裏的開關，才能知道1～100之間兩個數的乘積。怎麼來解這個謎題？
換句話說，我討厭謎題！（但願那些謎題狂熱者都能解答出來……）在意料之中，我沒有通過那次麵試。我當時很失望，因為那份工作還是挺酷的！
倒不是說我在"與程序員麵談"一節裏給出的建議會更受歡迎，但我確實認為那要好得多！
在前麵，我給大家介紹了一種我自創的方法，那也是麵試程序員最理想的方式：讓候選人在你的團隊麵前就他們做過的某樣東西做15分鍾閑聊式的演講。你當然還可以用一些實際的需要動手的編程測試來作為補充，以確保那位候選人不是在招搖撞騙-盡管我堅信，如果你不是真的理解你正在談論的東西，你是不可能在一個技術性演講裏煳弄一群同人的。（如果你真能這麼煳弄，你現在應該已經成為一家創業公司的CEO了！）
我在這裏要強調的是溝通能力。對於大部分程序員來說，在他們通過了"Fizz-Buzz"級別的能力測試之後，他們看起來已經相當不錯了。但隻會寫代碼還不夠。如果想從優秀發展到卓越，你必須培養起有效溝通的能力：與你的同事溝通，與你的老板溝通，與用戶溝通，最終與全世界溝通。
因為我們第一個小孩的出生，我和我的妻子在一家醫院裏待了5天。在住院期間，我們得到了很多名護士的協助-每天至少兩名不同的護士，有時還會更多，因為我們要去不同的科室就診，而且護士每天還有換班。這家醫院的護理質量總體來說是相當高的，但我們也為從最差的護士那裏和最好的護士那裏分別得到的護理之間的差距倍感困惑。幾天之後，我終於發現了一個共性-最差護士的溝通能力必定是最差的！這些護士無法跟我們進行有效的溝通，比如：
為什麼她們需要做某事
可選方案有哪些
提供建議
解決我們的問題
這讓我們覺得，她們都是些死板的、隻知道照章辦事的人，她們不會照顧人，或者她們沒有主見（必須不斷地請示上級）。當然，事實不是這樣的。我相信，她們都是完全合格的專業護士。但在溝通方麵，她們看起來確實很糟糕！我還得說句公道話，這些護士常常（也不總是）不是本地人（她們的母語不是英語）。
即使在最佳的條件下，招聘也不是件容易的事！但如果讓麵試流程太過依賴於謎題就太冒險了。當然，程序員們最終可能把你扔給他們的蹩腳謎題解決了（我猜他們也許隻是記住了答案）。但是，把那些解決方案有效地解釋給團隊中的其他人聽，難道不同樣重要嗎？對於很多程序員來說，那才是謎題中最難的部分。
第5章 促使團隊緊密協作
不管怎麼說，那總是人的問題
作者在Twitter上發的一條短訊：
"不要恨程序員！恨代碼就好了。"
11:16 AM - 2012-5-18
Bruce Eckel 巧妙地指出了所有軟件開發問題的根源：
我們身處一個新興產業中。很原始，真的-我們對真正有用的東西知之甚少，而且我們總是認為我們已經找到了可以解決一切問題的"銀彈"。結果呢？這麼多年來我們一直在經曆從繁榮到蕭條的輪回：新的想法出現、進一步發展、失去控製、偃旗息鼓。不過，有些理念似乎有持久力。例如，敏捷方法論裏的很多理念看起來在生產力和質量方麵正在產生著實質性的影響。這是因為它們更多關注了在一起工作的"人"的問題，而更少關注"技術"的問題。
我從Gerald Weinberg那裏學到了很多。他最早寫的幾本書都是關於編程技術的。後來他轉變了方向，撰寫了（包括與人合寫）50多本關於軟件開發流程的書。他還有一句名言："不管他們告訴你什麼，那總是人的問題。"
項目的成敗通常都是因為流程和人員的問題-你每天的工作方式；你的架構師、你的經理以及和你一起工作的編程團隊成員；你是如何溝通的，最重要的是，當流程和人員出現問題時，你是如何解決它們的。讓你陷入困境最快的方法，就是認為技術是決定性的因素，而且你相信你能輕易解決其他方麵的問題。事實上，那些其他方麵的問題最可能讓你止步不前。
Bruce把Gerald Weinberg的原話記錯了，它應該是"不管什麼問題，那總是人的問題"。但是，Bruce的重述有一種不可言喻的真實感，當然也忠實於Gerald Weinberg原話的精神。
假設我現在有個任務，要去判斷你的軟件項目是否會失敗。我手上有3個問題，當我得到你對它們的回答時，我幾乎可以肯定地宣判你的項目結果：
1．你的團隊將會寫多少行代碼？
2．你們在開發什麼樣的軟件？
3．你喜歡你的同事嗎？
最後的那一個問題不是笑話。我是在說正經的。從個人角度出發，你是否喜歡你團隊成員的陪伴？你是否在專業上尊重你的團隊成員？假設你換工作到了另一家公司，你是否會邀請你的同事一起過去？你們是否有令人振奮的團隊討論，還是那種打倒、拖出去，直到最後一個站著的強人說了算的爭論？在你的團隊裏，是否有你想要"投票趕下島"的人（如果你可以這麼做的話）？
讓你關注跟你一起工作的"人"，而不是那些實實在在的事情（例如，實際的工作或者你工作中所用的特定技術），這聽起來可能有點本末倒置，但事實上並非如此。我發現，從你選擇的跟你一起工作的人身上能最準確地預測工作滿意度。而根據我以前的經驗，工作滿意度和成功有著密切的聯係。我還從來沒有看到過一個快樂、健康、有凝聚力、社交正常的軟件開發團隊失敗過呢！遺憾的是，這樣的團隊太少了。
就像Gerald Weinberg所說的，那總是"人"的問題。如果你不是和你喜歡的人、你尊敬的人、會挑戰和激勵你的人一起工作，那你為什麼不去找到這些人呢？是什麼在阻止你？
最後更新：2017-04-03 14:54:38