1.手寫KMP演算法

我猜測考這道題並不是真的要被面者把KMP演算法一字不漏的寫出來（當然能寫出來最好），面試官一上來就出一道很難的題可能有兩點用意：

1）看看被面者心理承受能力，是說道KMP就跪地求饒呢還是拼死拼活寫點算點？心態很重要，顯然後者更好

2）寫出程式碼了，看看被面者的程式碼風格怎麼樣？有沒有把程式碼寫得很魯棒？有沒有考慮到邊界？有沒有用簡潔易懂的變數名？

2.0.執行緒和程序的區別

1）程序是CPU分配資源的最小單位，執行緒是CPU排程的最小單位

2）程序之間是獨立的，每個程序獨享資源（如記憶體空間），而執行緒間是共享記憶體（除了棧以及暫存器外）。因此線上程間可以直接互相通行（直接訪問同一塊記憶體），而程序之間需要特殊手段，例如管道、訊息佇列、共享記憶體、訊號，socket等

3)執行緒是輕量級的程序，開銷通常要比程序小，因此能用執行緒的地方儘量用執行緒。

4）一個程序至少擁有一個執行緒，即主執行緒（Main Thread）

2.1既然執行緒比程序開銷要小，那具體小在哪裡？

執行緒的開銷是明顯小於程序開銷的,主要體現在建立和上下文切換的時候。我在一本書上看到，Solaris 2中 程序的建立要比執行緒建立慢30倍 ，程序切換要比執行緒切換慢5倍。那麼，為什麼程序和執行緒的效率差別如此之大呢？

1）資源開銷：作業系統每建立一個程序，就要為之分配一筆很大的資源，比如I/O，記憶體等，而每個執行緒所佔用的資源要比程序小得多。通常執行緒自己只需要獨立的棧空間和暫存器空間就可以了，其他資源都和其他兄弟執行緒共享。因此在建立的時候，程序要比執行緒慢得多

2）作業系統的管理：每個程序有一個PCB，每一個執行緒有個TCB，分別記錄的都是程序和執行緒的當前狀態。但是，PCB要比TCB大得多，是一個龐大的結構體（struct），在程序切換時，涉及到整個當前程序環境的儲存環境的設定以及新被排程執行的環境的設定（即先將當前程序的狀態儲存到自己的PCB中，再用新程序的PCB初始化當前執行環境），而執行緒切換隻需儲存和設定少量的暫存器的內容（也是儲存在TCB中）

2.2哪些情況下必須要用程序？

我們說過，在能用執行緒的地方儘量用執行緒，因為執行緒無論在資源佔有還是效率上都優於程序。但是，程序的存在，也是有其必要的。下面就談談什麼時候用執行緒更恰當，什麼時候用程序更恰當。其理論依據，還是線上程和程序本身的特點和區別。

1）需要頻繁建立銷燬的優先用執行緒
原因請看上面的對比。
這種原則最常見的應用就是Web伺服器了，來一個連線建立一個執行緒，斷了就銷燬執行緒，要是用程序，建立和銷燬的代價是很難承受的
2）需要進行大量計算的優先使用執行緒
所謂大量計算，當然就是要耗費很多CPU，切換頻繁了，這種情況下執行緒是最合適的。
這種原則最常見的是影象處理、演算法處理。
3）強相關的處理用執行緒，弱相關的處理用程序
什麼叫強相關、弱相關？理論上很難定義，給個簡單的例子就明白了。
一般的Server需要完成如下任務：訊息收發、訊息處理。“訊息收發”和“訊息處理”就是弱相關的任務，而“訊息處理”裡面可能又分為“訊息解碼”、“業務處理”，這兩個任務相對來說相關性就要強多了。因此“訊息收發”和“訊息處理”可以分程序設計，“訊息解碼”、“業務處理”可以分執行緒設計。
當然這種劃分方式不是一成不變的，也可以根據實際情況進行調整。

