面試時，問哪些問題能試出一個 Android 應用開發者真正的水平？

01-18

註：
1、是Android應用開發，不是操作系統級移植；
2、做App的；
3、主要是學習能力和人品；
4、你懂的，面試前從網上都會找些面試寶典。。。

這幾年面過的各種Android開發也有三位數了，failed的不敢說，pass的基本都沒有看走眼，來得晚了也想說說我的體會。

一般面試時間短則30分鐘，多則1個小時，這麼點時間要全面考察一個人難度很大，需要一些技巧，這裡我不局限於回答題主的問題，而是分享一下我個人關於如何做好Android技術面試的一些經驗：

面試前的準備

1. 簡歷調查

簡歷到你手上的時候，你要做好充分的調查分析，不僅僅是對公司負責，也是對自己與候選人時間的尊重，明顯不match的簡歷，就不要抱著「要不喊過來試試看」的想法了，候選人也許很不錯，但如果跟你的崗位不match, 也不要浪費大家時間，你要想清楚現在需要的人是有潛力可以培養的，還是亟需幫忙幹活的。另外如果簡歷里附帶了博客鏈接，GitHub地址，相關作品的，可以提前去看看，直接看人家多年積累的文章與代碼，比這短短一小時的面試來得靠譜的多。

2. 準備問題

了解清楚候選人背景後，要根據簡歷，有針對性的準備問題，可以是他作品或做過項目里的某個技術細節的實現方式，也可以是他聲稱精通的某些領域的相關問題。總之不要等到面試過程中現想問題，特別是剛開始面試別人的同學，往往經驗不足稍帶緊張導致大腦短路，其實也是很尷尬的，把要問的問題提前寫下來，準備充分。

考察哪些點?

1. 簡歷是否真實

這其實是面試第一要務，面試的過程其實就是看簡歷是否屬實的過程，因為能到面試環節，說明這個人是符合要求的，不滿足要求的早就被剔除了，如果他真的如簡歷描述的那樣，100%會招過來，如果人人都如此，那就不需要有面試這種過程了。

需要注意的是這裡的真實有三層含義：

一是他如實描述了自身經歷，很多人只在一些大項目里做一個很小的螺絲釘，但簡歷里往往誇張這段經歷。
二是不知道自己不知道，常見於簡歷里各種「精通」開頭的描述，因為知識體系與視野的局限，明明只是了解很淺卻誇口精通，很多時候他並不認為自己說的有問題，而是真的以為自己已然精通，有點井底之蛙的感覺。
三是簡歷里的真實要與你的期望相匹配，一門技術了解到怎樣的程度才算精通，很難有定論，所以這裡的「真實」只能是候選人與面試官標準之間的契合，這種有主觀運氣成分，也許面試官水平不夠錯誤判斷了你，也不用感到不爽，面試何嘗不是種雙向選擇呢。

2. 技術的深度

技術的深度一向是我最看重的部分，當今任何一個技術領域都非常寬廣，一個人要同時掌握那麼多知識並且都深入幾乎不可能，那都需要拼學習效率與工作年限了。而你曾經做過的東西，正在做的東西，是絕對可以了解得更深入的，一個對技術有好奇心，有技術熱情的人，都不會僅僅停留在這個東西挺好用，而是會忍不住去探究它背後的技術原理，即便不是親自去看源碼，也會花點時間了解別人整理過的經驗，所以單憑考察技術上的深度，就可以考察一個人是否對技術有熱情，是否有技術好奇心等等這些很多大牛認為的所謂「優秀程序員的特徵」。

之前曾看到過一句話：「一個人對他所做的事情了解得越深，他就能做的越好」。放在這裡再合適不過了。

3. 技術的廣度

