【轉】來討論下 Android 面試該問什麼？
來討論下 Android 面試該問什麼？
經歷過一些面試，也面過一些同學。
被面試官問到頭皮發麻，也把候選人問得面紅耳赤。
曾怨恨問題刁鑽刻薄，也曾懷疑提問跑題超綱。
經歷過攻守的角色轉換後，沉下心，回顧過往，不由得發出感嘆。如果要將“面試”作類比的話，我願意將其比作“相親”。
之所以這樣類比，是因為看似客觀的技術面試，其實充斥了各種各樣的主觀判斷。“候選人合不合面試官胃口”可能比“候選人有多優秀”更重要一點。
世界這麼大，Android 知識體系這麼龐雜，我也時不時地懷疑自己，特別是當 pass 一個候選人之後，這種情感愈發強烈。“是不是自己的知識有侷限性？”、“我認為關鍵的問題，真的這麼關鍵嗎？”
帶著這樣的懷疑，我對自己的面試偏好做了一下總結，在此拋磚引玉，歡迎各路大神指點迷津。
ps：本篇僅關注 Android 應用層開發相關面試。
八股文式問題
- Activity 有幾種 launch mode？每一種有什麼特點？
- Service 有幾種型別？各有什麼應用場景？
- 廣播有幾種註冊方式？有什麼區別？
- Activity 有哪些生命週期回撥？
- Kotlin 中的擴充套件函式是什麼？
- JVM 記憶體模型是怎麼樣的？
- GC 回收演算法？
- Java 中有幾種引用型別？
這類問題的特點是“只需百度即可立馬獲得答案”。候選人若做過充足的準備，刷過題，就可以倒背如流。但這些問題也是有價值的，可以快速判斷候選人是否瞭解 Android 的基本概念。
上面的第 6，7 問，我不太喜歡問。原因是“掌握了這個問題對應用層開發能起到什麼可見的好處？”
計算機的複雜度高，分層是常用的降低複雜度的方法，層與層之間形成了壁壘，也提高了層內的效率。將單獨一層的複雜度吃透，都可能要花去畢生的精力。並不是否定深挖底層的價值，學有餘力當然可以打通好幾層，但作為 Android 應用層的面試，重點還是要關注應用層的技術細節。（個人愚見，歡迎拍磚~）
但如果面試中全都是八股文式問題，則不太公平，太過偏袒死記硬背者，也可能因此 pass 掉能力很強，但基本問題準備不太充分的候選人。
原理性問題
這類問題旨在考察候選人的技術深度，在會用的技術上，知道為什麼用它，及其背後的實現原理。比如：
- Android 訊息機制是怎麼實現的？
- Android 觸控事件如何傳遞？
- Android 檢視是怎麼被繪製出來的？
- Android 如何在不同元件間通訊？（跨程序，跨執行緒）
- Activity 啟動流程？
- AMS、PMS、WMS 建立過程？
- 手寫訊息入 MessageQueue 的演算法。
- RecyclerView 快取機制？
原理性問題也可以被百度出來，但可能得多看幾篇部落格再消化一番，最後用自己的語言組織一下，才能在面試中對答如流。
這類問題不同於八股文的地方不僅在於考察了技術深度，還順帶便考察了理解分析能力和總結表達能力。把原理性的東西用簡單精煉的語言表達出來並讓人聽懂也是一種能力。
我不太喜歡問 5、6 這樣的問題，還是之前提到的那個原因，即“回答出這樣的問題對應用層開發能起到什麼可見的好處？”。若是 Android 系統開發工程的面試，倒是很有必要問。
第 7 問將原理性和演算法結合，不是讓默寫演算法，而是在考察理解原理的基礎上的演算法實現能力。若死記硬背原理，通常都寫不出。
專案經歷類問題
這類問題旨在考察候選人專案經歷是否真實，技術棧情況。也可就某一個使用過的技術棧追問背後的原理。
這類問題對面試官要求最高，若是沒有一定的技術廣度和深度，很難就候選人的技術棧問出好問題。
場景類問題
場景類問題是指設計一個“待解決的問題”，讓候選人當場解決。
所有前面的問題，都可以提前準備，若準備足夠充分，全部拿下不是問題。而場景題是無法提前準備的。
- 如圖所示：按住View，移到 View 邊界外後鬆手。這個過程中，哪些觸控事件會被傳遞，它們是如何傳遞的？
- 要做一個 1MB * 10 的幀動畫，有什麼辦法優化記憶體？
- 如何防止搜尋框過度頻繁地發起請求？
- 如何實現彈幕？
- 如何設計直播間禮物佇列？
- 設計圖片非同步載入元件需要注意哪些方面？
第 1 問將原理性問題場景化了，對死記硬背不友好。
這些問題都是應用層開發過程中可能遇到的技術問題，場景類問題是開放性的，沒有唯一解，考察候選人的思路、技術積累及綜合運用能力，甚至是抗壓能力。
但場景類問題也有致命的缺點，受到面試官知識及經驗的限制，面試官見過多少世面，就能問出多少問題。若面試官經驗恰好和候選人有交集則兩情相悅，不然則可能話不投機。所以這類問題也不是公平的，就好像相親，甲之蜜糖乙之砒霜是有可能出現的。
需求拆解估時問題
即把一個真真切切的迭代需求給到面試者，要求把業務需求拆解成技術步驟，然後為每個步驟精確估時。
不要小看“需求拆解”，首先得深入領會需求，能否把產品想表達的理解到位？，能否意會產品想表達而為表達之意？在實際迭代過程中，產品和研發對需求理解的不一致是屢見不鮮的，候選人會不會和產品成為好朋友？
在深入領會需求的基礎上，能否將業務故事拆解成技術步驟？考察候選人掌握的技術棧及其綜合運用能力，技術選型及實現方案是否合理？是否將擴充套件性或效能優化考慮在內？
“估時”可以看出候選人對技術實現細節的熟練程度，假設“用 ViewPager + Fragment 實現分頁框架”的估時是 1 天，那說明雖然瞭解改用什麼技術，但並未實踐過。但此時的估時是理想化的，因為沒有將應用的程式碼現狀考慮在內。
這些問題也是候選者入職之後，在每次迭代時真真切切遇到的問題。“拆解合理，估時準確”不是一件容易的事情，即需要深入領會需求、有豐富的技術棧實戰經驗，還需要對現有程式碼框架了然於胸，這是一個成熟研發的標誌。
沒有找到比需求拆解估時問題更務實的面試題了。若相親的第一感覺不可靠，那就試著約會一次。
總結
我對面試的偏好是按羅列順序遞進的，但水平有限，經驗侷限，對 Android 應用層的面試也只能停留在這個階段。還望掘金大神點撥~
評論裡：
我覺得面試就應該根據簡歷去由淺到深迴圈漸進的瞭解候選人，既然候選人簡歷通過，說明候選者的履歷是符合的，只要把簡歷上面的是真的，那麼技術上基本沒問題。請記住 “由淺到深迴圈漸進”。
轉自：https://juejin.cn/post/7023508547832905758