給公司面了一個10年經驗的Android開發，心態崩了-有解無憂

部門最近專案很多，在擴招，面了不少android程式員，結果竟然沒有一個合適的，

偶然看到一份，10年作業經驗，做過各種Android開發，精通各種技術的簡歷，看著還比較合適，于是聯系過來面試了，

說實話，當人事把簡歷遞到我面前的時候，我稍稍的驚呆了一下，這個作業經歷比我長一倍的“大牛”，要知道面試他的是我這么個中級的開發，會不會鄙視我，以至于鄙視我們公司，我們公司只是一個普通的上市公司，跟一線互聯網公司相比還是差遠了，但是我還是很有公司榮譽感的一個人，

所以，我先給自己定了幾條：

不能問一些簡單的弱智白癡問題，必須要有深度，絕對不能讓“大牛”感到：“面試官的問題很Low！”的感覺，
盡量少說話，不然萬一問了“大牛”一個問題，“大牛”回答后，反問我一個，我回答不上來，那更糗，
還有幾個，當時想出來的，現在想不起來了，

面試程序：

我：簡述Handler訊息機制，

“大牛”：嗯？

我：就是說一下Handler發送和接收訊息的實作，尤其是Message的訊息載體的作業流程，

“大牛”：這個，額，不太清楚，，，

我：（趕緊換一個方向）Service和IntentService有什么區別？

“大牛”： Service和什么？

我： IntentService，

“大牛”：沒用過，，（他開始有點不好意思）

我：（哦，沒事，這個可能確實太冷門了）那Service和Activity之間的通訊怎么實作？

“大牛”：這個，通信，額，你指的是？

我：就是傳值，比如Service里面某個后臺任務結束，怎么通知當前活動Activity，并且把結果傳遞出去？

“大牛”：哦，這個，啊，想想，，，沉默10s后，，，

我：額，比如用廣播的方式？（我都尷尬的主動給了他一點提示）

“大牛”：哦，對，廣播，Broadcast之類的，

我：那還有其他方式嗎？

“大牛”：嗯，廣播，額，，，（又是10s后）比如？

我：介面回呼，，，（算了不糾結這個，他知道廣播，那順便問個這個），那Context 的sendBroadcast和LocalBroadcastManager 的sendBroadcast有什么區別？

“大牛”：這個沒聽說過，，，，，，，

后面的問題，我從MVP、MVVM等流行結構框架問到多執行緒同步，然后再問點擊事件分發，到自定義View，再聊影片效果實作，基礎的ArrayList、HashMap底層實作，final static關鍵字用法，進階的設計模式里面單例模式和觀察者模式的實作，java類加載、記憶體分配，他沒有一個問題能確確定定的回答出來，要么“不知道”、“沒用過”，要不支支吾吾的說不出個123，

哦，對了，聊的程序中，他反復說自己用過什么什么第三方的庫顯得自己很能干，

我問他：有沒有開源過什么自己寫的庫？他說沒有，那我問他：讀過ImageLoader的原始碼嗎？ImageLoader的本地快取機制是怎么實作的？他說不知道，我告訴他，你說的所有的庫，我都用過，并且絕大部分我都看過原始碼實作，另外，像ImageLoader、Pull2RefreshListView這種庫，我作業兩年后就自己實作過簡易的版本，還分別做過擴展，

最終最終我確定這個所謂的10年作業經驗的“大牛”，就是網上那種“一個經驗用了N年而不是有N年經驗”的人，

回過頭我又仔細看了看他的簡歷，10年程序中，這個人換了8家公司，最長的一家呆了不到2年，最短的半年就不干了，簡歷里也沒有自己獨立完成過的專案，簡歷上大部分所謂的Android專案，全部都是基礎控制元件的簡單羅列，沒用過設計模式，沒用過分層框架設計，跟我第一年參加作業寫出的東西一個鳥樣，

在這次面試后期又面試了幾個人，說實話都不盡如人意，這些面試者都有一個共同點：任何他們知道的知識點都是停留在知道、用過的層面，具體實作和怎么擴展優化都答不出來，

再想想這兩年都在說Android開發飽和，我感覺這個說法有欠缺，飽和的是這種初級安卓開發，會簡單的頁面實作，但程式可擴展性和維護性，欠缺考慮，框架結構設計缺失，（當然不是說代碼必須按照條條框框的寫，而是說在合適的地方用合適的方法，某個地方明明一個方法函式就能解決，后期沒有什么需要擴展的地方，那你非得按照JAVA面向物件思想，寫一個類物件，再用個設計模式一框，那就舍本求末了，

我感覺我現在依然徘徊在中級工程師級別，由于各種原因，比如家庭等等，我學習的時間也感覺比剛作業的時候少了好多，精力也差好多，一想到這些，就有種念頭：我可能永遠也達不到那種網上動輒能碼出10000 star開源庫的大牛，或者隨手寫個深入透徹的解惑答疑的技術博客就有N個評論和轉發的神人，所以我又有些動力，努力學習下去，這些人才應該成為自己的目標，