深度是有了，還需要廣度嗎？我個人的理解是：深度是必要條件，廣度是加分項。同樣的有技術好奇心的優秀程序員，也不會滿足於僅僅局限於自己的一畝三分地，工作之餘，也會想要嘗試一些其它的領域和方向，因為投入問題也許不夠深入，但很多領域知識你知道與不知道，對你個人知識體系的形成關係很大。比如你要實現一個功能，在你當前熟悉的技術領域上很困難或者效果不佳，在你就要放棄時你的同事告訴你，這用一個簡單sql語句就可以實現啦，為什麼要搞得那麼麻煩？這個例子雖然舉得很蹩腳，但是我想意思大家應該已經明白了。知識越有廣度，頭腦里的技術體系就越完備，同樣的問題，你就可以想到N個解，思考一下就得出最優解了，如果你聽都沒聽過一些東西，就會經常說出「這個好難搞啊」，「這根本就不可能」，其實有的時候真是知識的局限問題，所謂的從0到1難，也是這個意思。

4. 邏輯思維能力

這也是我比較看重的一點，這裡並不是指那些臭名昭彰的腦經急轉彎問題，而是通過交流觀察，判斷一個人表達觀點邏輯是否清晰，回答問題是否有章法，這個很難描述，但如果你細心觀察，你會發現很容易通過一些簡單的交流，就可以看出一個人是否邏輯清晰。有時候你會覺得某個人表達溝通很不錯，其實不是溝通的問題，是他說出去的話，經過了他大腦的條理清晰的整理，讓你很容易就能明白。這種習慣不是一朝一夕就能養成的，所以面試過程中這點裝不出來。

另外一個人如果邏輯清晰，而且反應又敏捷，語速很快，那是大大的加分項，恭喜你，碰到一個聰明人了。

具體問哪些問題？

前面提到的是要重點考察的點，那麼具體的Android開發，有沒有一些通用的問題可以問的呢？我個人一般會從這幾個角度考察候選人：

1. Android經驗

如果不是校招，Android經驗是必須的，我比較喜歡問一些基礎概念與技術原理，比如Activity、View、Window的理解，各LaunchMode的使用場景，View的繪製流程，Touch事件機制，Android動畫的原理，Handler, Looper的理解，Android跨進程通訊的方式，Binder的理解，Android Mashup設計的理解等等。

2. Java水平

基本上就是Effective Java那本書里提到的東西，如果你背完那本書里的問題，並且對答如流，沒問題，就要你這樣的。其實也會考察關於final用法，反射原理，註解原理，java編譯過程，GC等一些常見問題。

3. IT基礎知識

其實就是計算機科班學生學校里學到的一些東西，在校招時這塊是重點，社招會放寬，但一些基本的常識是要有的，比如不少人都不知道http的get post有啥區別，https的那個s是什麼意思，講不清進程與線程的概念，不知道二分演算法是個啥東西。這些簡單問題的篩選，可以過濾一些所謂野路子的程序員，是不是科班出身不重要，搞這行就得對一些基本常識有概念，不然以後怎麼愉快的交流呢？

4. 代碼質量的認識

我們需要的是一個對代碼味道有感覺的人，關於這點，看下《Clean Code》就夠了，面試中這點其實不好考察，可以讓他聊一聊對代碼質量的認識，雖然不能排除對方夸夸其談，至少想法不多，只能提到命名風格這一點的人是不符合要求的，也可以在寫Code的環節中觀察。

5. 技術視野

比如對Android開發新技術的了解與學習，對其它流行技術領域的了解，這其實與我剛才提到的技術廣度的考察有關，就我面試過程中，發現很多非互聯網行業的從業人員，因為公司各種操蛋規定與公司技術氛圍的原因，技術視野相當狹窄。

我個人對這點深有體會，2011年我還在傳統行業從事軟體研發，當時的公司因為擔心技術信息泄露，不讓上網，相當封閉，我個人雖然自認為已在那個行業內做到業內專家的級別，但總感覺哪裡不對，有一天我很興奮的打算跟身邊同事聊一聊Android的時候，發現他們居然都不知Android為何物？2011年啊同志們，當時的震驚無法言表，深切感覺到需要作出改變了，毅然放棄多年行業積累，轉戰移動互聯網，直到現在。時至今日，多年前的小夥伴也有很多混出了名黨，開始走向人生巔峰，我也從來沒有後悔當初做出的選擇。

