美女學姐面了美團阿里京東，這些經驗實在太真實了

很真實的經歷，美團阿里京東全都嘗試過，希望對你們都有幫助

近一個多月 斷斷續續參加了一些校園秋季招聘，仍未上岸，

記錄近段時間的反思共享，

（時間順序）

【美團基礎研發部門-測驗開發崗(功能測驗，測驗平臺研發，白盒測驗等)】第一次面試

1. 自我介紹
2. 介紹實習作業
3. 印象最深刻的線上問題以及解決方案
4. StringBuffer和StringBuilder的區別
5. Java悲觀鎖Synchronized和lock
6. http和tcp區別
7. http請求有哪些
8. Linux查看日志資訊，查記憶體
9. 演算法->整型有序陣列，只有一個已知的有重復單元，找到第一次出現的下標(思路：二分查找)
10. 資料庫->表(id，姓名，借閱書籍，借閱時間)查找確定7天的借閱記錄，按id排序，

[反思：

1. 大大方方的自我介紹，來自哪里，叫什么，學校&專業，校內測驗實踐，實習作業(無則空)；這些經歷讓我對測驗作業和技能有了更多了解并認識到了自己的不足和提高方向，如果有機會加入該團隊會提前了解作業內容和需要，并做好準備，
2. 由上引出關于實習的問題(或校內實踐)，此介紹個人實習->功能測驗為主，校內學習的自動化框架和測驗工具輔助測驗，回答此問題時介紹了測驗的業務系統以及服務物件，提到了要根據不同的測驗場景選用對應方法，同時除了熟悉業務的黑盒邏輯還要多多了解業務的代碼邏輯，
3. 由上引出一個線上問題(即bug)怎么排查解決，①嘗試復現②關注資料流的各個階段，前端互動，http請求介面，后臺java api介面，資料庫③梳理代碼邏輯和資料來源(來自sql資料庫還是mongo或redis快取，還是通過多個資料庫的拼湊資料)
4. 串聯知識點StringBuffer&StringBuilder區別，除了各自應用場景一定會說到執行緒安全，引出保證安全的鎖機制，
5. Linux查看日志的程序

cd 指定目錄(一般最后一級為logs)

ls 此命令會顯示出這個路徑下的各個日志檔案

cat 檔案名(靜態查看檔案內容)

tail –f 檔案名(動態查看日志)

【在面試官讓列舉知道的Linux命令時不妨以此場景說出多個命令】

]

【阿里菜鳥部門-測驗開發崗(功能測驗 黑盒&白盒 資料分析等)】電話第一次面試

1. 自我介紹，與上答的一樣，
2. 實習作業，與上答的一樣，
3. 實習時接觸的系統或作業有什么不好的地方嗎？怎么改進，感覺跑偏了答的系統架構，前后端分離什么的，完全不會 其知識點也不屬于自己的能力范圍；反思認為，應該說自己應該從多方面熟悉業務系統(黑盒 白盒邏輯等)同時提高測驗的作業效率，測驗也作為敏捷開發周期的一部分其效率也影響到整個專案的進度，
4. 看過什么原始碼嗎， ……
5. 最近看什么書嗎， ……
6. 反問環節
   1. 系統優化那個問題我該怎么答，

面試官：具體我也不清楚，但我想知道你自己去了解的東西以及去思考的東西，而不是聽別人說的，

1. 1. 我沒有什么開發經驗，了解的到測驗與測驗開發的區別是測驗開發會開發一些測驗工具并以白盒測驗為主？是嗎，還是有什么區別呢？

面試官(反問)：我看到你簡歷上寫的完成過一些UI和http介面的測驗框架，為什么說自己沒有開發經驗呢？其實測驗開發與測驗都是要結合具體的業務場景的，而測驗開發更注重于什么測驗場景選用什么測驗框架的工具，有時候也會自己mock&stub介面來進行測驗的，