下面我從面試官角度來分析，在面試程序中的對候選人一些考查點吧，知己知彼百戰不殆，面試程序中逆向思考一波，有助于我們怎么應對技術面，

候選人人設是否跟簡歷一致

主要看候選人是否坦誠真實，這個會直接影響能不能通過，候選人上的專案經驗和技能點應該盡可能與候選人匹配，比如說，候選人說做了XX專案，但是問起是怎么實作的，卻答不上來，或者說熟悉xx技能點，卻只會呼叫常用的api，對其原始碼細節一點都不熟悉，那多半是不給過的，如果候選人要吹牛B，能拿出能圓上吹牛B的實力，也是可行的，比如說某某模塊其實是你同事做的，但是你也完全理解了，可以應答如流，面試官是不會計較的，

技術的扎實程度和專案經驗匹配程度

考查包括對技術的理解和解決問題的能力，包含一些細節，運用的場景，實作的原理等等，目的是為了測驗候選人技術水平上限，答得越清晰，越深入，對細節掌握越牢靠越好，不一定需要全部答出答完美才能拿到offer，但這些題回答的效果最能影響到offer能談多少錢，小廠偏重于技能、專案經驗匹配度，大廠偏重于基礎、原理，小公司，面試官通常希望候選人盡快上手，就希望候選人有類似競品或者功能開發經驗的候選人，所以也可以從這些方面做準備，大公司呢，可能會提出一些場景來考查候選人怎么設計，這就要求候選人功底深厚，邏輯嚴謹了，上面的題集我沒寫答案，因為我覺得很多題本就沒有標準答案，也沒有必要背題的“標準答案”，優秀的回答，應該是形成自己的理解輸出的，說的有理有據就行，

候選人亮點、優勢

一般是作為候選人的加分項，或者是面試官為了更快的打開話題，了解候選人的優勢，并測測候選人的優勢到底屌到什么程度，這個問題回答好了，候選人甚至能翻盤，

溝通能力

在一線搬磚過的應該都懂，每天正正經經寫代碼的時間通常不到一半，還得花不少時間跟產品撕，跟后臺撕，跟UI撕等等，所以溝通協調能力也是很重要的，候選人需要理解面試官出題意圖，表達要邏輯清晰，最好是候選人能跟面試官建立起討論技術的氛圍，這方面很容易被多數候選人忽略，但其實挺重要的，面試官也許不能直接決定要你，但是一般可以直接決定淘汰你，候選人要不卑不亢，保持謙遜，候選人技術再屌，態度傲慢的話，也是很容易翻車的，但也不能太慫，顯得沒有技術底氣，所以最好是和諧的討論氛圍，

學習能力，自驅性

一般總監或負責人會比較關注這個，

答會的問題

要聽明白面試官的出題意圖，也就是注意審題，不要答非所問，如果對面試官提出的問題不是很理解，及時進一步溝通，把問題問清楚，這也體現了溝通能力，畢竟平時作業時，也會接到一些不是很清晰的需求，自己主動獲取更清晰的需求也是程式員的優秀素質，

回答要盡量清晰準確，最好能答到問題的本質，展示出你對技術的更深層次的探索和挖掘，同時要注意面試官的反饋，這時候就要察言觀色了，

如果面試官聽的津津有味，并不斷追問加大問題難度，那么恭喜你，你回答的很好！

如果面試官表現得有點不耐煩，那就精簡下回答，畢竟面試時間有限，去掉那些啰嗦的話和題目關聯不大的東西，

如果發現面試官問的題越來越簡單，越來越常規表面，那么就得警惕下了，可能是你之前的回答太一般，讓面試官覺得你比較菜，所以就不給你出難題了，這種情況就算最后給到offer，多半價格也談上不去了，甚至還可能是為了給你個臺階下，然后讓你回家等遙遙無期的通知了，這種情況下就得把問題回答得更深入一些了，知道多少答多少，盡可能主動展現出自己的水平來，

答不會（不確信）的問題

首先要對這個問題有一定的思考分析，不要輕易的說不會，但也不能完全不會還瞎答，完全不會的還是要敢于說不會，坦誠也是必要的素質，

如何思考分析呢？以我的經驗來看，主要是從問題的關聯知識或者可替代方案的角度來思考，對問題不是很清楚了解的時候，嘗試從已知的相關聯的知識點來做出合理推測，比如從一些開源庫里面借鑒思路，或者從Android原始碼里面借鑒思路，但是這種情況就得跟面試官說清楚，你是推測的，還要說下為什么要這么推測，避免面試官誤以為你不懂裝懂，還有一種方式，就是你也提出一個可替代的能解決問題的方案，