6. 技術想像力

一個優秀的技術人，如果知識的深度與廣度足夠，知識已成體系，那麼他對於一些從未接觸過的領域，也是可以做出足夠合理的想像與判斷，面試過程中如果問到一些領域候選人沒有涉獵，這時候一般不用過多糾纏，但如果你想借這個問題考察下他的技術想像力，可以深入下去，比如問他：「你覺得這個東西應該是什麼原理呢？」，「這個酷炫的控制項，如果要你來做，你會怎麼實現？」。在這方面表現出色的同學無疑是有深厚基礎與足夠廣度的人。

7. 技術習慣

好的程序員都會有好的習慣，比如各種快捷鍵的熟練應用，各種命令行的掌握，一些提高開發效率的工具與習慣，碰到問題是baidu還是google，有沒有做一些小工具幫助減少重複工作，工作之餘有沒有繼續學習？有沒有看什麼不錯的書等等，這些小細節很大程度上決定了程序員的開發效率，這也是為什麼很多人說一個優秀程序員抵得上100個普通程序員，這也是重要原因之一。

面試後的反饋：

面試一般不止一輪，你需要給出你的反饋，多輪面試結果一起考量，減少誤判的風險，反饋一般怎麼寫呢？以下是我的建議：

1. 面試紀錄

面試過程中的完整紀錄，盡量客觀評價，讓其它面試官知道你問了哪些問題，回答的怎麼樣，也避免了重複問題的尷尬。

2. 優點與缺點

你的主觀評價，亮點有哪些，你覺得哪些地方不夠好？

3. 綜合評價

你對候選人的綜合評價，hire或者no hire的根本原因，如果有些地方感覺沒考察清楚，期望其它面試官繼續加強考察，也可以寫上。

4. 怎樣才給通過？

通過標準因人而異，每個人都有自己心中的bar, 但還是有些可直觀考量的因素的：

一是崗位的要求，不同的崗位標準當然不一樣，校招與設招肯定也不一樣。
二是崗位的緊急程度，兄弟們天天加班忙死了，趕緊找人過來幫忙吧哈哈。
三是候選人的年齡，大齡程序員莫怪，一把年紀了還跟剛畢業一兩年的同事一個水平，說明成長太慢，做技術的潛力有限，這個大家應該能理解。
四是前面提到的做技術的深度，這個是必須的，廣度也要有一些，視野不能太窄。
五是要有亮點，大家在面試的過程中要注意發掘亮點，有時候他問題很多但有一個足夠的亮點也夠了，用心觀察也發現不了什麼亮點的，就要注意了。

說了這麼多，其實最重要的就是一句話，問問你自己：你真的原意跟那個傢伙一起並肩戰鬥嗎？

我最近運營了一個微信公眾號AndroidTrending，主要專註Android最佳實踐，經驗分享等，大家有興趣的歡迎前往關注，我會定期更新一些開發經驗到上面。

http://weixin.qq.com/r/6kxxaWbEHztgrSIK9xn4 (二維碼自動識別)

首先，面試官們一定要知道，每個人由於經歷不同，擅長的方向是千差萬別的，所以一定不要抓住自己擅長的某個方面去問的很深，覺得「如果連這個都不會還算毛程序員啊」。

所以我問問題的時候，往往是「兩步走」的循環：

1. 問他做過什麼，如果有成品的話，我能看看更好。

2. 從他做過的東西裡面，找到問題進行提問。具體的問題要看情況，可以是界面或效果的實現方式、相關bug的排除、該部分原理的分析。

舉一次面試時的對話作為例子吧：

我先開始：

「這份簡歷和網上投過來的那份是一樣的吧？」

「嗯，應該是一樣的。」

