本文目的

寫本文的目的，大叔不是為了裝逼（雖然說話的口氣有時候也確實有點裝逼，性格導致的，咳。。。我得改），其實大叔在公司也只是小羅羅，本文的目的主要是為了向大家展示如何通過各種軟技能應對面試官，這個應對包括如何溝通，引導，展示技巧以及更多地讓面試官跟著你的思路走，讓面試官根據你的亮點挖掘你其它的優勢，而不是一味地跟著面試官的思路走（這就有點危險了），也就是如何更多地展示你強的一面而盡量避免暴露自己的弱點，尤其是Senior和Lead在面試的時候需要注意這一點，當然，這確實需要下很多功夫，那就體會一下大叔在去年的一次面試經歷吧。

起源

事情起源于一個2010年11月12號（周五）的一個電話，下午剛吃晚飯被部門領導叫進一個小會議室說有事找我談談，大概事情是歐美一個大客戶要在北京總公司建立第2個ODC（離岸研發中心）（第1個ODC已經在公司的另一個分公司建立了1年多了大約400人），這次面試很多高級開發工程師都已經面過了，但是客戶就是不給簽約ECA（個人另外和客戶單獨簽的安全協議），原因是ODC的技術帶頭人一直沒招到，公司提供了大批的架構師、Tech Lead、以及懂技術的項目經理去面試，都栽進去了，所以讓我去試試，說一會公司的高級副總M先生馬上就打電話過來。

在1萬多人的公司工作，能讓VP親自打電話，其實心里還是蠻激動的，但其實大叔是不愿意去的，因為當時手頭的項目也是很不錯的，做亞洲最大的KTV連鎖系統相關的東西（數據實時采集，商業智能分析，以及后期全新開發的WPF版的KTV點播系統），下面30多人，其實也挺不錯的，主要是有了孩子，所以想先穩定2年。可是M先生打來電話了，大意就是客戶面試比較嚴格，視頻會議以及遠程桌面現場編程，這就意味著，面試個過程中客戶不僅可以看到你的表情和心里，還要通過遠程桌面在你現場編程的時候看到你每敲的任何一個字母。很多人技術很強，但是印度式英語溝通上，或者代碼編程細節上，甚至MSDN查詢的細節上都有可能被客戶challenge住，公司已經浪費了幾個月時間，而且也浪費了大批的優秀候選人，客戶給了deadline，如果沒有滿意的人，客戶有可能就把這個ODC建立到歐洲那個公司了，所以希望我去試試。雖然我不情愿，但是在領導近于命令式的語言以及一大堆的憧憬中，大叔也沒有辦法，嘗試著說先給我一周時間準備吧，因為我已經1年多沒有進行編程了，但領導說，事情緊急，就下周一吧，給你兩天準備時間。在堅決地拒絕以后（因為周一要去國貿客戶現場講解新項目的架構，所以沒辦法），面試終于選擇在周二早上8點進行。

其實周一下午公司的人還是給予了一些面試指導，畢竟所有的人都很看重這個事情，尤其是和客戶溝通方面需要注意的事情以及稍微了解了一下客戶的脾氣（因為之前有個人很堅持自己的方案牛逼，不愿意聽從客戶的方案解釋，所以被fire）。

技術面試

北京時間早上8點（客戶時間：下午4點）：

雖然之前有過和印度人共事的1年多經驗，但是依然有點怯，連通視頻我一瞬間，大叔驚愕了，面試官居然是Martin Fowler的翻版：

（Martin Fowler頭像， 我的偶像啊！）

不過人還是挺友善的，在剛開始的5分鐘，我主要是做個人介紹，大概介紹了一下最近2年做過的項目，和承擔的職責，其實客戶對這個不太感興趣，他們感興趣的是現場面試，so, 我說了一句：我準備好了，我們可是開始了么？客戶來勁了，視頻里說了一下題目，同時Live Meeting里也把英文題目發過來了（可能是怕聽不懂吧），題目非常簡單：找出第一個句子中有而第二個句子中沒有的單詞。

我很詫異，面試不會這么簡單吧，就算我1年多沒寫過代碼了，完成這個題目也是不成問題的吧，可是回過頭來一想，我面的職位不是高級開發，也不是架構師，而是技術管理，于是我明白了。。。

