2018年 iOS 面試心得

時間 2019-11-05

標籤 2018年 ios 面試心得欄目 iOS 简体版

原文原文鏈接

面試了幾家公司以後，最後來到了愛奇藝（座標上海），工做的內容是筆者我的很是感興趣的領域。能拿到這個結果對於入行兩年半&非科班的筆者來講無疑是幸運的。前端

很感謝面試官給我此次機會，由於並非全部人都會承認你的努力，生活原本就沒有任何理所應當。git

具體的面了哪些公司，有哪些面試題在這裏就不分享了，由於感受借鑑意義並非很大。程序員

面了哪些公司仍是不方便在這裏公開的。
這幾家公司的面試題相差並不大，主要仍是須要重視答題質量；並且即使是同一個面試官，在面對不一樣面試者的時候問的問題也極可能不同，由於極可能受到答題者的回答影響會問一些計劃以外的題，這點我在做面試官的時候有體會。

面試題方面筆者會專門在下一篇出一套本身認爲能夠用來面試高級 iOS 的面試題，連接：出一套 iOS 高級面試題github

本篇主要分享的是筆者在這階段是如何準備面試的。可能每一個人都有適合本身的學習方法，筆者的這套方法更談不上十分高效，但仍是但願對你們能夠有必定的借鑑意義。面試

準備面試

準備面試主要從三個點展開：算法

使用的工具
面試題的整理
時間管理

使用的工具

在準備面試的過程當中使用頻率最多的工具備兩個：編程

有道筆記
奇妙清單

1. 有道筆記

用途1：用來收集知識源：有道筆記瀏覽器插件能夠一鍵快速保存網頁，也能夠收藏公衆號的文章。
用途2：用來整理面試題：支持多級文件夾，能夠清晰看到知識結構；支持MarkDown，能夠保存代碼。

筆記的整理過程就是理解的過程，反覆咀嚼本身的筆記能夠幫助理解。設計模式

2. 奇妙清單

用途1：用來記錄忽然想到的問題點：有的時候可能在頭腦出蹦出一個問題來，可是沒辦法馬上想出答案。這時候須要在一個本身熟悉的位置保存一下。
用途2：羅列如今爲止沒有攻克的面試題：能夠更直觀地看到距離複習完成還有多少任務。

清單這種工具是爲了解放大腦，由於大腦是用來思考的，不是用來記憶的。把須要惦記的事情先扔進去，讓大腦脫離出來~數組

這兩個工具還有一個很是大的優點就是跨平臺：都支持（Mac，Windows，Android，iOS）系統，同步的功能作的也都很好。因此使用它們能夠在不方便用電腦的時候隨時更新，特別是有一個好想法的時候能夠立刻在手機上記下來。瀏覽器

面試題的整理

面試題分類

筆者儘量蒐羅了網上全部的iOS面試題，難度從低到高，固然也有介紹某個知識點的一些文章。筆者將這些題彙總之後分紅了幾個主題放在了有道筆記裏面：

iOS 基礎題：例如「KVO的實現原理？」等等。
iOS 應用題：例如「可能致使崩潰的幾個緣由以及如何避免崩潰？」等等。
Block：例如：「基本類型的變量和對象被__block修飾與否各有什麼區別？」等等。
RunLoop：例如「利用RunLoop能夠實現哪些功能？」等等。
Runtime：例如「從一個對象收到一個它沒法響應的方法到崩潰之間發生了什麼？」等等。
網絡：例如「HTTPS的握手流程？」等等。
多線程：例如「線程同步的幾個策略？知道哪幾種鎖及其它們以前區別？」等等。
計算機系統：例如「內存的幾塊區域以及職能？」等等。
設計模式：「iOS SDK裏面有哪些設計模式的實踐？」等等。
架構：例如「MVVM和MVP的區別？」等等。
數據結構：例如「哈希表的實現原理？如何解決衝突？」等等。

算法題的準備

最後還要說一下算法題：筆者由於沒有算法方面的基礎，並且時間上也比較緊，因此只准備了數組，鏈表，二叉樹爲主的算法題，語言是C++。這些題目的來源主要是《劍指offer》和LeetCode上面的題目，一共學習了大概一個月的時間。

筆者把已經掌握的算法題放在了個人GitHub庫上面（有答案，並且都是正確的）：awesome-algorithm-question-solution。這個庫裏面的算法題大部分都是移動端面試比較常考的算法題。

目前都基於C++語言，有興趣的同窗歡迎提交Java和Swift的答案。

時間管理

好的時間管理策略能夠更好地幫助計劃的落地。在這裏從兩個點來介紹筆者的時間管理策略：

天天都作哪些事情
不作哪些事情

天天都作哪些事情

由於當時在職的關係準備面試的時間比較有限，可是天天對不一樣類型的知識點都有比較固定比例的時間分配：