「嗯好。你在之前的團隊的位置是什麼？」

「中高級吧。」

「具體的工作呢？」

「寫框架，讓新人比較容易上手，能夠輕鬆工作。」

「你說的框架具體包括什麼呢？」

「一些會共用的東西，寫出來可以讓新人就算是剛來也能很好的完成工作。」

「聯網是你封裝的嗎？」

「是。」

「你們聯網用的是什麼？」

「就是……安卓自帶的……HttpClient。」

「直接用的？」

「嗯。」

「那你們的網路請求是怎麼做的非同步呢？」

「嗯……用Handler嘛，還有AsyncTask。」

「能具體一點嗎？」

「嗯……就是……額……」

「例如什麼情況下用Handler，什麼情況下用AsyncTask，你是怎麼決定的呢？」

「嗯……」

「或者說，他們有什麼區別呢？谷歌為什麼要造他們兩個出來，而不是只造一個呢？」

「區別……區別……他們肯定是有區別的，不然谷歌不可能造兩個。嗯……」（到這裡，這個問題就可以結束了。評級減一。）

「這樣吧，你的簡歷上提到『熟悉大圖片的載入』，能說一下大圖片載入有什麼需要注意的嗎？」

「緩存嘛。」

「緩存？」

「嗯，大圖片的載入不就是ListView裡面的大圖片載入嗎？要防止內存溢出。」

「ListView裡面一定是大圖？」

「嗯……」（不了解的東西卻說自己熟悉，評級減一。繼續順著問。）

「那麼ListView中圖片的緩存你是怎麼做的呢？」

「三級緩存嘛。」

「哪三級？」

「如果內存裡面有，就用內存裡面的；如果沒有就用本地的；如果本地也沒有就從網路上取。三級。」

「網路上的也叫緩存？」

「啊。你可以把他看作緩存，也可以不看作緩存嘛。」（這個……）（最近收到的簡歷看到很多說自己熟悉三級緩存的，於是我在網上搜了一下，終於找到「三級緩存」的出處了：android中圖片的三級cache策略（內存、文件、網路）原來是 @singwhatiwanna 寫的，難怪這麼火。不過他在文中提到了，「其實網路不算cache，這裡姑且也把它划到緩存的層次結構中」。）

「內存緩存你是怎麼實現的？」

「用的一個HashMap。」

「直接用的HashMap嗎？」

「嗯……嗯。」

「直接用HashMap的話，怎麼防止你剛才提到的內存溢出呢？」

「你可以用軟引用嘛。」（首先答案有問題，另外當聽到關鍵詞「你可以」，多數情況下這個問題也可以結束了——八成是不會，僅僅聽說過。不過出於謹慎還是繼續問了）

「軟引用就能防止內存溢出嗎？」

「還有……還有谷歌出的一個叫LRUCache的。」（迴避正面回答，確認他是不會。這個問題結束。評級減一。到此就再沒必要聊下去了。）

然後簡單過渡一下，就結束了面試。

所以你看，只需要簡單提問，然後接著對方的回答繼續往深了問，就什麼都問出來了。

--------------------------------------------------------------------------------

評論中有人問到這次面試中我沒有問完的問題的答案，那簡單就說一下，想了解更多還請自行谷歌。

Handler和AsyncTask：這倆類都是用來實現非同步的，其中AsyncTask的集成度較高，使用簡單，Handler則需要手動寫Runnable或者Thread的代碼；另外，由於AsyncTask內部實現了一個非常簡單的線程池，實際上是只適用於輕量級的非同步操作的，一般不應該用於網路操作。（感謝網友指正，AsyncTask 通過重寫的方式是可以用於長耗時操作的，而我只考慮了直接使用的情況就說它不適合網路操作，是不對的。）我問他Handler和AsyncTask的區別，一方面是因為他說用AsyncTask聯網，因此我認為他對AsyncTask並不熟悉；但更重要的是在我問他實現非同步的具體手段的時候，他同時提到了Handler和AsyncTask——用這種「混搭」的使用方式來寫聯網框架，就算不考慮AsyncTask的可用性，也顯得非常怪異，這聽起來更像是在「列舉Android實現非同步操作最常用的類」，而非「講述實現網路非同步操作的具體方式」。也就是說，我聽了這句話後開始懷疑他封裝過聯網框架這件事的真實性。但我只是懷疑，並不確定，因此接著問了我想問的。

