主要分為三次考核來記錄

線上筆試

這次一共五道題，前三道題很簡單，後面兩道暫時沒想到怎麼做。但是總是有一些case過不去，所以費了很多時間，印象最深的是尋找最長的迴文子串，這個很明顯要使用DP去做，但是卻告訴我記憶體超出限制，我也沒想到其他的方法了，也許該題的本意就是直接暴力尋找。

總體來說，感覺還不錯，至少可以通過50%的case，

第一次電話面試：技術面試

一共兩位面試官。

首先是出了兩道程式設計題

1）反轉二叉樹：直接遞迴DFS即可
2）給定五張撲克牌，大小王是通用牌，判斷是否是順子：直接尋找最長連續子串即可
程式設計題是通過線上共享文件來描述的，屬於很簡單的問題

要寫一個較為詳細的虛擬碼，然後面試官又讓寫一下第二道題的測試用例，我起初想的有點複雜，所以總結了所有的情況，但是根據面試官的反應來看，這道題是十分的簡單的問題，不需要想那麼的發展，都怪我我當時沒意識到。

接下來是計算機基礎知識的考察，

由於我研究生的科研方向是軟體工程，所以計算機網路的基本知識還可以，那麼就有以下的問題。

TCP和UDP的聯絡和區別

1.基於連線與無連線；
2.對系統資源的要求（TCP較多，UDP少）；
3.UDP程式結構較簡單；
4.流模式與資料報模式 ；
5.TCP保證資料正確性，UDP可能丟包，TCP保證資料順序，UDP不保證。

tcp協議和udp協議的差別 
            TCP             UDP 
是否連線     面向連線      面向非連線 
傳輸可靠性   可靠          不可靠 
應用場合    傳輸大量資料    少量資料 
速度        慢            快
 

請你設計一個可靠的UDP協議應該怎麼做

簡單說TCP保證了傳輸的準確性和相應的流量控制，而UDP不提供任何準確性保證。既然TCP提供這麼多完備的方案，為什麼還要大費周章地去設計RUDP呢，這裡主要願意可以用兩個字概括“速度”，TCP提供了過多的保護，在及時性上做了很多的妥協，比如：控制微包（Nagle演算法），延時ACK，流量控制，超時重傳等，這些設計嚴重影響了Tcp的速度和及時性。

幀同步中的UDP幀同步方案中邏輯幀一般都在8~16幀左右，一般都在12幀以上，這要的網路傳輸頻率決定了不可能採用TCP協議，那麼如果採用UDP會出現什麼問題呢？

1. 丟包，幀同步中邏輯幀在每個Client上一定是一致的，也就是說決定不能出現丟幀的情況，
2. 
 
資料完整性，UDP協議頭部雖然有16位的校驗和，但是IPv4並不強制執行，也就是說UDP無法抱枕資料的完整性
3. 亂序。 UDP並不保證資料的順序，故可能出現數據包亂序問題

以上問題任何一項都會導致Client在邏輯幀上出現不同步問題，為了解決這個問題就必須引入RUDP概念，這裡的RUDP主要是解決上述的問題，並不某個RFC定義的規範。

RUDP初步簡單思路，既然原生UDP有那麼多痛點，那我能不能像應用層協議一樣在UDP資料包頭再加一段包頭，從而定義為RUDP呢，答案是肯定的。首先思考RUDP需要解決哪些問題，然後根據問題加上必要的包頭欄位。

1. 資料完整性 –> 加上一個16或者32位的CRC驗證欄位
2. 亂序 –> 加上一個資料包序列號SEQ
3. 丟包 –> 需要確認和重傳機制，就是和Tcp類似的Ack機制
在思考一下既然是自定義協議是不是需要一個協議號欄位來過濾一些非法包，那麼又可以加入一個新欄位：
4. 協議欄位 –> protol 欄位，標識當前使用協議

綜合以上欄位，我們的RUDP就可以簡單實現成如下：

微信是使用TCP還是UDP

微信通訊中使用了HTTP短連線和TCP長連線，並沒有用到UDP，其中登陸驗證和頭像身份資訊及日誌等功能採用的HTTP，文字訊息、語音訊息、視訊訊息、圖片訊息這些使用的是TCP長連線。通過心跳包來維護長連線狀態，300S一個心跳。

微信是一直保持的和伺服器tcp連線嗎？

