轉(zhuǎn)載自http://blog.csdn.net/journeyx/article/details/74907082
【
1、從面試談起(看人的性格，內(nèi)向還是外向。)

2、如今是賣方市場(要降低要求，一個強力的Team Leader，外加一些能干活的人就行了。在工作中培養(yǎng)人才，提升從業(yè)人員水平。)

3、名校論不適用無線開發(fā)（類似于搜索之類涉及復(fù)雜算法的軟件行業(yè)，固然需要較高學(xué)歷良好背景的人去研究。但對于App應(yīng)用類軟件而言，每天的開發(fā)工作大都是重復(fù)性畫UI和調(diào)用MobileAPI獲取數(shù)據(jù)，并無需名校出身。）

4、如何搞到更多的簡歷(和HR搞好關(guān)系，加入招聘組。)

5、面試時需要考察的幾個點
{
主要考察3個方面：
(1)、技術(shù)水平，主要是候選人的編程技術(shù)水平。
(2)、領(lǐng)域知識，主要是候選人對業(yè)務(wù)的了解程度。
(3)、軟件技能，包括溝通能力、抗壓能力、性格。
一般而言，有兩輪最重要。第一輪是Team Leader面試，考察技術(shù)水平。第二輪是用人部門的負(fù)責(zé)人面試，考察領(lǐng)域知識和軟件技能。
--->如何考察面試者的技術(shù)水平？對于App而言，分為3個方向：
(1)、應(yīng)用類：共同特點是頁面特別多，都需要頻繁地調(diào)用MobileAPI獲取數(shù)據(jù)，都涉及到支付流程，所以這類App的開發(fā)人員需要對UI、網(wǎng)絡(luò)、登錄、支付流程都非常熟悉。
(2)、手機管家類：這類App雖然也算是應(yīng)用類，但是很少調(diào)用MobileAPI,它更多關(guān)注的是手機系統(tǒng)內(nèi)部數(shù)據(jù)的讀寫，所以這類App的開發(fā)人員需要對ActivityManager、Service、BroadcastReceiver之類的知識很熟悉。
(3)、游戲類：必須對動畫引擎很熟悉，比如說Cocos2d和Lua。
此外，還有一類Android從業(yè)人員，是在華為、三星這樣的硬件廠商做手機系統(tǒng)的二次開發(fā)，包括手機系統(tǒng)上自帶的一些軟件，嚴(yán)格地說，不屬于App開發(fā)。
--->面試時經(jīng)常考察的幾個方面：
(1)、Activity的生命周期。
(2)、Activity的4的4種啟動方式及使用場合。
(3)、做過的項目中，Activity是否有基類，如果有，封裝了哪些共用的邏輯？
(4)、事件的各種使用方法及優(yōu)缺點。
(5)、與HTML5頁面的相互調(diào)用。
(6)、UI線程的阻塞與解決方案(Runnable 與 Handler)。
(7)、采用什么姿勢調(diào)用MobileAPI并解析返回的數(shù)據(jù)？
(8)、怎樣做列表的分頁和刷新。
(9)、登錄的實現(xiàn)，包括從哪里來，到哪里去的頁面跳轉(zhuǎn)機制，記住密碼的邏輯設(shè)計。
(10)、性能調(diào)優(yōu)，包括Layout調(diào)優(yōu)、Activity中如何使用CONST常量、時間換空間策略、ViewHolder、圖集的優(yōu)化策略、數(shù)據(jù)緩存和圖片緩存，等等。
(11)、全局變量過多怎么辦？
(12)、寫過UT沒？
(13)、是否做過自動打包？Ant、Maven或gradle任意一種都可以。
對于TeamLeader的要求會更高一些，包括如何檢查內(nèi)存泄漏，如何優(yōu)化內(nèi)存、多線程、自動打包、框架設(shè)計、版本管理等諸多方面。
}