客戶：這時候客戶直接問我要estimate估時了
大叔：這個時候我并沒有告訴客戶說，我需要時間先分析一下，問完問題才能給你時間，而是直接告訴他，我還沒用細想，但是我覺得大概的樂觀（optimistic）估時應該是1小時（其中包括，5分鐘的思考，5分鐘的問題確認，5分鐘的設計，25分鐘的編碼，10分鐘的code review以及10分鐘的測試和bug fix），但悲觀估時可能是1小時20分鐘左右，因為沖突可能會出現無法預知的問題需要客戶或者相關人的幫助。

客戶表示Good。那就開始吧，滴答，滴答，滴答。。。。

在考慮了一系列的常見的和特殊的場景以后，我問了很多問題，但總時不超過5分鐘，大概如下（記不太清楚了，就寫這么多）

1. 非英文下如何處理
2. 數字等算不算單詞
3. 輸入輸出形式如何

然后又誠懇地問了一下，英文下除了逗號，句號，空格，問號，斜杠，感嘆號以外，還有其它的語言符號么？（因為要用這些分割單詞哦），客戶比較開心這個問題，又告訴了我幾個：反斜杠，引號，又特別提示了一下我，中劃線不算分隔符。 中途也遇到了一點尷尬，就是對這些符號的英文單詞，記得不是很清楚，所以老搞錯，最后客戶還是直接在live meeting上敲出才確認的，感謝IM。

北京時間早上8:15（客戶時間：下午4:15）

編碼正式開始了，其實中途的編碼過程到時沒什么問題，因為題目確實比較簡單，但是代碼總不能都在控制臺的Program.cs吧，也不能只寫一個簡單的靜態方法吧？題目雖然簡單，不能體現什么架構，但是要展示點東西吧，于是一個有點搞笑的類文件InterviewEngine.cs出來了，但這時候，我并沒用急于寫代碼，而是把我的代碼處理邏輯的想法用英文寫在這個類的summary里了，寫了大概5分鐘左右（這就姑且算我的設計吧），然后代碼上，寫了一個單例（有點不倫不類，后面會解釋）（靜態字段+靜態構造函數的方式），當然在正式處理方法里也仔細考慮了很久，比如2個參數的空值判斷，異常判斷，以及分隔符的定義易修改等做了處理，當然中途我故意把字符的大小寫沒用區分（因為我想在后面的code review階段來體現），當然該有的注釋啥的也都有。

北京時間早上8:45（客戶時間：下午4:45）

代碼結束，為了表明自己真的做了code review，自己還是硬著頭皮把鍵盤提示符一行一行地走了一遍，以便讓客戶在編輯器里看到我真的是在做這件事，因為code review是項目里非常重要的一步，也為了證明我做了，我在這時候才把上面故意沒用區分大小寫的問題加上了。

由于不是按照TDD的方式來做的，所以單元測試是在基本的code review以后才開始做的，由于之前和客戶確認了，不用使用MBUnit/NUnit之類的單元測試工具，所以只是手工寫了一些case，做的case不僅包括了正常的，也包括了不正常的了，當然邊界測試，空值測試，異常捕獲等也都覆蓋到了。（后面項目開始的時候，客戶由于知道我熟悉MBUnit，所以在項目上讓我們用了這個，而沒有用其它人都推崇的NUnit）。

北京時間早上9:00（客戶時間：下午5:00）

時間比我預想的提前了5分鐘，暗自慶幸中，于是告訴客戶，我已經寫完了，當然也客氣的說了一句：“你能幫我check一下，有沒有其它的我沒用想到的錯誤么？”。
"Okay, Tom...."，客戶舒了一口氣說，你再檢查一下獲取單詞集合的時候有沒有什么遺漏？我實在想不起來遺漏了哪個判斷，參數判斷，單詞萃取，單詞存儲，查詢性能等都考慮到，只有虛心而真誠地請教了客戶：“I cann't find any problem now, could you give me some comments?”

客戶這時候在IM上敲了一句話：Hello, tom, how        are you？