[反思：

其實上面也寫出一些反思了，阿里的這一面雖然涼的明顯但給了我極大的啟發和自信，我一般在面試時總會找機會提一下自己沒有實際的開發經驗，但其實所謂“開發”并沒有多么高大、遠不可及；軟體開發時也是利用程式去梳理業務邏輯，關注訊息的同步，資料的增刪改查，關注記憶體的使用，CPU的利用效率，利用介面鏈接與前端互動等等，這些都是基礎知識的應用實踐，測驗也需要具備開發技能，但我們的開發技能會更多關注測驗的框架和技術，這兩者是互通的，

而原始碼的學習又會帶來什么呢？能幫我們去理解JVM記憶體的管理和調度，那些學習的理論也正是源代碼的體現，

而由原來李老師給我們看的美團lego介面測驗平臺發現了美團的技術交流網站

tech.meituan.com

里面有篇文章寫道，程式員在復現BUG時發現問題代碼沒有日志，想加上日志再復現卻擔心重新啟動會破壞執行緒池等因素，而如果深入了解原始碼便可以解決此困難，文章介紹了阿里團隊研發的開源框架用于解決上述問題，

秋招面臨的對手來自很多很多優秀的大學，他們比我們起點高且優秀的原因時人家曾比我們效率高，反思的更快，跑的更遠，而當我們一起去試水秋招一起競爭的時候我們也并非毫無優勢，很多崗位其實我們的能力也絕對能夠勝任，這20年我們也經歷過很多有益的事，也學過見過足夠的世面，我們需要反思、需要思考如何把自己有的東西更好的表達出來，讓面試官聽到 我們對已有知識的深刻反思以及能夠打動他們的事，

]

【美團基礎研發部門-測驗開發崗(功能測驗，測驗平臺研發，白盒測驗等)】第二次面試

1. 介紹實習作業 (負責的四個系統及業務，給誰使用；根據不同的測驗需求采取不同的測驗方法[手工?自動化?框架輔助等])
2. 怎么看待測驗作業(研發負責實作抽象的業務功能；產品負責梳理需求做出需求檔案；測驗介于兩者之間即需要關注代碼邏輯和黑盒的業務功能 正向反向的去設計測驗驗證，同時也需要關注產品的業務容錯率，同時應當結合所在團隊的應用框架、組件技術等設計相應的測驗，如：前端Vue技術的雙向系結特性能夠讓表單輸入通過Js代碼利用”formdata.Name=”填寫；由于實習所在團隊沒實作前后端分離而又由于前端頁面相對固定，研發系統實作前端代碼的封裝應用Json串來操作Java代碼實作配置，由此反思，對所測系統的代碼邏輯，應用技術深入理解會對測驗作業有利，)
3. 怎么理解測驗和測驗開發(認為兩者都需要具備代碼能力，但認為除了業務測驗外測驗平臺的開發是由測驗開發崗的人做的)，面試官：測驗開發是由測驗成長起來的，從業務測驗入手，能在不同的測驗場景應用相應的測驗框架和方法，同時測驗開發需要還需要具備一定的產品思維，對產品需求提出建議，
4. 實習的測驗團隊有什么不太好的地方嗎(研發承擔了過多壓力，實習的測驗流程為需求檔案交付測驗和開發，測驗設計用例并熟悉業務，研發投入漫長的開發，待開發完成后介入測驗，認為測驗需要提前介入，除了了解黑盒業務外在開發程序中提前了解改造的介面和代碼邏輯，梳理開發的上下游依賴并判斷測驗時是否需要提前做依賴的mock以及mock部分的回歸驗證，應實時了解研發的進度、困難點和暫不處理的地方這些地方會對應到bug的掛起等相應狀態， 同時在此討論測驗人員的代碼權限以及bug的定位問題<->測出bug研發不改的問題 bug不改是指bug確認為需要處理的bug但研發不予處理，此有兩種可能①需求更改沒同步給測驗人員bug無效②bug優先級低且研發認為不影響主要功能，其根本原因是bug在上線截止日期前改不完且bug的修復代價很大，這時如果測驗人員能協助定位到每個bug的更多資訊，或者提供一定程度上的bug解決方向，便會使研發修復問題的效率提高，實作這點需要測驗人員更多的了解、理解開發人員的作業，去分擔研發的壓力)，
5. 學校學的測驗和實際的測驗作業有什么不同?(沒有不同，只是實際的測驗與自己之前對測驗的理解有不同，校內實訓的測驗業務場景和邏輯比較簡單，以保證自動化等測驗技術的實踐；而實際的測驗業務十分復雜，不會很容易的把一個有價值的模塊單獨提煉出來設計自動化測驗，但測驗作業需要嘗試應用一些自動化技術來起到輔助的作用，還有資深業務測驗人員會把許多歷史遺留問題及時記錄并及時在新的業務開發后驗證該問題是否升級，還會根據不同的業務場景帶入不同的用戶角色來設計測驗，這些也都是有理論支撐的[探索測驗]，如果我作業及時反思并與所學的知識結合起來 會 讓自己更快的成長，)
6. 代碼題：給定兩個字母組成的字串，去除第一個字串中含有的第二個字串的字母，并將結果按字母字典序輸出，(思路利用set集合給第二個字串去重，兩個遍歷，結果再用排序演算法)
7. 測驗代碼
8. Java8個基本型別
9. 說出Java5個例外
10. 反問：由于之前發現了tech.meituan.com問了面試官美團Quake全鏈路壓測平臺的一些問題，

