Android程序員秋招三面螞蟻金服，高級Android都應該知道

時間 2021-08-12

標籤 git 程序員 github 面試算法編程後端服務器數據結構架構欄目 Android 简体版

原文原文鏈接

我覺得是HR一面，結果是技術，沒想到啊，沒想到！git

一、描述Activity的生命週期。程序員
二、描述一個Activity啓動另一個Activity的生命週期github
三、Activity標籤能夠配置什麼面試
四、IntentFilter裏面的標籤能夠幹嗎算法
五、Service怎麼啓動編程

　　瞭解IntentService嗎？後端

六、幾大控件有服務器
七、存儲數據的方式有數據結構
八、Intent能夠幹嗎架構
九、Sharedpreference裏面的apply和commit有什麼區別
十、ContentProvider用過嗎？爲何要用這個
十一、ASyncTask用過嗎？知道是怎麼實現的嗎？
十二、線程池知道嗎？怎麼建立？底層怎麼實現？
1三、Set、List、Map區別，Map底層怎麼實現的
1四、重寫View怎麼重寫？
1五、快排實現
1六、實現兩個鏈表表示的整數相加（空間複雜度要求很低）

看到還有不少程序員連面試流程都沒有完全弄清楚，今天，咱們以阿里爲例，來聊聊互聯網大廠的面試流程和過程！

本篇主要仍是聊聊社招的面試過程！阿里以及其餘的互聯網大廠的技術類社招面試，一般狀況是 4 個輪次。第1、第二面是技術面，第三面是主管面試，第四面是 HR 面試。對於目標級別在 P6+ 的候選人，咱們會增長至少一輪的跨團隊 Review 面試，由於涉及招聘委員會（Hire Committee）的定級流程，因此要複雜一些。接下來的內容，主要針對一般狀況下 P5~P6 的面試來介紹，大神請直接忽略。

01?技術面

1. 我的介紹和基礎知識考查

這部分算是必備技能。我我的卻是傾向於弱化基礎知識的考查，畢竟每一個候選人的背景不一樣，應該更看重聰明程度、學習能力、溝通理解力等，基礎知識只能證實他不是一個優秀的工程師，卻沒法證實他是一個優秀的工程師。
2. 項目經歷考查

從這個階段開始就格外重要了，由於面試官以前並不必定完整瀏覽候選人的簡歷，因此聆聽候選人對項目的介紹是瞭解候選人的最主要途徑。在這個過程當中，面試官試圖刨根問底，這跟各公司內部的技術評審很類似。幾個關鍵點，但願你格外注意：

對項目背景的瞭解程度，講不清楚需求從哪裏來是很是可怕的，這說明你更多隻是一個執行者，不是負責人，且缺乏對於項目總體的思考。
對需求的合理性進行分析，一味遵從 PM，不能把控需求的研發是很可怕的。
對技術方案設計的調研和選型，咱們更但願看到你的方案是通過充分思考、調研、對比、論證的，經過這個過程，能夠看到候選人的系統設計功底，是否對業界技術有足夠了解，對開源技術的掌握狀況，是否願意應用開源技術。哪怕你的項目只是一個簡單的業務系統，那麼仍然應該有不少亮點可尋，不然這段項目經歷可能會減分。
取得的成效。不少工程師只看重過程，不看重結果，這是不可取的。

3. 編程技術考查
在個人團隊中，我要求每一輪技術面，都至少要有 1 道編程題目。一方面，咱們很是看重侯選人的代碼風格、優雅程度，還有對邊界條件的考慮，這些都是好的程序員必須具有的素質。對於代碼混亂、邊界考慮不清的人，咱們會認爲他沒有足夠的編程素養和追求，在邏輯思惟層面，也有所欠缺。這樣的候選人進入團隊，短時間可能形成 Bug 多、項目質量差等影響，長遠來看，不利於合做開發、項目傳承等。另外一方面，咱們很是看重數據結構、算法等的高效實現。可以快速設計出高效的程序，這體現了候選人平常的深厚積累，還有對編程的極致追求。前不久就有一個典型案例，咱們的運維同窗發現一個後端模塊上線後處理性能只有幾十 QPS，很不理解爲何性能這麼差。直到咱們從新 review 代碼後，才發現是個「經典」問題，即 for 循環裏調用 sort（雖然是隔了幾回函數調用），簡單優化後，性能就能夠提高 1~2 個數量級。優秀的工程師，必定會盡量規避這類問題，幾行代碼的優化，就能提高用戶體驗、下降服務器成本、方便代碼維護、減小兄弟們的工做量。
4. 邏輯題目或數學題目

這類題目的核心不在於它有多複雜，須要多少經驗背景，而在於，只要邏輯清晰，認真思考，大多能得出結果，雖然不必定是最優解。我舉幾個例子：

一個六位數字，逆時針旋轉 180 度後與以前徹底相等的機率是多少？
邊數是 3*4 的網格，從左下角的 A 點走到右上角的 B 點，一共有多少種不一樣的走法？