OK, God，我明白了，原來是分隔符連續的問題，這時候分割出來的單詞是空，所以這時候不需要在去判斷集合里是否包含這個單詞了，因為空根本就不需要添加到集合里。我對客戶的提示表示感謝：“Oh, good catch, thanks R****.”，然后很快給予了修復，并且添加了相應的測試用例。

北京時間早上9:25（客戶時間：下午5:25）

客戶對題目表示滿意，本意為面試就要結束了，但是客戶這時候又給了一個需求變更，讓我在現有控制臺程序的基礎上做一個方便測試代碼，經過互相討論，最終的理解是：做一個控制臺的輸入功能，讓用戶分別輸入2段字符串，然后給出結果，在這一步，我差一點栽了，因為對Console.Read，Console.ReadLine以及Console.ReadKey的用法實在想不起來了，再試了很多次之后，才搞定的了，以至于客戶問了我一句：你是不是這些知識已經忘記了，我只得遺憾地回答：“是的，長時間不寫類似的程序，很多基本的東西都忘記了，看來需要經常來回顧一下用法。” 沒想到，客戶說了一句：“對，我也是經常忘！”

哈哈，看來沒丟臉。

北京時間早上10:00（客戶時間：下午6:00）

客戶又問了一下，我平時編碼的時候是如何保證質量的？我會意的笑了一下，我說我有T氏法則，也就是我整理的Guideline，所有Team的人都要遵守，Guideline里囊括了開發過程中要預防的各種各樣的問題，比如輸入輸出驗證，編碼，性能，加密解密，信息安全，客戶端安全，多條件，多線程，異常處理，資源釋放，代碼覆蓋率，單元測試等等，還順便問了一句，你要看么？因為我現在用的是自己的機器，可以發給你一份。

客戶表示想看，看了我發的英文版以后，客戶表示：你在我們這里干的話，我想你的很多條規則都是可以用上的。

之后客戶又突然回來，問我為什么面試的時候要用單例，我很誠實地回答，因為面試時間有限，所以我要想辦法體現我的各種各樣的能力，然后我們倆又針對單例討論了很久鐘，期間我講我了解的單例模式，然后所有的實現都在VS2010里用代碼展示給他了,最后，我連把單例的泛型版本都展示給他看了，他表示贊許，因為我在視頻里看到他點頭了。

面試持續了2個多小時了，因為很自信自己在設計模式方面的理解，所以為了搶占主動權，所以我豁出去地說了一句：你還想問我其它的設計模式么？

R先生：不用了，看你對單例研究這么深入，我覺得也沒有必要再問其它的設計模式了，因為我相信你肯定也很熟悉了，而且你的職位又不是開發人員，而是要Manage他們，好了，你能再把你之前的工作經歷詳細地和我說一遍么？

有戲了，客戶居然再次讓我介紹之前的項目了，于是把自己之前的幾個項目介紹了一下，由于之前的項目都不小（第一個項目，26人做了2.5年，第二個，16人做了1年，第三個34人做了半年），客戶了解了我的職責以后，什么都沒有說，只是說了一句，我們的項目和第一個差不多，你應該能夠cover住的，技術面試這里就先結束了，1小時以后我們繼續來聊非技術的吧，因為我要先回家吃飯（因為這時候已經是客戶時間晚上7點了）。

什么？！！這才是上半場？下午我還要和我Team的人開會布置任務呢！！不過還是禮貌性地說了一句，感謝你的面試，我的準時上線的。

技術面試總結

在這里，其實我自己感覺，技術面試這一關其實應該是八九不離十了，因為從和客戶溝通的效果來看，基本上都是贊許，下半場還沒開始，所以我在這里先總結一下我的面試體會：

技術上：

1. 要有非常明確、規范、令人信服的整體結構。所以對代碼分塊很重要，同時這也是我們很容易疏忽的地方。各塊代碼的功能如下：

