為什麼要重視專案介紹？
你可以嘗試著講一遍你的專案經歷。我第一次講的時候就挺亂的，卡殼、專業詞彙匱乏、邏輯混亂、用詞不當、沒有介紹到專案重點……
專案經驗面試在面試中佔很大比重，面試官通過一些專業性的技術問題來了解你的技術水平，問題從哪來？要麼來源於結構化面試題庫（每個面試者的問題都一樣，多出現在校招一面），要麼，就是從你的簡歷中專案經驗來。所以對專案整體而深入複習的重要性不言而喻。
介紹專案時面試官會考察應聘者的溝通能力和思考能力，我們大部分情況都是做產品的一個功能或一個模組，但是即使是這樣，自己有沒有把整個系統架構或產品搞清楚，並能介紹清楚，為什麼做這個系統？這個系統的價值是什麼？這個系統有哪些功能？優缺點有哪些？如果讓你重新設計這個系統你會如何設計？這些都是值得你好好思考的。
專案介紹思路
這部分技巧對簡歷上的專案介紹也是通用的。
首先用一句話介紹這個專案做了什麼，打個比方，我使用XX 框架實現了一個 XX
主要功能
挑亮點和創新點講，細碎的功能點一句帶過。
然後講基本的實現：主要運用到的技術點有XXX。
（這裡面試官從你介紹的技術點切入考察，所以要好好回顧複習專案中運用到的技術點細節。）
架構
（面試官還會問一問為什麼你選了這樣的架構／方法來實現。）
我在專案中的角色
主要介紹專案中的職責和作用，是多面手 or 組長 or 技術 。這點主要凸顯你的工作量和貢獻率。
注：可以在簡歷上附上專案github地址，上傳重點功能的演示 gif ，讓面試官可以很直觀地評估你的專案規模和難度。
面試官會考察些什麼？
知己知彼，摸清面試官心理，你才能有針對性去準備。
1. 能力、技術
考察深度：深入瞭解哪個技術？
整個專案中用到了哪些開源框架？他們的實現思路是什麼？你看過他們的原始碼嗎？你不僅僅是要會用開源庫和第三方SDK，還需要知道實現原理和技術細節。不然一個都是第三方堆砌起來的App，問這個說不了解，用的第三方框架，問哪個說不了解，用的SDK，你還要面試官問什麼？[攤手]
考察廣度
在進行技術選型的時候，你有過什麼考慮，做過多少調查。詳細地瞭解不同的工具/框架 思想的對比。最後是什麼原因，你選定了這個技術。記住一句話：技術沒有優劣，只有合不合適。功能點的實現方式有很多，往往選擇的是最適合的。
同時面試官可能會考察你是否關注產品資料，是否關注合理的工作流程，是否關注前後臺互動時的相關知識和流程，是否關注測試自動化、持續整合等其他方面。
2. 潛力
做專案中怎麼解決問題？
主要展示自己解決問題的思路。
舉一反三的能力
面試官會提出和專案技術類似的點，考察你是否能將新知識點聯絡到已學的技術，然後嘗試解決它。
優化專案哪些部分
面試官意在考察你的思考力和動手能力，開源庫多多少少都會有坑，你是否在應用中排查出坑並且能埋坑。
如何快速學習專案需要的技術點
首先，找資料順序是：官網文件->權威書籍->google->StackOverflow->部落格。其次，新技術的學習非常考驗基礎。打個比方，沒學過RxJava，但是如果你知道設計模式的觀察者模式，理解起來就很快。
3. 細節
sdk的細節瞭解在哪裡
自己造輪子確實費時間，但是你又是否知道SDK做了哪些優化？
自定義控制元件優化
作品對比
自己的專案有沒有和市面上的競品比較過，客觀地評價下從別人的作品中學到了什麼，基於此你有沒有改進自己的作品？
演算法
主要是一些坑和解決思路、解決的靈感來源等，在專案中肯定會涉及到資料結構，比如快取最近100條點選記錄，超出100條則移除最早快取的記錄，自己實現。可能你會想到用佇列或堆實現，那可以去看看快取演算法Lru演算法的原理，用的什麼容器，為什麼這麼設計？
4. 主動性
- 是否做過知識總結、知識沉澱？（這就是平時注重部落格積累的好處了）
- 是否實踐過知識分享？
- 是否主動給專案提出過意見或建議？
5. 溝通能力
在面試的過程中，悄聲無息進行的還有另一項考察 —— 溝通能力。想想自己面談時是否能讓面試官感覺舒服，是否能清晰表達自己的要點，是否能清晰表達自己未來的個人發展規劃。可以嘗試模擬面試錄下音，看是否有過多的語氣詞表達出的不自信。
6. 例子
說了這麼多，搞個直觀的例子談談。
問：
專案中推送是怎麼實現的？
答：
剛開始做推送的時候，對目前主流的推送方案大致瞭解了一下。發現推送實現不止一種。
（展示技術選型和方案，簡單談下就ok）
（1）GCM服務
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：該服務在國內不夠穩定、需要使用者繫結Google帳號。
（2）XMPP：
優點：開放性，標準性，可擴充套件，跨平臺，且已有開源專案。
缺點：資料冗餘（基於XML），不支援二進位制資料，協議雖然完整擴充套件性雖然好，它耗費網路流量很大，跑起來比MQTT慢很多；有高達70%的流量是耗費在XMPP本身的標籤和編解碼上面。
（3）MQTT
優點：協議簡潔、小巧、可擴充套件性強、省流量、省電。
缺點：不夠成熟、實現較複雜、服務端元件rsmb不開源，部署硬體成本較高。
（4）HTTP輪循
優點：實現簡單、可控性強，部署硬體成本低。
缺點：實時性差。
（體現技術細節）
所以後續選型，我選擇了 XMPP + MINA + AndroidPN 來實現推送。
（體現專案優化改進之處，體現自己的思考和能力，對開源專案進行改造）
但是 AndroidPN 開源專案也存在一些不足之處：
如果將訊息從伺服器上推送出去，就不再管理了。
我的做法是：客戶端收到推送後給服務端一個反饋，如果服務端在一定時間內沒有收到反饋，則重發。
androidpn伺服器收到訊息後如何知道要發給哪個使用者？
所以我加了個tag維度來做使用者分組
一旦伺服器重啟了，客戶端似乎不會自動重連，需要使用者自己中斷後臺Service再重啟應用。
完善的方法是加上心跳機制和斷線重連
AndroidPN伺服器不儲存訊息。就是說它一有訊息就會發出去，即使客戶端根本不線上，它也不會重發。
解決方案是讓服務端保持對客戶端狀態的監控
再問：
怎麼不用現有的極光推送？
答：
極光推送初始的版本文件不全，接入麻煩，同時我對推送的原理很感興趣，所以想自己實踐下。
問題示例
最後，是面試官針對專案面試可能提出的問題彙總。
你參與的專案是獨立完成的還是團隊協作完成的，在團隊裡是什麼角色？是負責人還是參與者？
專案執行過程中的難題你是怎麼處理的？
問一些專業性的技術問題來了解你的水平。
如果是沒有明確結果的專案，你從專案裡學到了什麼，有什麼經驗教訓？
看你的專案經驗，還有思維邏輯性，對專案整體的認識，包括技術的選型和架構的設計等等。
專案技術點具體的使用場景，比如多執行緒的控制、效能優化、資料庫設計、加密混淆等等。
挑一個你最熟悉的專案講講吧。
講解你是怎麼從0到1對專案進行開發和改造的。
題目確立 -> 產品需求開發 -> 概要設計 -> 詳細設計 -> 測試用例 -> 編碼 -> 測試 -> 優化 -> 宣傳視訊海報的製作。
開放性問題
當然，存在有的面試官傾向於問一些開放性的問題。主要看重你是如何解決問題的，看你的思維方式是怎麼發散的。
比如面試官問我，你為什麼覺得你做的產品就比別人好？你為什麼要對你們的產品進行效能優化，主要瓶頸在哪裡？你是通過什麼方式進行優化？你優化的點是怎麼考慮的？你在使用第三方服務是處於什麼目的，你對它的評價是什麼，它們給你帶來的好處是什麼？讓你去思考如何更好的為開發者提供服務，你覺得還有什麼東西是開發者需要的？你對開發工具類產品感興趣嗎？
可以從這些問題看出，面試官並不僅僅看重你的技術能力，還有你對產品的認識。面試官想找的人不僅僅要在技術上有亮點，還有其他方面能吸引到他們。
最後
最重要的一點：不知道的技術點不要不懂裝懂。很多時候我們都會遇到一個情況，就是面試官的問題我不會，這時候大多數情況下不要馬上說我不會，也不要糊弄回答，要懂得牽引，轉移話題往類似的你擅長的技術點方向去，不然當你抱著僥倖心理隨便回答出問題後，面試官會一直沿著往下深挖，挖到挖不出來為止，這就很尷尬了。