58同城研發面試題
58同城 20xx研發一面面試來臨了，你準備好了嗎?面試時不要緊張，下面就由本站小編為大家介紹一下58同城20xx研發面試題的文章，歡迎閲讀。
58同城20xx研發面試題篇1
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)都滿足需求的情況下，用你最熟悉、最拿手的方式
至於“數據共享、同步”、“編程、調試”、“可靠性”這幾個維度的所謂的“複雜、簡單”應該怎麼取捨，我只能説：沒有明確的選擇方法。但我可以告訴你一個選擇原則：如果多進程和多線程都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。
需要提醒的是：雖然我給了這麼多的選擇原則，但實際應用中基本上都是“進程+線程”的結合方式，千萬不要真的陷入一種非此即彼的誤區。
58同城20xx研發面試題篇2
怎麼傳輸數據的?
長連接和短連接的區別以及使用時機
2.C#怎麼管理內存的?
58同城20xx研發面試題篇3
如果你需要你的上司給你寫一個模塊，兩天之後你要用到，但是上司要在第三天才給你，導致你的工期延誤，你會怎麼做?
補充：今天收到58給的offer，薪資還算給力。總結了一下成功的原因，發現還是有很多技巧的。實力肯定必須擺在首位。但是，面試的成功不僅僅靠實力説話，成功的標準是“通過這幾十分鐘的溝通，結束之後面試官是否樂意今後與你共事。如果他感覺很好，面試就成功了;如果他覺得以後不想和你相處，面試就失敗了。”因此，博得面試官的好感大於把每一道題都準確無誤地“背”出來。經過這麼多長面試，我覺得面試時注意以下幾點：
1)多和麪試官交流想法而不是“他問你答”的刻板面試。
2)代碼的風格(變量命名規則，縮進，函數命名，代碼整潔度，魯棒性等)大於代碼的正確性，因為你的代碼他能力再高也不會在很短的時間內讀的很透徹，大部分精力應該就放在風格和邊界值等上了。但是，也不能犯那種重大的邏輯錯誤(只要面試官憑感覺看不出來就可以了)。
3)説髒話在一定程度上會起到良好的效果。但是，要有個度!偶爾一句“TMD”“坑爹”“這道題最蛋疼了...”"XXX代碼寫得亂七八糟的..."等有助於打破“很正規”的面試氣氛。更平等地交流。(PS：你和你的同學、同事説話不會有任何拘束吧，把面試官就看成你的同學或同事)
4)當遇到不會的題或不明白的知識點，又需要表現的十分謙虛和好學。勇敢地把你不清楚的説出來和麪試官交流討論而不是忽略過去避而不談。比如可以説“我在很多地方都見到多這道題但是一直沒有找到一個滿意的答案，您能給我講講思路麼?”或者説“我感覺這道題可以用XXX方法做，而且時間複雜度還不錯，但是具體的思路還沒有想透徹!”
5)當面是官甩給你一道題後你感覺可以用O(n)的時間複雜度完成但是僅僅找到了O(n^2)的解法，這是不妨這麼説“我曾經記得有個O(n)時間複雜度的解法，但是現在只想到了一個O(n^2)的解法，不妨我説一下思路吧，您看看還有什麼改進的地方沒。”然後補充道“其實有時候過分關注算法的時間複雜度並不是好的軟件工程思想，很多時候花了大部分精力優化的地方並不是性能的瓶頸，還不如一個複雜度稍差但清晰易懂的算法呢!”
6)加分點：你的技術博客、平時看的書、經常瀏覽的論壇、參加的項目、關注的最新技術(哪怕只能説出皮毛)、崇拜的偶像(當然是IT行業的，周潤發什麼的就別説了)、新奇的想法等。在面試的過程中儘可能抖出來，比如説“我在XXX論壇上看見他們是這麼討論這個問題的.....”比“我覺得是這個問題應該這樣解決....”要好。總之，儘量在交流中把這些點説出來