　　Block 1：描述性的注釋。首先把題目放到注釋里，讓reviewer知道你現在做的是哪道題；其次是要對題目進行簡短的分析，讓reviewer了解你的思路，節省他閱讀代碼的時間；再次是提一下你將用到的關鍵技術以及你的concern。比如說你現在是按小文本的輸入寫出的最好的代碼，但如果是大文本輸入，需要更改邏輯。這主要體現出一個人的溝通能力。不管你自己知不知道該怎么做，首先要想到的是讓對方知道哪些是你能夠應付得來的，哪些是你的問題。忌諱按照自己的假設去答題。如果條件不明確，需要你自己提出來。客戶很喜歡別人跟他討論，這樣可以明確需求，減少風險和不確定性。客戶也很喜歡別人有問題時馬上提出來。總體來說，他們很能容忍你有問題，但不能容忍你隱瞞問題。

　　Block 2：自動生成的代碼。這里最重要的是注意命名規則。根據需要增加一些注釋也是很好的習慣

　　Block 3：代碼的主體部分。方法前面加注釋是好習慣。變量最好集中聲明，顯得比較整潔有條理。一定不能遺漏的是數據的合法性驗證，健壯性是代碼的重要指標之一。Good test case 和 bad test case 至少各有一個。程序的可擴展性也很重要，少用hard code。

　　Block 4：異常處理。一定要有。

2. 盡可能多地去顯示你的能力。從客戶的角度來說，他們也很歡迎candidate全面地去展示自己
　　1. 多用OO的概念去思考問題
　　2. 替客戶去想他們自己都沒有想到的問題，但不要天馬行空。例如，Scalability就能很好地展示自己思維的縝密
　　3. 適當展示自己design的能力，這一點很重要。即使是很小的問題，也是需要全局把控的。

3. 一個很重要的觀念需要candidates轉變過來。客戶面試的根本目的不是為了難倒candidates，而是為了給candidates一個展示自己能力的平臺。所以對于客戶給出的題目，應該用工作的態度去應對，而不是用考試的態度去應付。很多優秀的候選人給我們的感覺是：讓他實際工作，他可能會考慮得很全面，而答題的時候，他就顯得比較馬虎，完成要求就算結束。原因大概就在這里。這樣的結果是，別人只能看到他考試的能力，看不到他工作的能力。

管理上：

技術上半場是技術面試，沒有問到管理的問題，但是我也想辦法體現了自己的能力，比如告訴客戶我還是比較了解軟件開發過程的，從需求分析，需求確認，設計，編碼，Code Review，測試以及需求變更方便的東西，在估時方便有悲觀估時也有樂觀估時，同時在自我介紹的時候也通過項目的實際經驗向客戶灌輸一些其實你懂很多東西這個觀點。

溝通：

客戶相對來說是個比較容易溝通的人，在需求確認的時候就能看出來了，沒有趾高氣揚的架勢，以至于后來我反而去表揚了他一句“Good catch”，所以，在任何面試的場合，只要溝通做到位了，其實技術差一點也無所謂，就像前面，我連Console.Read的基本用法都不會了，也沒有什么事。

非技術面試

下半場的面試是下午1點開始的（客戶時間晚上8點），主要是問項目/Team管理和溝通方面的問題，主要問題如下：

1. Give examples (include the documents in reply) of Architecture document/Design Document/Code Review feedback/Status report
   客戶要看我們日常項目里的文檔，這個沒什么問題，因為平時項目都是有的，我只是把Code review的文檔做了一些詳細講解，比如兩輪review+錯誤分級和優化分級，然后把平時發給客戶用的日報和周報也都展示了一下，但是在后面展示給面試官看架構文檔和設計文檔的時候，我特地說了一句，這個文檔我現在不能傳給你，因為牽涉到之前的客戶信息，由于我們公司不允許把每一個客戶項目相關的任何內容公布，所以如果想看的話，我要把一些信息加工屏蔽處理以后，才能發給你一個大綱，客戶表示滿意，因為他說了句：恩，我們的項目也是需要保密的。
   
   