這類題目其實很簡單，能夠用編程的思路解決，好比遞歸（固然還有不少其餘方式），也能夠用機率論、組合數學的方式解決，甚至一個一個「數」也是能獲得答案的。在思考問題的過程當中，能夠看出候選人的思惟習慣，也能夠看出候選人的邏輯能力。另外，這類題目其實有不少變化，若是候選人很輕鬆完成了回答，面試官就能夠適當加大難度，好比 3*4 的網格有一個點不能通過，那麼會是什麼結果？這類題目看似簡單，實則分辨率很高，能夠充分挖掘候選人的潛力。除去上面的介紹外，候選人還應該對行業狀況有所理解，包括競品、開源項目等，這能夠體現一我的的眼界和行業洞察能力，也能夠看出一我的的學習態度，他是否在持續更新本身的知識儲備。

02??主管面

相對於技術面而言，主管面試不會過多考查基礎知識、數據結構及算法，但由於技術主管大多具有很強的技術背景，因此仍然會針對技術面過程當中的一些遺漏點（多是面試官沒有考查到，也多是候選人的回答不夠完善），着重補充考查。除此以外，主管面的核心就是判斷候選人除了技術能力外的其餘維度，是否與團隊相匹配。第一類維度，軟素質能力。軟素質的維度很豐富，每一次面試過程不會面面俱到地考查，但一些重要的維度必定會被照顧到。

1. 邏輯思惟。
與技術面的邏輯題目相似，團隊能夠接受不足夠聰明的人，但沒法接受邏輯不清晰的人。在這個環節，能夠提出一些進階的題目，好比給候選人一個很複雜的問題，但願候選人能夠嘗試分析、分解，讓看起來一團亂麻的問題變得清晰可實現。或者，讓候選人闡述一個經歷過最有挑戰的問題，是如何定義問題並分析解決的。固然這類問題，通常初入職場的同窗都很難回答完美；不過對於工做 2 年 + 的同窗，我以爲問題的分析、分解、設定目標、規劃、執行都是必備素質。這個能力很難在工做中迅速培養，它更可能是經過候選人過去一二十年的學習和工做經歷，一點一滴積累的，因此對於社招而言，但願候選人已經具有很好的邏輯思惟能力。
2. 溝通能力。
不能有效且高效地溝通，對於團隊項目是場災難。在平常工做中，常常會看到幾個同窗針對一個問題爭論得不可開膠，但其實他們每每沒有理解對方所講的主旨是什麼，甚至對於一些名詞和概念的理解都不一致，就更不要說同理心了，這種無效溝通是致使會議冗長的最主要因素。這類的面試考查，通常會依附於項目介紹或者設計題目等。

若是候選人已經具有不錯的溝通能力，咱們通常還會考查進階能力：說服和影響。這是成爲技術 / 項目負責人的必備能力。面試官可能會和候選人進行一個簡短的虛擬溝通或辯論環節，但願候選人能夠說服面試官接受某個觀點或技術方案。固然，在這個過程當中，面試官扮演的反派可能會用一些偏激的詞彙和行爲，這一方面是看候選人的溝通說服和影響他人的能力，另外一方面也是壓力測試，看看候選人在受到刁難時的反應，是否足夠職業。創新能力。

在過去的項目中，請講述一次發現傳統方法的不足，嘗試新的解決問題的方法，並得到成功的經歷。這類題目很是開放，但遺憾的是，在我面試過的候選人中，近半數都是在思索一下子後回答「沒有什麼」。

固然，一方面可能候選人很謙虛，另外一方面，則極可能是候選人確實沒有嘗試作過什麼創新。

互聯網行業，創新是一切之源，若是真的「沒有什麼」，如何給 Offer 呢？

第二類維度，文化價值觀。

工程師文化是務實、自驅、Follow Through（跟進到底，善始善終）。一個浮誇，不思進取，凡事不肯承擔責任，不能將項目跟進到底的候選人，很難成爲咱們的夥伴。這類維度，其實沒有太多經驗可談，每一個公司都有它的文化基因，而候選人是否與之匹配，是基因和環境使然。我只說下從我我的角度，最爲看重的內容，不然我會一票否決。樂觀積極。不得不認可，每一個人都有積極的一面和消極的一面，職業化的思惟在於將積極的一面展示出來，儘可能弱化消除消極一面的影響。

在平常工做中，每一個人都不但願遇到一羣愁眉苦臉、滿腹牢騷的同事。善於合做。一位同窗加入到咱們的團隊，他不只須要具有優秀的我的能力，同時也須要能和其餘人協同合做，起到 1+1>2 的效果。咱們會考查候選人在過去的經歷中，對待合做的態度，有沒有接觸過比較複雜、跨越多個角色或團隊的合做，遇到過的協做困難是什麼，遇到這類困難是如何解決的。有些候選人常常會無心識地表達出，在項目研發過程當中，多人寫代碼，還要同步需求、設計、協商接口、聯合調試，並且有 Bug 修復推進也很麻煩，若是我一我的開發早就解決了。這種思惟雖然無可厚非，但但願每一個人能夠看得更遠，大型項目是一我的完成不了的，在多人合做的背景下，如何提高合做的效率和質量纔是重點，而不是過多地看到負面。追求極致。這一條很難。在我發過的這麼多 Offer 中，具有這個素質的候選人也是百裏挑一，但只要具有這個素質，我幾乎必定會給 Offer。固然，追求極致不等於鑽牛角尖。