圖片緩存：大多數情況下，內存中使用LRUCache是最合適的。如果用HashMap來實現，不是不可以，但完全沒必要嘛！需要注意在合適的時候釋放緩存。至於具體怎麼釋放，我沒考慮過，但用軟引用的問題在於，你很難控制緩存的大小，也就是說，只有等到你的內存快要撐爆，你的圖片緩存才會被回收。是不是感覺傻傻的？（經網友指出，LRUCache 的內部實現就是用的 HashMap。由於我沒有讀過 LRUCache 的源碼不知道這點，在評論里被大家罵慘了。）

對於初級和中級工程師，我更傾向於考慮對方的學習能力，也就是你對於自己所做過的東西是否足夠了解，而非要求你那裡都強，因為就像我開頭說的，每個人由於經歷不同，擅長的方向是千差萬別的，我不喜歡挑別人的軟肋問。只要你學習能力強，我就安全感滿滿噠！

至於高級工程師么……我還沒面過吶！^_^

各位給的問題我基本上都不會回答！我找到了一個很厲害的android妹子，問的時候啥都沒問出來，然後就讓她上班了，沒想到非常厲害！

1，讓他描述一個曾經解決的最難的問題

2，如果他沒遇到過難的問題，就給他一個難問題，看他如何思考。

3，他的產品觀。

其實第3點非常非常重要。

所有技能都可以學，但是看法和視野需要太長的時間來訓練。

提供幾個供參考：

1. 什麼是ANR，如何避免ANR。

2. 什麼是FC？如何避免FC的發生，另外FC發生時如何捕獲相應的uncaught exception？

3. Asynctask的優缺點？能否同時並發100+asynctask呢？

4. Handler有何作用？如何使用之（具體講需要實現什麼function）？

5. 有哪些實現自定義控制項的方法？

6. CMWAP, CMNET有何區別，網路通訊時是否要特殊處理？如何切換接入點？

7. 能否講講你用過的adapter？

8. 已經發布了軟體版本A，使用sqlite存儲用戶數據其DB version為1包含某張表T1，則其後需要發布版本B，在版本A的T1表結構的基礎上又增加了2個新的欄位，則能否在保存用戶已經安裝的版本A的數據的前提下，更新安裝新版本B？

9. 你怎麼看待在android上面應用MVC框架，是否有必要抽象獨立於activity的C？

10. 各種基礎問題--側重考察熟練度，例如有幾種在activity之間切換的方法？能否描述一下android平台的framework的層次結構？etc。。。

11.直接問候選人你準備下面讓其開展的工作的內容，問問他會如何實現？大概需要多少工時？

12. 最關鍵的還是候選人的學習能力基本功，介個多花點時間和候選人溝通，深入的討論一些技術問題相信你自會有結論的。

題目神馬的都是浮雲，看他做過的項目，界面，功能再問幾個原理上的問題就能看出他的能力啊。

聊下我面 Android 開發的時候的基本過程吧。

1. 先談談最簡單的東西，包括不限於：最基本的 App 生命流程，Context 的理解(Application Context 和 Activity Context 異同), ANR 處理，BitMap 和 OOM 的處理，函數調用Trace 怎麼玩，客戶端怎麼請求網路等等。

2.聊聊項目，讓對方描述下做過的項目裡面的自己覺得最有印象的一到兩個點

3.如果覺得不錯，就給一個小作業，一般是不超過2小時就能做完的東西，比如做個簡單的小遊戲（貪吃蛇，掃雷）會給予一些資源圖。允許上網，允許帶回家完成。