6、無線團(tuán)隊必備的10份文檔
{
一個團(tuán)隊成熟與否的標(biāo)志是文檔。文檔太多，就違反了敏捷的原則，但有幾個文檔是必須提供的：
(1)、新員工入職文檔（這份文檔包括：部門組織結(jié)構(gòu)，新員工所在的團(tuán)隊和將要擔(dān)當(dāng)?shù)慕巧粋€人簡介，用于群發(fā)給部門其他成員；要加入的公司郵件組，部門內(nèi)部用于溝通的QQ群或微信群；Android項目的地址，權(quán)限申請；Bug管理工具及權(quán)限申請；測試環(huán)境和仿真環(huán)境的地址；產(chǎn)品需求的地址；WIFI設(shè)置、VPN申請、手機郵箱配置、打印機安裝，等等。）
(2)、加強版新員工入職文檔：(這是一份更適合Android團(tuán)隊的新員工入職文檔：SVN或GIT的權(quán)限申請；Android開發(fā)常用軟件下載；迭代的節(jié)奏；業(yè)務(wù)名詞解釋；Android App的項目結(jié)構(gòu)；Android自動打包地址；模板<模范標(biāo)準(zhǔn)>頁面。)；代碼規(guī)范。
(3)、測試機清單（測試機型號、操作系統(tǒng)、使用人。采購測試機可以看友盟統(tǒng)計）
(4)、模塊分工表：（把開發(fā)人員按照業(yè)務(wù)線<模塊>進(jìn)行劃分）
(5)、頁面邏輯流程文檔
(6)、MobileAPI接口分布圖：(一般用XMind思維導(dǎo)圖來描述一款A(yù)pp所用到的MobileAPI接口。好處：定期檢查IOS和Android在做同一功能時所使用的MobileAPI是否一致；每次MobileAPI發(fā)版上線，相關(guān)的測試人員，就可以根據(jù)這張圖，找到這些MobileAPI接口改動影響了哪些頁面和功能，需要進(jìn)行相應(yīng)的回歸測試。)
(7)、版本管理策略文檔：(無論是使用SVN還是GIT，都要制定一套發(fā)版流程。Android團(tuán)隊中要有專門的開發(fā)人員熟悉并遵守這套流程，包括:
正常迭代的流程；開新分支做技術(shù)調(diào)研的流程；緊急上線流程。
流程一般有兩種，要么是主干開發(fā)主干上線，要么是主干開發(fā)分支上線，無論是哪一種，都要落實文檔，切記口口相傳。)
(8)、框架設(shè)計文檔：（當(dāng)我們把AndroidLib這個業(yè)務(wù)無關(guān)的類庫從App中抽象出來的時候，就該有一份框架設(shè)計文檔了。）
(9)、發(fā)布流程文檔：(Android要發(fā)布到各大市場，為此，需要修改清單配置文件中的友盟渠道號，才能統(tǒng)計各大市場的下載量。此外發(fā)布的apk包要混淆：渠道號是否正確？ 代碼是否混淆？ 版本號是否正確？ 是否release包(而不是debug包)？ 臨時決定關(guān)閉的功能是否露出來了？ 是否可以支付、分享、掃描二維碼？ 升級安裝是否會引起崩潰？
鑒于以上各點，需要制定發(fā)布流程并形成文檔，包括：
<1>、產(chǎn)品經(jīng)理準(zhǔn)備發(fā)版所需要的描敘文字、圖片等材料。
<2>、開發(fā)人員進(jìn)行批量打包工作。
<3>、測試人員要隨機抽取一個apk包進(jìn)行測試，包括功能點測試。
<4>、推廣人員發(fā)布到各大市場，要有郵件持續(xù)跟蹤各個渠道的版本更新進(jìn)度。
<5>、在版本倉庫上打Tag,合并分支上的代碼到主干。 )
(10)、App啟動流程圖
（如果要做App性能優(yōu)化，最好的著手點是App從啟動到進(jìn)入首頁的流程。大多數(shù)Android App的啟動Activity并不是首頁HomeActivity,而是一個叫做LaunchActivity的頁面，它的UI就是簡單的Splash動畫，同時它肩負(fù)著更多的職責(zé)，如：
<1>、注冊友盟、推送等等第三方組件。
<2>、加載Splash圖，同時下載新的Splash圖以便下次開啟時使用。
<3>、如果是首次打開，則進(jìn)入引導(dǎo)頁。
<4>、友盟打點，統(tǒng)計激活數(shù)。
<5>、如果有消息推送到達(dá)，點擊消息后想不經(jīng)過首頁而直接進(jìn)入某個二級頁面，其實在代碼層面還是要經(jīng)過LaunchActivity的，由它對推送消息進(jìn)行分發(fā)，以決定該跳轉(zhuǎn)到哪個二級頁面。
以上這些邏輯交織在一起，非常復(fù)雜，尤其是要區(qū)分升級版和全新安裝版的時候，為此我們需要用Visio之類的軟件繪制一個App啟動流程圖。在業(yè)界，我們將LuanchActivity稱為Bootstrapper。LuachActivity把上述這些事情都做完，才會進(jìn)去到首頁HomeActivity。）
}

