一些常見的iOS面試問題，一眼就能看出 初級和高級工程師的區別

前言

面試題中有一些通常性的問題，一般是會問到的。面試iOS應聘者時，切入點很重要，不一樣的切入點會致使不一樣的結果，沒有找到合適的切入點也沒法對應聘者有一個全面的瞭解。

因此下面的面試問題更多的是提供方向，沒有固定的答案，並且能夠根據應聘者的迴應引出更多有意思深層次的討論。

注意：如下問題的參考答案均爲筆者所答，不表明正確，問題答案因人而異，請根據本身的實際狀況回答，若認爲不合理，請在評論中指出。下面全部的參考答案，都是筆者站在面試官的角度來分析的，不一樣的面試官也會不同。筆者面試過一些人，一問就能夠知道對方的底子如何了，雖然如此，不表明參考答案是每一個面試官想要的。

自我介紹

自我介紹時，必定要簡潔明瞭，不要長篇大論。以我我的而言，最不喜歡自我介紹說了一大堆，最後連她/他叫什麼名字都沒記住。

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個個人iOS交流羣：638302184，無論你是小白仍是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！

參考答案：

自我介紹時，突出重點，說話慢一些，在關鍵點聲音大一點。本人回答時，就簡單地說： 我叫某某某，作iosX年了，曾在XX公司擔任過XX職務，在YY公司擔任過XX職務，主要負責ZZ工做。業餘喜歡作NN（要說積極點的），擅長LL（把本身的特長說明白）等。

最近這兩天你有學到什麼知識/技能麼？

對於這個問題，面試官確定知道做爲求職者，這兩天確定是在忙於找工做、面試。那麼，面試官問出這樣的問題的目的是什麼？若是我是面試官，我最想了解的是這兩天你爲這次面試準備了什麼而不只僅是告訴面試官這兩天學習了某一方面的知識。

參考答案：

這兩天爲了準備面試，整理了之前所作過的一些項目的筆記，回頭看了看之前的工做日誌。一來是整理一些在工做中常常遇到的坑，好比cell重用問題、ios6適配問題等；二來是回頭告別過去的本身，在思想上、技術上迎來全新的自我；三來定位本身下一個目標：往架構師方向深刻研究。

最近有作過比較酷或者比較有挑戰的項目麼？

這個問題的關鍵是酷和挑戰。其實這裏所說的酷對應於開發中的動畫，而挑戰則對應於開發中的衝刺。對於筆者而言，其實並無作過特別酷的項目，可是作過有挑戰性的項目。可是沒有作過並非就不用回答，面試官想看到的是你的學習能力、應用能力以及解決問題的能力，而不是一句沒作過或者沒什麼挑戰性這樣的話語。

參考答案：

我以前所負責的項目大可能是電商項目，所以並不會特別酷，可是業務比較多，頗有技術挑戰性。不過，平時我也深刻研究過ios核心動畫相關知識，對於經常使用的動畫是很熟悉的。在我看來，用戶體驗並非所謂的酷，而是簡單、方便且明瞭。我很在乎用戶體驗問題，在開發中會不斷地站在用戶的角度地問本身用戶討厭什麼、喜歡什麼和怎樣才能讓用戶感受容易上手且使用簡單等問題。好比，我會很在乎網絡狀態的變化給用戶的提示、請求網絡時右上角的轉圈圈是否開啓、滾動cell時是否有卡頓的問題等。

我待過幾家公司，從一我的開發到帶領團隊，從小公司到大公司，所以對於不一樣的公司對項目的要求徹底不同。對於大公司，通常項目管理機制相對比較完善，並且會有比較多經驗豐富的技術VP，所以對於工做的要求比較高，對於用戶的體驗及反饋會很是地關注；而對於一些小公司，可能就一我的在開發，而這我的每每是菜鳥的多，所以都是東拼西湊而造成的項目，技術不成熟、水平不夠，並且還被壓着不斷加班，所以幾乎不會過多關注用戶體驗問題，固然這樣項目也不會有什麼好的構架（初創技術合夥人除外）。

如今我所在的公司不算大，也就1000+號人，而作ios也才40號人左右。本公司是按業務方向劃分紅多個團隊，不一樣團隊開發不一樣的業務需求，所以這樣就面臨技術架構問題、安全問題、團隊開發如何作到互不干擾等問題了。