「怎麼理解Activity和Fragment的關係？」

別笑，這只是一個基礎的問題，但是許多Android開發都說不清楚（說錯，很多人以為Fragment就是一個輕量點的Fragment，或者一個重量點的View…）。

或者說，要說清Activity和Fragment的關係，涉及到多方面的知識和經驗，這得在基礎牢固的前提上，加上相關Fragment的使用經驗，才能比較準確得回答這個問題（吧）。

activity fragment loader 以及動畫框架的缺陷

沒有這樣的問題。建議你給他一個作業試試

感覺大家更多的是從拷問第三方應用開發者的角度來看。

我稍微補充一句吧，系統應用開發的話（比如phone app），絕大部分時候，對某些模塊的流程和結構的熟悉和理解程度，遇到問題對root cause的定位精度，是比具體的某些控制項如何使用等等更加有意義的。

直接上白板手寫程序。本座的題目是一個非常簡單的演算法：從一個字元串中剔除連續的字元，只留一個。

條件寬鬆，系統庫的API記不清也沒關係，意思到了就行了。

如果能寫得出來（令人驚奇的是，大多數人連這樣簡單的程序都是寫不出來的，包括許多簡歷上自稱N年工作經驗的面試者），再對著寫下來的代碼追問幾個基礎問題，比如演算法複雜度，內存分配／泄漏之類。

就這招，可以刷掉90%的不合格者。這超級初哥的一道題，能看出的問題太多了：

－寫不了代碼濫竽充數的直接就刷掉了。

－有的面試者彎彎繞，想各種複雜設計和演算法，最後毛都寫不出來。這種面試者一般都是眼高手低的破輪子重複製造者。刷。

－程序是寫出來了，但對平台基本的運行機理無概念，不知道內存是怎麼分配的，什麼是指針什麼是值。知其然不知其所以然，刷。

－有次來了個程序員，平台是Objective C，但他堅持要用純C寫。問他你能用Objective C和NS庫寫一下嘛？執意不肯，堅持C是最好的，看不起Objective C。那你來搞什麼iOS開發？技術認識有問題。刷。

本座面試是招iOS開發，但這對各種平台的程序員都適用。

從面試著者的角度，應該是基本的知識，加學習能力和技術發展的嗅覺！

1. Java基礎和Linux基礎(Ubuntu或者Mac)

2. Android

多線程編程(AsyncTask以及Java thread的使用)
ANR三種類型(activity timeout, service timeout 和 receiver timeout)
AlarmManager以及Wakelock的使用
HTTP以及Parser的使用
Android內存泄露的類型(Java Leak和Native Leak)
SQlite數據的使用
NavigationDrawer，PageAdapter等UI模式的使用和定製
自定義view控制項以及自定義屬性的使用
Logcat以及DDMS的使用
Exception的調試(Java exception和Android exception)
測試相關 (Java Unit和Android Instrumentation)

3. 設計模式 (MVC以及MVVM在Android開發中的使用)

做過面試的都知道,其實面試官也是挑自己會得東西問別人,再牛的人也不是什麼都知道的特別清楚,但是重要的是能夠想出大體的思路,解決方法,主要看項目,如果一個面試我的人問我一大堆基礎的問題,會選擇鄙視他,直接離開,因為那是校園招聘面試的水平..

關於新API的了解程度（FingerManger等），listview優化（至少說出2種），聯網機制，斷點續傳，緩存機制，回收機制等...

我是新手，勿信...

在以前的項目或者產品中，有沒有讓你特別有成就感的一件事？詳細說說。

在以前的項目或者產品中，有沒有遇到特別棘手的問題？難點在什麼地方？如何解決的。

關注在每個公司工作時間的長短。

從上家公司離職的原因。

talk is cheap, show me the code

1. Java 水平是基礎

2. 成功案例

3. 對Activity和Intent的理解

這三個足夠開發應用了

Just shut up and show me the app!