7、一對一溝通
{
走簡便流程，要求：
<1>、最近一個月做了哪些事情，有什么提高？
<2>、自身想要有什么提高？需要我?guī)椭鲂┦裁矗?br> 經(jīng)常反饋的有:
<1>、強烈要求團(tuán)建。
<2>、有的程序員想轉(zhuǎn)行做產(chǎn)品經(jīng)理，想得到一些鍛煉的機會。
<3>、初級程序員希望分配到一些更高級的Task。他們渴望新知識，而不是天天畫UI。
<4>、有些程序員比較好學(xué)，希望團(tuán)隊有大牛，能學(xué)到東西。
<5>、渴望被表揚。
}

8、每周技術(shù)分享
{
技術(shù)分享是提高團(tuán)隊技術(shù)水平的3個方法之一，另外兩個是Code-Review和修復(fù)線上Crash。
技術(shù)分享關(guān)鍵在于堅持。技術(shù)分享并不是天馬行空，不為所云的技術(shù)暢談，要根據(jù)團(tuán)隊整體技術(shù)水平和實際項目需要，彌補團(tuán)隊短板。建議可以羅列Android或IOS必須掌握的若干技術(shù)點，然后發(fā)給大家給自己打分，每個技術(shù)點都是5分制。<完全不知道：0分 聽說過：1分 看過介紹的文章：2分 親手做過demo：3分 項目中使用過：4分 非常熟悉：5分>，把大家的自我打分收集上來進(jìn)行匯總，對團(tuán)隊的整體技術(shù)水平就一步了然了。對于團(tuán)隊的技術(shù)短板，在每周的技術(shù)分享上，會安排團(tuán)隊成員進(jìn)行講解。
}

9、代碼評審
{
常規(guī)代碼審核會出現(xiàn)一些情況，首先在我們是個互聯(lián)網(wǎng)公司，App迭代的周期只有兩周，所有的開發(fā)人員都疲于奔命做需求，哪有時間去審核別人的代碼，會出現(xiàn)一些情況：
<1>、能力強且責(zé)任心強的開發(fā)人員，一天大部分時間在審核別人的代碼。
<2>、能力強且責(zé)任心差的開發(fā)人員，看都不看直接審核通過了。
<3>、技術(shù)能力弱的開發(fā)人員，要審核別人的代碼也是心有余而力不足。
另一個副作用是：因為每次請別人Code-Review都要等，所以開發(fā)人員傾向于每天下班前一次性提交所有改動，并沒有遵守持續(xù)開發(fā)、持續(xù)提交、持續(xù)測試的持續(xù)集成思想。
===應(yīng)變解決方案為:
<1>、對老員工不再進(jìn)行Code-Review。
<2>、對新員工和實習(xí)生、應(yīng)屆生，要為他們每人指定一個Code-Review的老員工，至少3個月之內(nèi)，對他們的Code-Review還是要嚴(yán)格執(zhí)行的。
大致的標(biāo)準(zhǔn)為：看編碼規(guī)范或看編碼邏輯。
---->互聯(lián)公司沒有時間去搞太繁瑣的流程，可以把Code-Review的策略改為，每周一下午，技術(shù)經(jīng)理從上周提交的代碼中找出10處寫的有問題的代碼片段，然后給大家進(jìn)行講解和討論。在達(dá)成共識后，今后就再也不能寫類似的代碼了。
那么對于有問題的代碼，處理方式建議，對于首頁、會員中心這種一級頁面，不能改要保證穩(wěn)定性。對于二級或三級頁面，局部某個功能可以安排人員去修改。
在進(jìn)行Code-Review的同時，有一個東西可以順便搞出來，那就是模板頁面，即符合編碼規(guī)范要求、可以作為編寫其他頁面的模板頁面。對于Android應(yīng)用類App而言，一個模板頁是不夠的，至少要提供Activity、Adapter、Entity、Fragment這4個模板頁，其中Acitivity要包括對MobileAPI的調(diào)用。
有了模板頁，所有開發(fā)人員的編碼就有章可循，單純搞Code-Review和編碼規(guī)范都太抽象，一定要有能落地的東西，那就是模板頁。
}