而我在團隊中的主要職責是處理團隊之間衝突的問題、如何代碼模塊化以減小團隊以外的依賴問題、移動端安全通訊問題、項目存儲安全問題、公共框架等問題，這一系列都是很是有技術挑戰的，須要花費不少非工做時間去調研、寫demo、寫文檔等。

最近看過的書/文章有哪些？

詢問最近看過的書或者文章，其實經過所回答的書的性質差很少就能夠猜出當前狀態下應聘者的技術水平大體處於什麼樣的水準了。下面的參考答案是筆者的常態。

參考答案：

最近在看《iOS應用逆向工程》、《The Swift Programming Language》。不過本人更喜歡的是閱讀博客文章和官方文檔，雖然官方文檔是英文的，閱讀起來相對要費勁一些，可是一方面能夠提升英文閱讀能力，另外一方面英文原版表達的語義纔是最準確的，其餘翻譯過來的文章會有一些變味之處。

爲何要學習編程，編程對你而言的樂趣在哪兒？

這樣的話題在不少社區都出現過，其實問這樣的問題只是想知道應聘者的態度而已。經過應聘者的回答，一方面可初步瞭解應聘者對編程的認知程度，另外一方面可從應聘者口出得出編程對於應聘者而言是什麼樣的態度。下面是結合筆者的事蹟寫下的參考答案，僅供參考。

參考答案：

說到這個問題，我曾經也問過本身爲何要學習編程。回想當年高考結果出來的時候，須要選擇學校和專業的時候是很迷茫的，不知上大學應該學點什麼。後來，我選擇了計算機科學與技術專業，併爲了這個專業而選擇學校。

因爲高考考得很差，雖然超過一本線，可是高不成低不就，不少高校的計算機專業要求總分達到560（當時一本線是502分）左右才能穩拿到這個專業，而我才考了526分，想一想計算機專業很強的高校是很難進的。因而選擇了從廣西到瀋陽這麼遙遠的地方上學，居然是爲了計算機專業，如今回想起來還本身偷笑。

在大學的時候，大一每天在圖書館提早學習編程，由於動手能力突出，到大二的時候有好多教計算機的老師提早知道了這樣的我，感謝他們的承認，在大學這幾年，是他們引導我如何編程實戰。大學的時候作過不少PC端的軟件（.net開發的）、給老師作過教程網站（ASP.net開發的）、參加學習的ACM訓練等等，一切的一切，都要感謝那些教導個人恩師們。

後來經過學長了解到將來就業的一些動向，瞭解到畢業後如何找工做，學習了iOS開發，因而愈來愈愛她了。若是非要說編程的樂趣在哪裏，我想說在討論技術的時候就像和同窗、朋友一塊兒玩LOL的時候；在解決掉一個別人解決不了的bug的時候，那是一種想要向全世界大聲說：YES,I Can；當咱們與技術總監並肩做戰，一塊兒爲了項目上線熬夜，總監爲咱們買夜宵一塊兒吃的時候，那就是兄弟情誼，那會有種相見恨晚的感受。

若是一個函數10次中有7次正確，3次錯誤，問題可能出如今哪裏？

這樣的問題經過應聘者的分析，能夠知道應聘者的功底如何。不少人的回答會是很簡單的，沒有從多方面去分析。這樣的問題也是頗有意義的，在項目開發中所產生的bug，有的時候會出現這樣的狀況，而代碼量比較大且業務比較複雜時，經過其餘工具並不能分析出來是什麼bug，可是咱們卻能夠根據出現的頻率推測。筆者把這個問題看成測試部反饋過來的bug描述問題來分析一下。

參考答案：

從問題描述可知，bug不會必現的，所以沒法直接定位出錯之處。從如下角度出現來分析可能出錯之處：

因出錯並非崩潰，所以沒有錯誤日誌可看。第一步就是分析函數中的全部分支，是否在語法上存在可能缺乏條件的問題。因此，檢查全部的分支，確保每一個分支執行的結果的正確的

檢測函數的參數，保證必傳參數不能爲空，若爲空應該拋出異常。所以，用斷言檢測參數的正確性是很重要的。