個人理解：強相關涉及到兩個工作任務之間的強依賴，如頻繁交換資訊；弱相關就是兩個工作任務間幾乎沒有交流，各自獨立工作。
4）可能要擴充套件到多機分佈的用程序，多核分佈的用執行緒
5）都滿足需求的情況下，用你最熟悉、最拿手的方式
至於“資料共享、同步”、“程式設計、除錯”、“可靠性”這幾個維度的所謂的“複雜、簡單”應該怎麼取捨，我只能說：沒有明確的選擇方法。但我可以告訴你一個選擇原則：如果多程序和多執行緒都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。
需要提醒的是：雖然我給了這麼多的選擇原則，但實際應用中基本上都是“程序+執行緒”的結合方式，千萬不要真的陷入一種非此即彼的誤區。

3.程序各種狀態之間的轉換怎麼樣的

注意：從執行態切換到就緒態不一定只是時間片可以，程序排程演算法中的高優先順序搶佔低優先順序程序都會使程序從執行態轉換到就緒態

4.0.http怎麼傳輸資料的？

4.1.http長連線和短連線的區別以及使用時機

5.C#怎麼管理記憶體的？

6.如果你需要你的上司給你寫一個模組，兩天之後你要用到，但是上司要在第三天才給你，導致你的工期延誤，你會怎麼做？

補充：今天收到58給的offer，薪資還算給力。總結了一下成功的原因，發現還是有很多技巧的。實力肯定必須擺在首位。但是，面試的成功不僅僅靠實力說話，成功的標準是“通過這幾十分鐘的溝通，結束之後面試官是否樂意今後與你共事。如果他感覺很好，面試就成功了；如果他覺得以後不想和你相處，面試就失敗了。”因此，博得面試官的好感大於把每一道題都準確無誤地“背”出來。經過這麼多長面試，我覺得面試時注意以下幾點：

1）多和麵試官交流想法而不是“他問你答”的刻板面試。

2）程式碼的風格（變數命名規則，縮排，函式命名，程式碼整潔度，魯棒性等）大於程式碼的正確性，因為你的程式碼他能力再高也不會在很短的時間內讀的很透徹，大部分精力應該就放在風格和邊界值等上了。但是，也不能犯那種重大的邏輯錯誤（只要面試官憑感覺看不出來就可以了）。

3）說髒話在一定程度上會起到良好的效果。但是，要有個度！偶爾一句“TMD”“坑爹”“這道題最蛋疼了...”"XXX程式碼寫得亂七八糟的..."等有助於打破“很正規”的面試氣氛。更平等地交流。（PS：你和你的同學、同事說話不會有任何拘束吧，把面試官就看成你的同學或同事）

4）當遇到不會的題或不明白的知識點，又需要表現的十分謙虛和好學。勇敢地把你不清楚的說出來和麵試官交流討論而不是忽略過去避而不談。比如可以說“我在很多地方都見到多這道題但是一直沒有找到一個滿意的答案，您能給我講講思路麼？”或者說“我感覺這道題可以用XXX方法做，而且時間複雜度還不錯，但是具體的思路還沒有想透徹！”

5）當面是官甩給你一道題後你感覺可以用O(n）的時間複雜度完成但是僅僅找到了O(n^2)的解法，這是不妨這麼說“我曾經記得有個O(n)時間複雜度的解法，但是現在只想到了一個O(n^2)的解法，不妨我說一下思路吧，您看看還有什麼改進的地方沒。”然後補充道“其實有時候過分關注演算法的時間複雜度並不是好的軟體工程思想，很多時候花了大部分精力優化的地方並不是效能的瓶頸，還不如一個複雜度稍差但清晰易懂的演算法呢！”

6）加分點：你的技術部落格、平時看的書、經常瀏覽的論壇、參加的專案、關注的最新技術（哪怕只能說出皮毛）、崇拜的偶像（當然是IT行業的，周潤發什麼的就別說了）、新奇的想法等。在面試的過程中儘可能抖出來，比如說“我在XXX論壇上看見他們是這麼討論這個問題的.....”比“我覺得是這個問題應該這樣解決....”要好。總之，儘量在交流中把這些點說出來

今天就簡單說這些吧，後面 有時間我會把我這些天以來的面試做個好好的總結，以饗後來人！