2. How do you estimate work?
   估時這個問題相對來說，比較寬泛，如果按照自己的絕對堅持的方式告訴客戶，很有可能和客戶的預期不一致，所以我的大體答復如下：
   在真正做需求分析之前，估時的話，我一般是參考歷史數據來估計，主要是包括之前是否做個相似的系統或者子模塊，或者是公司是否有現成的系統或者子模塊的解決方案可以直接利用，然后再參考一些特殊的要求給出一個預計。
   在做需求分析之后估時，一般會按照up2down的方式，也就是將系統細分成子系統，子系統細分成子模塊，子模塊細分成子function，然后逐一估計，另外我也會讓Senior（或者我的backup）給出自己的估時清單，最后會進行比較，然后對有較大差異的部分進行重新估計與討論，以便最終達成相對的一致。
   另外，我也列舉了一般估時需要考慮的點：
   　　1. 項目大小以及項目難易程度
   　　2. 客戶或公司的特殊限制約束
   　　3. 每個Level的工程師數量以及Skill的能力
   　　4. 開發步驟，每個步驟大概需要多少天（調研、分析、原型設計、架構、詳細設計、編碼、測試、bug修改、維護）
   　　5. 交付物的數量（即客戶需要什么樣的交付物，因為不同的公司可能需要不同的交付物文檔）
   　　6. 會議、溝通、培訓、Travel的時間
   　　7. 有無任何可以重用的組件或者解決方案
   　　8. 項目風險（CR，離職，換人等）以及Buffer
   
   
3. What, in your opinion, are the roles and responsibilities of a tech lead?
   我的答復：主要職責是項目和技術分析，方案決策，task assignment, schedule, scope, quality, technology and communication等，有時候，TL就是一個manager，因為他需要跟蹤和控制項目的進度，找出項目風險然后避免這些風險，有時候又是一個BA，因為他需要有一個好的知識去完全理解客戶的需求，所以說TL也是架構師和開發人員之間一座非常重要的橋梁，另外，TL也應該是一個技術決策者，在合適的時機做合理的決策，同時TL也在平時也應該負責整個Team的培訓工作。
   
   
4. What are your strengths?  What are your weaknesses?  List 3 of each.
   在列舉優勢和劣勢的時候，優勢肯定要是優勢，劣勢也得時優勢才行，當然你不能太明顯了，我的答復如下：
   優勢：
   　　1. 很強的IT背景和分析的能力
   　　2. Team管理經驗和項目交付方面有很多經驗
   　　3. 擅長溝通（從客戶/公司到Team，從Team到公司/客戶)
   劣勢：
   　　1. 對項目成員要求非常嚴格（比如所有的文檔必須用我指定的統一的模板，成員一般都喜歡flexible的風格）
   　　2. 做Solution review的時候，太注重細節（經常在做決策的時候浪費不少時機）
   　　3. 經常開會（但開發人員一把都討厭開會太多的會）
   
   
5. Describe the size and structure of your most recent team that has reported up through you.
   主要還是想了解我最近的項目的結構和大小，以便確保我能否勝任他的工作，我按實際情況回答如下：
   　　1. BA:2個
   　　2. 架構師: 1個
   　　3. C#開發組:9個（1個Lead，6個高級，2個中級）
   　　4. BI開發組:8個（1個Lead，4個高級，3個中級）
   　　5. C#測試組:7個(1個Lead，6個測試)
   　　6. BI測試組:6個(1個Lead，5個測試)
   
   
6. Give an example of how you’ve dealt with a conflict or issue and how it was resolved.
   這個問題，剛開始還是以技術背景來理解的，后來想了想，應該是以管理背景來回答這個問題，首先，應該先找到問題的原因，然后列出關鍵點和對當前項目帶來的風險，然后提供至少2個解決方案，同時給出每個解決方案的優缺點，最后會根據issue的重要程序和影響的大小來決定最終使用哪個方案。
   
   
   給出的例子，就是上個項目里遇到的，當初客戶要求用Windows服務+Access數據庫的形式來部署到100個KTV門店上，后來實施部署的時候發現部分程序的門店使用的是SQLite數據庫或是Excel表。后來我們只用了4天就解決了支持多數據庫源的問題，首先我們原因是發現了，然后列出了修改這些程序的風險和方案，后來結合客戶的要求，先部署可以部署的程序，程序升級以后在通過我們的自動升級機制來升級成通用版本，當然這也得益于IOC這種技術的幫助，不過這個4天的時間依然在我們的Buffer之內，并且我們的代碼也能很好的支持其它的數據源了。
   
   