檢測函數中每一個分支所調用的函數返回結果是正確的，其實就是一個遞歸的過程（步驟一、2）

自身最大優勢是什麼，怎麼證實？

人最大的敵人不是別人，而是本身。打敗本身，纔是最大的勝利。不少人不清楚本身的優勢是什麼，甚至不少朋友喜歡說我最大的優勢是沒有缺點。若是是對面試官說這一句話，那麼你可能被pass掉了。

參考答案：

我也不清楚我最大的優勢是什麼，可是我知道我有不少優勢。

我學習能力特別強，接受新事物的能力也特別強。好比，我在工做之餘還會去學習swift、PHP、js等。

我喜歡寫博客、寫總結、分享技術、幫助他人等。我以爲寫博客的過程，既讓本身對相關知識有更深入的認識，更是幫助到他人。每作一期需求，我都會寫一份總結，記錄那些坑。在公司每一個季度都會作幾回技術分享，帶動團隊的技術氛圍。我也喜歡幫助他人，我建立了本身的技術羣，短短1個月羣就滿500人了，在羣裏經過回答你們問題，也讓我瞭解到不少知識。

我開發過多款App，解決問題的能力很強。在團隊中充當技術主心骨，任何隊員解決很差的問題，我都會幫助一塊兒解決掉。

我對技術構架、團隊如何解藕方面都有所研究。在團隊開發中，由於常常面臨團隊開發存在交差的問題，致使需求變更引發不少問題，所以研究過如何讓團隊之間減小依賴的問題。

我活躍於GITHUB、CocoaChina、CSDN等，對於iOS相關技術知識比較熟悉。

就說這麼多吧！(由於面試高級人員一般會交談3個小時左右，因此儘量地說吧，不要懼怕時間過長)

有沒有在 GitHub 上發佈過開源代碼，參與過開源項目？

github上的開源項目能夠體現應聘者的水平以及對編程的熱愛程度。一個不足夠熱愛編程的人，業餘時間是不會花在編程上的，所以更不會有什麼開源項目了。

參考答案：

這裏個人開源庫的地址標哥的GitHub，裏面除了一些開源庫以外，還有不少的demo，每一個demo都有對應的博客文章講解，那都是我感受學習的成果。

我在GITHUB上發佈過不少開源代碼，也提供了支持cocoapods的開源項目，如今也有很多人在使用，固然我也會一直維護着，不過我並無參與過其餘人發起的開源項目。

你最近遇到過的一個技術挑戰是什麼？怎麼解決的？

經過應聘者回答所遇到過的技術挑戰，其實從側面就能夠看出這我的的水平如何了。若是回答的技術挑戰是個簡單的問題，而在應聘者這裏倒是技術挑戰，那麼就能夠知道這水平是初級的。而後應聘者針對這個技術挑戰所給出的解決方案也能夠看出面對技術挑戰，能夠看出應聘者處理問題的能力。

參考答案：

最近公司項目中的用戶帳號出現被盜現象，緣由是通訊安全問題處理很差。由於公司的項目已是好幾年的老項目了，包括服務端的接口好可能是老接口，原來是沒有處理任何加密的，所以很容易被盜取帳號。如今咱們的技術VP要求針對這個問題，作一個版本。由於主動接受挑戰，因此這個重任落在了個人身上，由我來牽頭作好這個需求。

這真的是一個頗有挑戰性的技術項目。步驟以下：

須要調研市場上比較有名的App，他們是如何作好安全通訊問題的；

寫好技術文檔，將調研結果反饋出來並寫出本身的技術方案；

開初步技術方案評審會，會有VP及各組Leader參與，會上會提出各類問題，並給予一一解答，而後作會議記錄，會後繼續完善文檔；

開跨部分評審會，只有全部都經過了，才能立項。

技術立項，而後寫好各方向所須要作的工做文檔。

爲何要這麼麻煩？由於咱們既要兼容之前的全部版本，又要保證技術安全，那就不會本身就能說了算的，並且也不只僅是客戶端的問題。

今年你最想掌握的一門技術是什麼？爲何？目前已經作到了哪一個程度？

既然是技術，那麼就要說明是什麼技術，至於爲何想要掌握，固然是想要在技術上更上一層樓。