類型一：全新的知識點。這類知識點是天天都要看的，由於對於新知識須要時間去消化和吸取。所分配的時間大概佔一天總學習時間的一半左右。
類型二：不熟悉的知識點。這類知識點是指那些剛理解好的全新的知識點或者比較難以理解的，須要反覆看和消化的知識點。大概佔一天總學習時間的一半之內。
類型三：很熟悉的知識點。這部分知識點屬於理解的比較透徹的，但也須要抽時間複習，是這部分時間佔比不是很重，簡單掃一眼便可。

另外還要費分配出整理知識點的時間：對於上面這三種知識點其實都須要反覆的整理和吸取，嘗試着用本身的話表示出來，須要的時間佔比也不是很重，可是卻頗有用。

不作哪些事情

在時間管理這塊，筆者我的比較贊同的一個觀點是：比起知道作什麼，首先知道不作什麼更重要。由於人的精力是有限的，一天就只有24個小時，當某件事很重要的時候，其餘的事情就要作個讓步。

爲了準備面試，筆者在今年上半年放棄了不少事情：

健身卡雖然快過時了，可是一次都沒有去。
同窗，家人聚會也婉言謝絕了。
沒有玩兒「吃雞」，也沒有去過電影院。

坦白說在筆者拿到offer之後纔去了健身房，和同窗家人聚會，也見了老朋友，算是都補上了。他們也都表示比較理解，因此筆者也感受也蠻欣慰的。

找一份工做並不難，可是找一份目前最適合本身的工做卻很是難，但願你們也可以作一些取捨，列好計劃並付諸實踐，應該是會有好的結果的。

簡單講完了這階段的面試經歷和準備面試的方法策略，下面說一下筆者對一些同行的某些想法想說的。由於這些也包括這上半年面試別人和本身去面試體會到的，因此在這裏就和麪試心得一塊兒說了。某些地方可能有些主觀。

對一些同行的某些想法想說的

「行業不景氣了」

這句話每月都會聽到一兩次。今年上半年不少朋友在面試，可能由於有些朋友不是很順利，有感而發了。並且筆者上半年也在給公司招人，招的是高級 iOS 開發，有一個感受就是很難招。雖然年限已經有3，4年了，可是關於設計模式，數據結構，iOS 底層方面的知識瞭解的甚少，開源庫也只看過SDWebimage（或許只是看了網上的解析而已），總之沒有達到筆者我的對一個高級 iOS 開發的要求。

可是反過來我也聽到好多人去了很不錯的公司，好比今日頭條，BAT等等，評級也比較高。

因此筆者我的以爲並非這個行業不景氣，而偏偏是不少開發者沒有保持一個持續學習的狀態，只是將一年的經驗重複多年，最終致使本身的能力小於所屬年限的能力標準的狀況出現。

筆者認爲既然作爲一名軟件開發人員，就要不斷地突破本身。對於前端的開發人員，要儘量地多學一些脫離UI層面上的通用性的知識，好比數據結構和算法，網絡協議，設計模式，看一些好的開源庫也是不錯的（上半年面試了很多於10我的，問看過哪些開源庫沒有一個不說SDWebImage的）。在這裏推薦筆者以前寫的一些源碼解析的博客：

「由於我學歷很差，因此很難拿到面試機會」

這些話在跟我比較熟的同行裏面聽到比較多，他們以爲本身的面試機會受限於學歷。

但其實簡歷上面能夠吸引人的地方能夠有不少：高質量的博客，高質量的Github代碼，優秀的項目經驗，有深度的技術分享等等。

有句話筆者我的很是喜歡：

Alter what is changeable, and accept what is immutable

意思是改變能改變的，接收不能改變的。學歷既然很難改變了，那就接受它，不去抱怨，不去拿它當藉口，應該把精力放在能改變的事情上：

博客：如今本身搭建博客都是很容易的事情，有現成的框架（hexo），學習成本很低，若是你有必定的技術積累能夠在這裏作一下介紹。
GitHub：這個就不用介紹了，若是你封裝了好用的組件就能夠放在上面，不斷更新優化，能體現出我的的成長。若是能參與大型的開源項目就更好了。
項目經驗：這個可能也是我的沒法掌控的，可是你能夠將某個功能點作到極致不是麼？
技術分享：若是你研究了一個新技術，是否能夠給同事們分享一下呢？同時也能夠鍛鍊下本身。

筆者我的是比較看重1，2點的：從這兩點能夠看出這我的對技術的追求，是否熱衷於分享，是否有比較好的表達能力和思路。而3，4點因爲客觀方面的影響比較多一些，因此相對來講筆者我的並非很側重。

筆者看到過一項調查：相對來講學歷越高，畢業學校越好的開發者每每在GitHub和博客上面產出更多。這不失爲一個值得思考的問題，同時也更加說明了學歷和畢業學校相對來講不是那麼太靠前的開發者更要注重GitHub和博客這兩塊。

「（大公司）面試造火箭，工做擰螺絲。」