7. How do you assign work items to your team members and how do you track their progress?
   由于很推崇敏捷，所以我們的開發一部都是按照2周為一個Sprint，所以每個Sprint我們都有明確的工作計劃，明確了我們應該做什么，有什么樣的交付物，另外分配任務的時候會根據不同的level的人給不同的任務，誰熟悉那一塊就盡量做那一塊，當然以便我們可以高效地利用時間，另外優先級比較低但是也比較重要的任務也會讓middle的人去做，不過通常我都會指定一個Senior的人做他的mentor.
   
   關于項目跟蹤，我們一直使用的是DailyScrum的形式來監控進度，通過跟蹤4個事情來確保項目處在合理的軌道：你今天做了啥？/你正在做啥？/有沒有任何問題需要別人的幫助？/明天的計劃是什么？，當然在問這些問題之前，他們還有一定的時間去做pair review的。
   
   
8. How do you measure and monitor the quality of the code delivered by your team?
   我的Team在質量控制方面一般分位2部分：
   　　1. 任何設計和方案無論大小，在Coding之前必須經過review和approved以后才能開始，
   　　2. 所有的task都要進行2輪的Code review，第一輪是編碼中期，以確保方案理解是否正確，第二輪是編碼結束以后。
   同時，所以的bug都要進行逐一分析和總結教訓，一般下一次不再犯類似的錯誤。
   
   
9. When and how do you escalate design, technical implementation and quality issues to Onsite tech team? 
   答復如下：工作過程中，如果我們在設計，技術或者issue上做出決策的話，我們會發生郵件給Onsite尋求幫助，不過在尋求幫助之前，我們會至少提供2個方案，列出每個方案的優點和缺點，告訴我們比較傾向于哪個方案（以及為什么），方案包括分析結果、技術方案、估時、風險等，在offshore經過充分的討論以后，會發給客戶尋求幫助。（注：千萬不要說，我們只要不懂，就發郵件問客戶，因為客戶出出錢讓你干活的，不是來培訓你的，充分提供資料給客戶，讓客戶做決策是個好主意，因為客戶了解的自己公司的東西遠遠比我們多）
   
   
10. How do you transfer the knowledge to new team member?
    在如何向新人transfer方面，一般剛開始會有一個high level的培訓會議，然后show一些重要的PPT給他一個整體的講解。然后每天會給新人提供很多文檔用于學習，每個文檔都會有一些key point一般他能否很快速的了解相應的業務知識，第一個月，我們有每周一次的check meeting來檢查他的學習狀態和學習結果，以便確保他能理解這些東西，當然也會回答他各種各樣的問題，與此同時，如果我們發現有一些東西需要更新或者通過新人提問也讓我們發現有些東西需要加進去的話，我們也會更新我們的文檔。在學習結束以后，一般我們會分配1-3個簡單的任務給新人，同時指定一個Mentor帶著他做，以確保他能真正上手項目，并且熟悉我們的開發流程。
    
    
11. How do you make sure members of your team are fully aware of functional and technical changes happening in your project?
    如果讓所有的人都知道需求變更，首先會把所有的CR發送給所有的項目組成員以確保所有的人都理解這個CR，然后所有的人都要對這個CR進行分析，以便確保這個CR到底和自己手頭的活有沒有關系或影響，如果有影響的話，自己的改動又會不會再次影響別的人；同時所有干系人都要提供針對這個CR的方案、估時和執行計劃。
    然后，我們會和onsite客戶溝通我們的這些方案和計劃，讓他們來accept或者reject這個CR。
    當然，我們也有自己的Traceability Matrix系統來跟著所有的需求變更，以便后期可以做分析總結，提示我們做分析、設計、架構、編碼的能力，盡量在每個CR到來的時候不需要改動太多的代碼。(其實還有一點作用，就是，萬一出現問題，可以拿出來作為證據，因為這個系統里也記錄了客戶的郵件呢，嘿嘿，只不過這個一點沒有告訴面試官)
    
    
