今天參加了微軟的面試，不得不說，自己還是too naive。
礙於規定，面試題目不可細說，只好說說大概。不過三面中的一個題目，面試官說的我不是很理解，因此等下會詳細說。
首先，微軟的技術面，每一輪都是要寫代碼的。面試官會根據簡歷簡單的跟你談談，然後給一個題目開始寫代碼。
題目可能會比較簡單，但是會要求你考慮很多比較奇怪的情況。
舉個例子，鏈表操作的題目，有可能會要求你的程序能夠處理鏈表成環，鏈表相交的情況，非常噁心，但又不是沒有道理，因爲你的代碼不可能只是你自己用，你的同事、後輩可能都會用，而他們很可能不會看到你是怎麼寫的，因此儘量保證不會出錯，哪怕是錯誤的調用也不會出錯，確實是很重要的。這也是與許多別的公司不同的一點。
一面
一面大概就是先隨便聊聊，然後開始寫代碼。順帶一提還讓我用英語做了自我介紹，因爲四面會有澳大利亞的老大來面。
隨後開始寫代碼，給了一個鏈表的題。由於之前看過一些面經，特別注意了空鏈表的情況，還有跟面試官確認參數和返回值格式等。
不過還是忽略了鏈表相交時的問題，當鏈表相交的時候，會指來指去指成一個自環，然後程序就當在那個循環上了。
說真的，正常人寫程序的時候，誰會把兩個相交的鏈表或者有自環的鏈表塞給一個函數啊。
不過在微軟，這顯然是不行的，因爲你寫的函數不僅給你自己用，還會給別人用。萬一別人犯蠢給你傳個奇怪的鏈表進來，也不是不可能的。
好吧，趕緊改。畫個小圖模擬一下，然後改了過來。
面試管對着我非常ugly的程序看了一眼，然後巴拉巴拉嘟囔了一陣子這裏跳那裏，如果啥樣有咋樣之後，說：哦，好吧，這種情況下雖然看起來雖然不太對，不過下一次迭代又調整回來了。（我寫程序的都不知道他在說什麼……）
總之，通過了。
二面
二面先是隨便閒聊了一會，不過面試官講的我都不是很懂，什麼軟件開發模型、敏捷開發之類的。
不過二面出的題就比較簡單了，以前初中的時候做過。我照着初中的做法寫了一遍，當然這個做法是沒有問題的，不過面試官似乎不如上一個面試官“身經百戰見得多了”，給我舉了一個反例，然而這個反例在我的程序中是不可能出現的。
然後問我如果讓我來測試，我會怎麼測試。
首先我給了幾個邊界測試，然後面試官提示我常規測試的情況。這個我就不是很清楚了，我只好說用一個非常樸素非常暴力的做法生成一組絕對沒問題的測試數據，然後輸入程序中測試。
三面
三面首先聊了聊簡歷上的項目，比如說之前我寫過的一個非常簡陋的管理程序。先是問了一些細節，然後拋出一個問題：你這個現在是單機的，如果它要上線，你覺得需要哪些改進？
好吧，其實我根本沒有相關經驗，就開始扯，數據庫上SQL啊，集羣啊亂七八糟的。
之後寫程序，大概是一個類似模式匹配的問題。由於我沒跟面試官討論清楚真正的匹配意圖，寫出了一個錯誤的匹配程式。
不過面試官非常kind，還是接着這個錯誤的思路進行討論。
在此我把問題重述一下，即
兩個等長的字符串，能否按照位置一一對應的在兩個集合間建立一個雙射關係。
顯然，我的思路是建立正反兩個映射表，然後遍歷字符串，如果表中無記錄，則將這個雙射關係記錄下來，如果有記錄且衝突，說明失敗了。
對於每次查詢來講，需要查詢兩個表是否爲空，如果不爲空是否匹配，因此時間複雜度在o(4)；
對於每次增加記錄，只需要將對應的位置寫上對應的值，因此時間複雜度在o(2)；
因此對於長度爲n的字符串，時間複雜度應該爲O(n)，常數爲6。
不過面試管問是否可以優化？
Excuse me? 已經O(n)了我要怎麼優化？！！
面試官提示我說，我的一個鏈表是多餘的，有一種數據結構，可以記錄<x, y>，既可以以x爲關鍵字查詢匹配的pair，也可以以y爲關鍵字查詢pair。
可是這種東西，單查詢的時候時間複雜度會是常數？
因此我是不太理解的……不過，理解錯了面試官的意圖，確實是我自己的鍋。
Normal End
於是在三面過後，被HR姐姐叫出去說，因爲面試coding的時候表現不太好，主要是不像春x和雪菜那樣的熟練（打死），因此無法給我安排四面，就回去了。
好吧，不能算Bad End，最多算是個Normal End。想想看，我世一大大約8人去面試，除了我一個不是CS的本科生，還有一個CS的本科生外，其餘都是CS的研究生。還有兩個Eagle實驗室的，身經百戰見的多了啊，怎麼比嘛。
不過至少也不虧，多少算是見識了一下微軟，以及微軟的做事風格。不得不說，微軟能做這麼強不是沒有道理的，跟其強大的管理是分不開的。
—FIN—