[反思：

還是前面那句話，我們很多經歷過的東西都值得思考和總結——實訓的測驗框架每個模塊都有很多值得深入學習探索的價值(資料驅動怎么結合業務場景應用?監聽器有很多種型別可以實作用例的調度和選擇執行等)，實習的再平常再機械的作業也有很多哲理值得總結(很多迭代里沒修復的問題根據什么理論知識記錄的?怎么與產品研發溝通?測驗資料的協調等)，

同時這些反思要怎么謙虛且流暢的表達給面試官

]

【京東云產品研發部門-測驗開發工程師(無界面的后臺介面測驗 對應 資料庫的增刪改查)】-初試

1. 自我介紹
2. 實習作業
3. Bug生命周期
4. 生命周期“掛起”狀態誰來處理

【京東云產品研發部門-測驗開發工程師(無界面的后臺介面測驗 對應 資料庫的增刪改查)】-復試

1. 資料庫：A表(id),B表(id)查兩個表共有的id->連接查詢&子查詢
2. 一個web界面只有一個按鈕，點擊按鈕后，http請求回傳200，但界面出現error彈窗，怎么排查是前或后端的問題，(可能前端沒有正確的封裝后臺需要型別的引數；也可能是后臺捕獲的代碼例外處理時回傳了200，斷定問題需要查看程式日志并關注上述的代碼邏輯和運行情況)
3. 后臺的一系列介面，對應到資料庫的增刪改查邏輯，怎么測驗?
4. 判斷測驗的兩個系統是否屬于一個網路
5. Switch陳述句和if else陳述句的區別
6. 介紹Java集合set，list，map
7. 一個頁面六個輸入框怎么測驗
8. Linux grep命令使用

[反思：

被我忽視的兩次面試，由研發組長和系統架構作為面試官，在我回答測驗相關的問題時并沒有足夠的耐心聽，但有時候我們需要適應不同的面試官和面試場景，此時應提煉簡化自己的回答，

]

【美團基礎研發部門-測驗開發崗(功能測驗，測驗平臺研發，白盒測驗等)】第三次面試(終)

1. 介紹一個自己遇到的最具有挑戰的問題
2. 這個問題設計的業務場景能否用UML圖畫出來
3. 21層樓6臺電梯設計一個電梯調度程式實作電梯的調度使用，考慮多個場景，抽象出類和具體的屬性方法
4. 快排的思想，時間復雜度，這個時間復雜度怎么算的，如何計算時間復雜度
5. HashMap查找的時間復雜度，如何查找的
6. Java集合有哪些？set和list區別？

[反思：

……

最終倒在了京東云和美團的最后一次面試上，這是一段極其折磨人的經歷，

試水秋招期間

記不清這次準備是第幾次回顧：

三次握手，四次揮手；tcp/ip tcp udp http ip https，http請求方法，post&get區別；osi七層協議(以及為什么常問七層協議)及各層之間的作用；url決議程序；長連接&短鏈接；死鎖條件；擁塞控制；流量控制

終于進一步搞清了：

JVM垃圾回識訓制和分代回收演算法；hashmap hashtable concurrentHashMap的區別以及jdk1.7 1.8concurrentHashMap的執行緒機制變化；執行緒同步的方法以及方法的原理(樂觀鎖，悲觀鎖，volatile關鍵字)；執行緒的狀態和執行緒池調度以及創建執行緒的程序，

Sql的索引、兩種引擎

吸取實習面試經驗：

刷了一些leetcode易中題型，幾種經典演算法題如：約瑟夫環，topK（堆排序）等

最終反思：

1. 面試的幾輪難度和層次是遞進的，如果一次面試后發現自己的所有能力點都被挖掘要及時警惕及時反思，為下一次面試做足準備
2. 要把理論與實際要面臨的作業結合，有助于分清楚知識點的主次
3. 許多知識點和考點也是需要迭代學習的，每次學習會有新發現，會更接近與實際的應用，而把知識點掌握到能夠應用到實際->我認為是修煉的終點
4. 知識點是有限的，但對知識點的挖掘是無限的，但會有終點的，
5. 秋招不易，考研也不易，祝福大家堅持到底，也祝上岸的同學一切順利，
6. 總還是會有一些運氣成分和一些無法改變的東西影在響最終的結果，把握好自己能把握的，最侄訓上岸的，
7. 以上純屬個人見解，修行不夠，繼續努力，