經歷過一些面試,也面過一些同學,
被面試官問到頭皮發麻,也把候選人問得面紅耳赤,

曾怨恨問題刁鉆刻薄,也曾懷疑提問跑題超綱,
經歷過攻守的角色轉換后,沉下心,回顧過往,不由得發出感嘆,如果要將“面試”作類比的話,我愿意將其比作“相親”,
之所以這樣類比,是因為看似客觀的技術面試,其實充斥了各種各樣的主觀判斷,“候選人合不合面試官胃口”可能比“候選人有多優秀”更重要一點,
世界這么大,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://www.uj5u.com/yidong/339196.html
標籤:其他