微信心跳包是300s一次，google原生的一般是1680s，原因是運營商移動閘道器會釋放tcp埠，tcp協議一般是10幾分鐘會換掉，udp埠資源更加緊缺，最好一分鐘內一個心跳包，否則很容易斷開，伺服器也就不能推送資訊了

接下來是作業系統基本知識

程序和執行緒的聯絡和區別

程序是表示資源分配的基本單位，執行緒是程序中執行運算的最小單位，

程序和執行緒的關係
（1）一個執行緒只能屬於一個程序，而一個程序可以有多個執行緒，但至少有一個執行緒。執行緒是作業系統可識別的最小執行和排程單位。
（2）資源分配給程序，同一程序的所有執行緒共享該程序的所有資源。 同一程序中的多個執行緒共享程式碼段(程式碼和常量)，資料段(全域性變數和靜態變數)，擴充套件段(堆儲存)。但是每個執行緒擁有自己的棧段，棧段又叫執行時段，用來存放所有區域性變數和臨時變數。
（3）處理機分給執行緒，即真正在處理機上執行的是執行緒。
（4）執行緒在執行過程中，需要協作同步。不同程序的執行緒間要利用訊息通訊的辦法實現同步。

然後問到我做得PLFF Solver用到多執行緒還是多程序？
我使用的是CUDA的SIMT，當然是多執行緒，

然後是臨界區和訊號量

臨界區：指的是一個訪問共用資源（例如：共用裝置或是共用儲存器）的程式片段，而這些共用資源又無法同時被多個執行緒訪問的特性

訊號量(Semaphore)，有時被稱為訊號燈，是在多執行緒環境下使用的一種設施，是可以用來保證兩個或多個關鍵程式碼段不被併發呼叫。在進入一個關鍵程式碼段之前，執行緒必須獲取一個訊號量；一旦該關鍵程式碼段完成了，那麼該執行緒必須釋放訊號量。其它想進入該關鍵程式碼段的執行緒必須等待直到第一個執行緒釋放訊號量。為了完成這個過程，需要建立一個訊號量VI，然後將Acquire Semaphore VI以及Release Semaphore VI分別放置在每個關鍵程式碼段的首末端。確認這些訊號量VI引用的是初始建立的訊號量

Linux ls -al

ls -al
檢視檔案資訊
drwx------+  9 zyu  staff    306  8 19 21:15 Pictures
drwxr-xr-x+  6 zyu  staff    204  3 30 22:09 Public

第一列：檔案的型別與許可權
第一個字母代表檔案型別：d目錄，-檔案，l連結檔案，b裝置檔案裡的可供儲存的介面裝置，c表示裝置檔案裡的串列埠裝置，如鍵盤滑鼠等一次性讀取裝置
接下來三個一組，第一組為檔案所有者許可權，第二組為同用戶組的許可權，第三組為其他非本使用者組的許可權
第二列：有多少檔名連線到此節點（i-node）
每個檔案都會將它的許可權與屬性記錄到檔案系統的i-node中，不過我們使用的目錄樹卻是使用檔名來記錄，因此每個檔名就會連線到一個i-node，這個屬性記錄的就是有多少不同的檔名連線到相同的一個i-node號碼
第三列：所有者賬號
第四列：檔案所屬使用者組
第五列：容量大小，預設單位B
第六列：建立或最近修改日期
第七列：檔名

長連結如何轉化為短連結

正確的原理就是通過發號策略，給每一個過來的長地址，發一個號即可，小型系統直接用mysql的自增索引就搞定了。如果是大型應用，可以考慮各種分散式key-value系統做發號器。不停的自增就行了。第一個使用這個服務的人得到的短地址是http://xx.xx/0 第二個是 http://xx.xx/1 第11個是 http://xx.xx/a 第依次往後，相當於實現了一個62進位制的自增欄位即可。

最後講一下單例模式，解釋一下

總結來說，感覺不太好，作業系統和計算機基礎知識還沒來得及複習，所以這些問題都說的很大

第二次電話面試：HR面試

這一輪面試就在扯淡了

首先是自我介紹，談了我自己的專案，

如何理解軟體測試？

測試工具按照測試方案和流程對產品進行功能和效能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執行測試用例後，需要跟蹤故障，以確保開發的產品適合需求。

總的來說，網易的HR面試主要是問一些專案的管理、個人性格、個人和團體的合作態度、遇到問題應該怎麼做等等基本問題，沒有涉及到太多的專業知識