12. Do you support cross training your team members? Give us the reason why would you support or why you won’t.
    交叉培訓這一塊，其實我本人是贊成的，因為每個人都有自己的強項和弱項，通過在項目過程中或者項目結束大家可以share各自的信息以便互相提高。
    不過，對于交叉培訓，我有2個理解，一個是同一項目組不同skills人的培訓（比如CSS高手和JS高手互相培訓），在這一個層面上，大家互相share的東西相對比較多，另外一個是不同項目組之間的交叉培訓，比如DW BI Team可以向C#開發Team共享一些東西，C#也可以共享一些東西給他們，這個層面上，我本人不希望有太深入的培訓，畢竟不是主業。
    不管怎么說，交叉培訓其實還是挺好的，因為可以讓每個人或者每個項目組都有一些提升。
    
    

再回答完這些問題的時候，其實基本上已經過了3個小時了，因為沖突可能因為印度式英文的理解上耽誤了一些實際，但總體效果上還是不錯的，充分表達了我想說的內容。

后面又大概聊了半個多小時，主要是問我平時是如何發郵件的，郵件里的To/CC/BCC都是怎么用的，以及如何給項目組成員作評價，如果想領導要特殊的支持等方面的軟技能了，平時怎么做的，我也就按實說了。

最后，估計R先生也覺得問個差不多了，而且他也困了（已經是他的夜里快12點了），所以就說我們到此為止吧，還說會盡快給答復的，當然最后我也花了很多詞匯恭維他，因為他從下午4點一直到夜里12點一直花時間來面試我：我很appreciate你花了那么多時間來面我，對我來說這是一個很excited的面試，你真的是一個很Nice的人，我真的很希望能做你的項目和你一起共事。

非技術面試總結

這一塊面試，主要考察的是2部分，一部分是項目管理方面的東西，看你是不是能很熟練地管理項目，確保項目質量按實提交交付物，同時也考察了你如何和客戶進行溝通規避風險，最后要問了一些軟技能的東西，比如發郵件的時候，什么時候該To，什么時候該C，而又什么時候該BCC，以及和同事相處及評價的態度等方面的問題。

另外還有一點，我覺得也是非常重要，那就是面試官花了很多時間在你身上，在結束的時候你應該多感謝一下他，這樣他會很開心，即便不要你，以后說不定還有機會呢。

結果

通過了，終于讓VP Happy了一把，之前pending的一批已經通過面試但不讓簽ECA安全協議的人也都陸續開始和客戶簽協議了，當然我也從原來的部門調到了新成立的ODC，同時原部門把博客園的兄弟NewSea挖了進來，以便能夠繼續之前的工作，1個月交接以后，我就飛往西雅圖，去客戶現場進行Domain Knowledge的培訓去了。

后續

以至于，后來還沒用交接完，客戶就讓我自己去招聘下面的Senior人選了，估計也是為了向他的老板匯報一下吧，所以，在找到合適的人選后，我的第一份正式的郵件，就這樣發出了（文中的H*，也是博客園的一個大牛哦，目前和我一個組，有機會和大家介紹一下）：

Hi J*** and R***

We are having the candidate H*** who qualify from our interview, we would like get your approval on the hire recommendation.

Below is my feedback after talk with H***, please let me know if you have any concerns.
Thanks.

General feeling in the interview:
H*** is proactive on communication, he has a good communication, also he would like to focus on .net development and passionate about the ODC project.he is talkative and introduce a lot aspects of himself and showing interests in ODC project on the project size, working method, etc.

Strength:

    He show a good technical background especially on OOP Design/javascript/asp.net areas.
    Deep understand on .NET CLR and OOP Design.
    He is confident on the asp.net/JavaScript, and self-learning capabilities.

Weakness:

    Limited oral English, however he shows potential as their reading/written English is good.


Hire recommendation: Hire

招聘

另外，我們最近也在招人，有興趣的請聯系我，基本條件如下：

1. 6年以上C#開發經驗，熟悉MVC
2. 熟悉JavaScript，熟悉前端開發
3. 能通英語口語進行簡單的溝通
4. 崇尚敏捷開發

同步與推薦

本文已同步至目錄索引：《大叔手記全集》

大叔手記：旨在記錄日常工作中的各種小技巧與資料（包括但不限于技術），如對你有用，請推薦一把，給大叔寫作的動力。