10、對Android團(tuán)隊Leader的定位
{
Android團(tuán)隊Leader要負(fù)責(zé)的工作羅列入小：
<1>、每次迭代把Tesk分配到具體的開發(fā)人員。
<2>、組織線上Crash的修復(fù)。
<3>、處理線上突發(fā)bug。
<4>、排查每日客人投訴的問題。
<5>、解決團(tuán)隊遇到的技術(shù)難題。
<6>、組織每周Code-Review。
<7>、組織每周例會。
團(tuán)隊Leader一定要明確自己的職責(zé)，，注意以下兩點：
<1>、不要給自己分配具體的需求開發(fā)，管理工作會消耗掉你大量的時間。
<2>、努力不要使自己成為瓶頸。很消耗時間的事情，及時分配到具體的開發(fā)人員。
哪些工作是要盡早分配給具體的開發(fā)人員呢？
<1>、Android項目的打包。
<2>、代碼混淆。
<3>、設(shè)計Android的Lib框架，交給框架組去做。
<4>、技術(shù)調(diào)研。
<5>、Monkey日志分析。
}

11、Android 應(yīng)用開發(fā)所需技能自我評測
{
從事Android應(yīng)用的開發(fā)人員所需要精通的20個技能點，如下：
<1>、Activity相關(guān)。App應(yīng)用開發(fā)，以Activity使用最多，涉及LaunchMode、onSaveInsatanceState、生命周期等技術(shù)。
<2>、Fragment相關(guān)技術(shù)。用的人不少，想明白是咋回事的人不多。
<3>、序列化技術(shù)。有Parcelable和Serializable兩種。前者是基于Service的，后者是基于Bundle的，二者實現(xiàn)原理不同，但是達(dá)到的效果差不多。
<4>、ImageLoader的原理和使用。類似的還可以學(xué)習(xí)Fracebook新開源的Fresco,它對圖片的處理會更好一些。
<5>、fastJSON或GSON的使用。做App不會用實體自動匹配JSON數(shù)據(jù)，相當(dāng)于白做。
<6>、多線程相關(guān)。包括Handler、Looper、ExecutorService等。
<7>、Adapetr和ListView。這兩個技術(shù)捆在一起，經(jīng)常容易崩潰，尤其是分頁的時候，要仔細(xì)研究深刻領(lǐng)會。
<8>、用戶Cookie設(shè)計。需要把登錄機制徹底搞清楚，包括在HttpRequest頭中夾帶Cookie來進(jìn)行用戶身份驗證的技術(shù)。
<9>、網(wǎng)絡(luò)請求封裝。使用AsyncTask的網(wǎng)絡(luò)底層封裝，使用Handler+Runnable的網(wǎng)絡(luò)底層封裝。
<10>、Android與HTML5的 交互。包括Android調(diào)用HTML5的方法，以及HTML5調(diào)用Android的方法。
<11>、代碼混淆。沒用過ProGuard,不知道keep相關(guān)語法的，有待研究。
<12>、Android 打包機制。涉及Android SDK中的若干命令。對Android打包過程做的每一件事都很清楚。進(jìn)一步是Android多項目依賴的打包技術(shù)。Ant、Gradle或者M(jìn)aven,掌握其中任何一種打包機制即可。
<13>、線上Crash分析并修復(fù)。要具備通過分析Crash信息修復(fù)線上Crash的能力。
<14>、內(nèi)存泄漏。包括內(nèi)存優(yōu)化、內(nèi)存泄漏的場景、MAT工具的使用。
<15>、調(diào)試工具。包括DDMS、Eclipse或者Android Studio的調(diào)制功能。
<16>、Monkey機制。Android開發(fā)人員如何對一款A(yù)pp進(jìn)行Monkey測試。
<17>、單元測試。這里指的是JUnit。對復(fù)雜的算法寫過單元測試以保證其沒有問題。
<18>、GIT的高級功能。如果項目使用的是SVN,那么要掌握SVN的版本管理策略。
<19>、插件化編程。哪怕知道一點DexClassLoader的概念也好。
<20>、設(shè)計模式。對常見的設(shè)計模式如工廠、生成器、適配器、代理、策略模式耳熟能詳。
}

】