1. 毫無疑問，面試得從筆試開始，先在筆試的時候讀程式碼寫結果，還是很簡單的一道題，不過就是考C#繼承，建構函式，及new對基類的隱藏等基礎知識，換做誰應該都能做出來。
2. 接下來的筆試問答題也還算簡單，也不過就是諸如裝箱拆箱，類和結構的區別，GAC，CLR等等基礎得讓人崩潰的基礎，說崩潰，是因為它們都是剛畢業那年為了找工作曾試著死記硬背的概念，其實接觸得多了，就算撇開概念也能較為清晰地描述它們，只是可能名詞稱呼不夠專業。
3. 緊接著就是編碼題，常見的編碼題就是排序，這次也毫無意外，寫了一個比堆排序容易超級多的快速排序，寫完心裡還蠻忐忑的，雖然腦袋裡嘗試執行的時候結果好像是對的，然而總覺得哪裡有問題，問題不是出在實現上，而是那一瞬間，突然不知道自己寫出來的是不是快排了，只能肯定不是冒泡，冒泡可沒那麼長的程式碼。這裡需要注意一點：如果能寫泛型程式碼儘量寫泛型，一個原因是泛型的作用還是很明顯的，還有，寫成泛型，稍稍好像有提升自己的檔次吧。當然，如果寫成 int[] array，回頭面試官八成還得問你，那我要是傳入的是一個string[] array(這個可能性會相對小)或者byte[] array，long[] array怎麼辦?
面試的時候，他肯定了我寫的是正確的快排，還提醒我，所有排序裡面只有快排是用到了遞迴，所以只要你寫出了遞迴，就可以肯定是快排。雖然自己沒有一一去驗證，不過就我所知道的為數不多的排序演算法裡，仔細想想，好像確實只有快排用到了遞迴。面試官還專門寫了幾個數字，問快排第一趟排序結束後的排序是什麼樣的，大概是怕我死記硬背這段程式碼，而不知道具體的邏輯吧。我稍微用筆畫了一會，然後回答出來了，或許是為了驗證我確實懂排序，又拿著同樣的數列，讓我用冒泡方式寫出第一次排序結束後的情況。還算ok，排序和查詢的演算法，以前還是理解得比較深刻的，當然，只限於簡單的部分，要是問我諸如堆排序什麼的，我就只能舉雙手投降了。堆排序以前也仔細研究過，不過好像跟樹有關，結果是將這些演算法邏輯都還給書本和老師了。
4. 依然還是編碼題，丫丫的，有你這麼考我的麼?我是應聘測試開發類崗位的自動化測試工作，測試開發，什麼叫測試開發，開發是為了更好的測試，我又不是真的應聘開發，尼瑪以為我對C#是有多熟悉，多瞭解吖??居然讓我實現ace()方法，還不能呼叫API，說真的，給我一個用例讓我呼叫 Replace方法做字串的替換，我都可能不知道Replace有幾種過載方法，以及每一個過載方法的引數有哪些，可是題目放在那裡，總不能不會實現也沒有任何思路吧。總不能開啟手機上網百度吧，手機流量也不多了，捨不得用。為了留下良好印象，也總不能直接寫上“我不會”三個字吧。
栽了栽了，就栽在這題上了，心裡沒有任何慌張，只是很冷靜地面對這樣的事實，也許是過分的冷靜吧，腦子裡突然有點意識到了什麼，如果記憶沒有騙我的話，這個題，早在三四年前，某人曾經跟我一起討論過，只是那時候我編碼一塌糊塗，也無心學習，對於這種演算法，程式設計什麼的對話，我頂多當他自言自語，理解不了，或者說懶得去理解。
閉上眼睛，努力搜尋那一幕幕微小的記憶片段，究竟那時候他自言自語說的是什麼，印象中是他曾在某公司面試C#開發崗位的時候碰到過的， 也是現場沒有回答出來而回到家裡繼續研究來著，當時他究竟研究出了什麼結果。不記得眼睛閉了多久，也不記得腦子裡飄過了多少東西，卻很清晰地，抓住了，就是它，沒錯，三四年前，他說過，用CopyTo的方法，只要匹配到輸入的'string中需要被替換的字串及知曉原字串長度，就可以知道 需要被複制的長度 = 索引-需要被替換的字串的長度(這僅限當時的想法，和具體實現的程式碼邏輯對有出入)，而一旦找到了這個關係，用CopyTo的方法將原來的字串替換成需要被替換的字串，即使用To (int sourceIndex, char[] destination, int destinationIndex, int count)(不要問我為什麼Replace的過載方法及引數記不住，CopyTo卻記得那麼清楚，前幾天剛幫某個群的某個朋友看一段程式碼的時候，剛好裡面有CopyTo方法，出於對它的好奇，還特地搜尋過，因為時間不長，所以記憶深刻，沒辦法，我記憶力比較好~)，可是，然後呢?char[]的陣列是什麼?又問了自己幾個問題，腦子裡思路似乎是漸漸清晰起來了，不過似乎挺凌亂，所以真讓我從頭到尾實現這個方法，與其說給我多少時間能解決，更可能的情況是，我根本寫不出來，不得不說，似乎蠻複雜的。算了，還是放棄吧。(程式碼實現其實也不難，只是本人不得不承認，編碼能力有限，沒能現場搞定，程式碼在文章結尾已附上)
5. 緊接著的題也讓我有想放棄的想法，因為這題是根據寫出的ace()方法進行測試用例的設計，按我正常的邏輯(僅限於本人的思維，不表示正常人的正常邏輯思維)思考，上一題都沒寫出來的話，這題應該是做不到的吧。可是這個念頭很快就打消了，開國際玩笑吖，測試是我本行，開發我甚至可以一竅不通，用控制檯實現Hello World我可以完全不會，可是測試怎麼能放棄，好不容易看到一道題考測試耶~立刻稀里嘩啦寫了一通我小小的腦袋瓜能想得到的一切可能用於測試的用例。
6. 考題算是告一段落，ok~正式進入面試階段，諸如自我介紹，根據之前工作的專案經驗提問的一系列問題，我滿腦子飄過的只有春晚大張偉唱的十幾個字：天空飄來五個字，那都不是事兒~為啥，自己做過的專案，再怎麼地，就算自己描述不清楚還不能把對方說迷糊麼?好吧，我只是隨口說說，還是會盡力將工作的一些情況如實稟報的。
當問到自動化測試框架的時候，毫無意外地，搬出了我們工作所用的框架和Selenium類似這個看起來沒有說服力的理由，只是一個不小心說到了框架在功能測試上幫助比較大，但後臺資料貌似支援度不高，於是被面試官逮住問到，為什麼框架不支援後臺資料?為什麼?為什麼?突然滿腦子的問號浮在了我臉上，不記得我嘴有沒有嘟鼓起來(我鬱悶的時候很容易嘟嘴)，我有病啊，沒事說什麼對後臺資料支不支援，別人寫的框架，別人搞出來的問題，我怎麼知道是對方不樂意寫出對後臺資料的支援還是沒開發完成這個框架啊?可是我總不能這麼回答吧，於是，稍作思考，這個時候就特別嫉妒自己的小聰明，怎麼會如此聰明的腦袋呢?哈哈，也許有一秒鐘時間我在微笑，然後回答到：因為我們這個框架是針對UI層設計的，主要是對頁面進行操作並驗證相應的功能，因此沒有提供對後臺的支援(不知道正確答案是什麼，反正我就這麼回答了，是正確的最好，不正確至少從我的角度忽悠了他，至於他是不是被忽悠到了，對我來說並不那麼重要)。