參考答案：

我如今一直在研究runtime相關知識。掌握runtime相關技術，能夠作不少正常狀態下作不到的事、可讓作一些自動化處理工做、解決代碼依賴問題等。目前已經對runtime中的成員變量、屬性、消息轉發、Swizzling等能夠熟練使用。關於runtime專題，你們能夠閱讀個人博客專題：iOS Runtime相關知識點

你通常是怎麼用Instruments的？

這個就是工做經驗的問題了。Instruments工具裏面有不少個選項，沒有必要每一個都答，其實筆者也只用過裏面的幾個而已。

參考答案：

使用Allocations來檢測內存和堆棧信息

使用Leaks檢測內存的使用狀況，包括內存泄露問題

使用Zombies來檢測過早釋放的殭屍對象，經過它能夠檢測出在哪裏崩潰的。

使用Time Profiler來檢測CPU內存使用狀況

你在你的項目中用到了哪些設計模式？

項目中使用了不少的設計模式，我相信面試官最好聽到的不只僅是設計模式的名字，更想聽到的是這些設計模式在項目中如何應用。所以，筆者認爲這個問題隱式地說明了應該回答設計模式及其在項目中的應用。

參考答案：

單例設計模式：在項目中，單例是必不可少的。好比UIApplication、NSUserDefaults就是蘋果提供的單例。在項目中常常會將用戶數據管理封裝成一個單例類，所以用戶的信息須要全局使用。

MVC設計模式：如今絕大部分項目都是基於MVC設計模式的，如今有一部分開發者採用MVVM、MVP等模式。

通知(NSNotification)模式：通知在開發中是必不可少的，對於跨模塊的類交互，須要使用通知；對於多對多的關係，使用通知更好實現。

工廠設計模式：在個人項目中使用了大量的工廠設計模式，特別是生成控件的API，都已經封裝成一套，所有是擴展的類方法，可簡化不少的代碼。

KVC/KVO設計模式：有的時候須要監聽某個類的屬性值的變化而作出相應的改變，這時候會使用KVC/KVO設計模式。在項目中，我須要監聽model中的某個屬性值的變化，當變化時，須要更新UI顯示，這時候使用KVC/KVO設計模式就很方便了。

就說這麼多吧，還有不少的設計模式，不過其它並非那麼經常使用。

如何實現單例，單例會有什麼弊端？

單例在項目中的是必不可少的，它可使咱們全局均可共享咱們的數據。這只是簡單的問題，你們根據本身的狀況回答。

參考答案：

首先，單例寫法有好幾種，一般的寫法是基於線程安全的寫法，結合dispatch_once來使用，保證單例對象只會被建立一次。若是不當心銷燬了單例，再調用單例生成方法是不會再建立的。

其次，因爲單例是約定俗成的，所以在實際開發中一般不會去重寫內存管理方法。

單例確實給咱們帶來的便利，可是它也會有代價的。單例一旦建立，整個App使用過程都不會釋放，這會佔用內存，所以不可濫用單例。

iOS是如何管理內存的？

我相信不少人的回答是內存管理的黃金法則，其實若是我是面試官，我想要的答案不是這樣的。我但願的回答是工做中如何處理內存管理的。

參考答案：

Block內存管理：因爲使用block很容易形成循環引用，所以必定要當心內存管理問題。最好在基類controller下重寫dealloc，加一句打印日誌，表示類能夠獲得釋放。若是出現無打印信息，說明這個類一直得不到釋放，代表頗有多是使用block的地方出現循環引用了。對於block中須要引用外部controller的屬性或者成員變量時，必定要使用弱引用，特別是成員變量像_testId這樣的，不少人都沒有使用弱引用，致使內存得不到釋放。

對於普通所建立的對象，由於如今都是ARC項目，因此記住內存管理的黃金法則就能夠解決。

使用過哪些第三方庫？

開發過App，若是回答說沒有使用過第三方庫，那麼這我的必定是剛入門。若是回答者可以說出不少有名的第三方庫，而且能說明使用場景，那麼能夠突出這個面試者的知識面仍是很廣的，這是能夠加分的

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個個人iOS交流羣：638302184，無論你是小白仍是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！

謝邀