這句話也聽過很多次了，能聽出來講這句話的人多數帶着些許負面情緒說的。

筆者我的認爲大公司的這種招人策略是很是道理的：由於既然是大公司，有豐富的資源，它要麼是正在造火箭，要麼就是準備造火箭，因此招人的話確定是招那些已經具有造火箭能力的人或者是那些培養以後能夠造火箭的基礎比較好的人。並且萬丈高樓平地起，總不會你們都是圍着設計圖討論吧？每一個人都有每一個人的職責，何況哪一個將領不是從士兵開始作起的呢？

因此咱們應該以正確的態度去對待這件事情：

若是你真的想進大公司，那麼就削尖了腦殼，好好準備底層知識和算法題去爭取：拿到offer最好，就算拿不到也確定會有收穫，畢竟你努力了，你也切身體會了一次大公司的要求。
若是你真的不想進大公司，那麼就儘可能不要去惦記這件事情，更不要去傳播這種負面情緒。
若是你還沒肯定要不要去大公司，那麼最好如今就定一下方向，方向有了計劃纔會有，計劃有了纔會有成果出來。

「這部分工做中我沒遇到過，因此不瞭解」

今年上半年也爲公司招了人，上面這句話是筆者作面試官的時候常常聽到的，好比問「NSSet和NSArray的區別」，「iOS有哪些反射實踐？」這樣的問題的時候，面試者一般把本身沒有作過做爲本身不會的藉口。

其實筆者以爲上面這兩個知識點和作沒作過相應業務沒有太直接的關係（筆者本人在實際項目中也沒有作過）。

對於第一個問題，若是你學習了哈希表，並順帶去了解其在iOS SDK的實現，或者是調研過除了數組，字典之外的其餘集合類的話，就必定會遇到NSSet。再或者你若是看過AFNetworking的源碼的話也能夠接觸到它。
對於第二個問題，若是你知道Java中有反射的概念，那麼你若是觸類旁通去探索iOS的反射的話，就能夠知道使用運行時的一些函數就能夠實現反射。

因此說不管學習哪一個語言，若是能夠從一些通用性知識點裏探索出該語言對該知識點的實現的話，會更有助於加深對該語言自己的理解，也能夠提升相應的業務能力：

比方說若是你僅僅須要一個集合，未來只須要判斷元素在不在其中的話，你只須要用NSSet就行了；可是若是你不知道NSSet的存在的話，你可能就只會用NSArray來作，要知道數組的查詢速度是要比哈希表低的多的。

因此說作學問最怕的是不知道本身不知道：多接觸，多探索總仍是好的。

「我不是科班的，因此數據結構和算法我不會」

筆者做面試官的時候發現：在非科班的羣體裏想主動學習數據結構和算法的人並非不少。由於每當筆者問一些關於數據結構和算法方面的知識的時候，總會聽到以本身不是科班出身做爲不會這類題的藉口。

筆者認爲若是想要在寫程序這條路上面走遠，這一塊是確定繞不過去的。有一個公式：

程序 = 數據結構 + 算法

一個好的程序每每跟這二者是分不開的。便是說若想寫出好的程序，就要選擇好合理的數據結構和算法（至少也要選擇正確的數據結構）。

舉一個例子：如今須要你用一個集合來保存一些人名，並提供一個接口來判斷傳入的人名是否在這個集合裏。那麼若是讓你來實現這個功能，這個集合的數據結構你會用數組，字典，仍是Set呢？

若是你不瞭解Set的優點，那麼你極可能就會用數組來作了（經過返回的index來判斷）。可是數組查詢的時間複雜度是O(N),遠不如Set的O(1)，因此這就說明了使用合適的數據結構對於性能的幫助會有多大。

筆者也不是科班出身的，可是學習了數據結構和算法以後，發現本身在設計功能，以及理解代碼的能力上提升了一大截。像上文所說的筆者也只是掌握了30到LeetCode題，和一些比較基礎的數據結構而已。因此很但願各位非科班的同窗也能夠好好規劃本身這一塊的學習。並且有一些科班出身的同窗，偏偏由於本身是科班出身，因此在工做以後反而就沒有主動去精進這方面知識了，因此非科班的同窗更要主動去規劃本身，以最快速度填補本身的這塊漏洞。

以上就是筆者這段時間的一些思考和想法了。

這篇總結就在這裏寫完了，一共兩個部分，但願您能有所收穫，也很是歡迎能跟我一塊兒交流~

本篇已同步到我的博客：2018年iOS 面試心得

筆者在近期開通了我的公衆號，主要分享編程，讀書筆記，思考類的文章。

編程類文章：包括筆者之前發佈的精選技術文章，以及後續發佈的技術文章（以原創爲主），而且逐漸脫離 iOS 的內容，將側重點會轉移到提升編程能力的方向上。
讀書筆記類文章：分享編程類，思考類，心理類，職場類書籍的讀書筆記。
思考類文章：分享筆者平時在技術上，生活上的思考。