自我介紹
自我介紹時，一定要簡潔明了，不要長篇大論。以我個人而言，最不喜歡自我介紹說了一大堆，最后連她/他叫什么名字都沒記住。
參考答案：
自我介紹時，突出重點，說話慢一些，在關鍵點聲音大一點。本人回答時，就簡單地說： 我叫某某某，做iosX年了，曾在XX公司擔任過XX職務，在YY公司擔任過XX職務，主要負責ZZ工作。業(yè)余喜歡做NN(要說積極點的)，擅長LL(把自己的特長說明白)等。
最近這兩天你有學到什么知識/技能么?
對于這個問題，面試官肯定知道作為求職者，這兩天肯定是在忙于找工作、面試。那么，面試官問出這樣的問題的目的是什么?如果我是面試官，我最想了解的是這兩天你為此次面試準備了什么而不僅僅是告訴面試官這兩天學習了某一方面的知識。
參考答案：
這兩天為了準備面試，整理了以前所做過的一些項目的筆記，回頭看了看以前的工作日志。一來是整理一些在工作中經(jīng)常遇到的坑，比如cell重用問題、ios6適配問題等;二來是回頭告別過去的自己，在思想上、技術上迎來全新的自我;三來定位自己下一個目標：往架構師方向深入研究。
最近有做過比較酷或者比較有挑戰(zhàn)的項目么?
這個問題的關鍵是酷和挑戰(zhàn)。其實這里所說的酷對應于開發(fā)中的動畫，而挑戰(zhàn)則對應于開發(fā)中的沖刺。對于筆者而言，其實并沒有做過特別酷的項目，但是做過有挑戰(zhàn)性的項目。但是沒有做過并不是就不用回答，面試官想看到的是你的學習能力、應用能力以及解決問題的能力，而不是一句沒做過或者沒什么挑戰(zhàn)性這樣的話語。
參考答案：
我之前所負責的項目大多是電商項目，因此并不會特別酷，但是業(yè)務比較多，很有技術挑戰(zhàn)性。不過，平時我也深入研究過ios核心動畫相關知識，對于常用的動畫是很熟悉的。在我看來，用戶體驗并不是所謂的酷，而是簡單、方便且明了。我很在意用戶體驗問題，在開發(fā)中會不斷地站在用戶的角度地問自己用戶討厭什么、喜歡什么和怎樣才能讓用戶感覺容易上手且使用簡單等問題。比如，我會很在意網(wǎng)絡狀態(tài)的變化給用戶的提示、請求網(wǎng)絡時右上角的轉圈圈是否開啟、滾動cell時是否有卡頓的問題等。
我待過幾家公司，從一個人開發(fā)到帶領團隊，從小公司到大公司，因此對于不同的公司對項目的要求完全不一樣。對于大公司，一般項目管理機制相對比較完善，而且會有比較多經(jīng)驗豐富的技術VP，因此對于工作的要求比較高，對于用戶的體驗及反饋會非常地關注;而對于一些小公司，可能就一個人在開發(fā)，而這個人往往是菜鳥的多，因此都是東拼西湊而形成的項目，技術不成熟、水平不夠，而且還被壓著不斷加班，因此幾乎不會過多關注用戶體驗問題，當然這樣項目也不會有什么好的構架(初創(chuàng)技術合伙人除外)。
現(xiàn)在我所在的公司不算大，也就1000+號人，而做ios也才40號人左右。本公司是按業(yè)務方向劃分成多個團隊，不同團隊開發(fā)不同的業(yè)務需求，因此這樣就面臨技術架構問題、安全問題、團隊開發(fā)如何做到互不干擾等問題了。而我在團隊中的主要職責是處理團隊之間沖突的問題、如何代碼模塊化以減少團隊之外的依賴問題、移動端安全通信問題、項目存儲安全問題、公共框架等問題，這一系列都是非常有技術挑戰(zhàn)的，需要花費很多非工作時間去調研、寫demo、寫文檔等
最近看過的書/文章有哪些?
詢問最近看過的書或者文章，其實通過所回答的書的性質差不多就可以猜出當前狀態(tài)下應聘者的技術水平大致處于什么樣的水準了。下面的參考答案是筆者的常態(tài)。
參考答案：
最近在看《iOS應用逆向工程》、《The Swift Programming Language》。不過本人更喜歡的是閱讀博客文章和官方文檔，雖然官方文檔是英文的，閱讀起來相對要費勁一些，但是一方面可以提高英文閱讀能力，另一方面英文原版表達的語義才是最準確的，其他翻譯過來的文章會有一些變味之處。
為什么要學習編程，編程對你而言的樂趣在哪兒?
這樣的話題在很多社區(qū)都出現(xiàn)過，其實問這樣的問題只是想知道應聘者的態(tài)度而已。通過應聘者的回答，一方面可初步了解應聘者對編程的認知程度，另一方面可從應聘者口出得出編程對于應聘者而言是什么樣的態(tài)度。下面是結合筆者的事跡寫下的參考答案，僅供參考。
參考答案：
說到這個問題，我曾經(jīng)也問過自己為什么要學習編程�；叵氘斈旮呖冀Y果出來的時候，需要選擇學校和專業(yè)的時候是很迷茫的，不知上大學應該學點什么。后來，我選擇了計算機科學與技術專業(yè)，并為了這個專業(yè)而選擇學校。由于高考考得不好，雖然超過一本線，但是高不成低不就，很多高校的計算機專業(yè)要求總分達到560(當時一本線是502分)左右才能穩(wěn)拿到這個專業(yè)，而我才考了526分，想想計算機專業(yè)很強的高校是很難進的。于是選擇了從廣西到沈陽這么遙遠的地方上學，竟然是為了計算機專業(yè)，現(xiàn)在回想起來還自己偷笑。
在大學的時候，大一天天在圖書館提前學習編程，因為動手能力突出，到大二的時候有好多教計算機的老師提前知道了這樣的我，感謝他們的認可，在大學這幾年，是他們引導我如何編程實戰(zhàn)。大學的時候做過很多PC端的軟件(.net開發(fā)的)、給老師做過教程網(wǎng)站(ASP.net開發(fā)的)、參加學習的ACM訓練等等，一切的一切，都要感謝那些教導我的恩師們。
后來通過學長了解到未來就業(yè)的一些動向，了解到畢業(yè)后如何找工作，學習了iOS開發(fā)，于是越來越愛她了。如果非要說編程的樂趣在哪里，我想說在討論技術的時候就像和同學、朋友一起玩LOL的時候;在解決掉一個別人解決不了的bug的時候，那是一種想要向全世界大聲說：YES,I Can;當我們與技術總監(jiān)并肩作戰(zhàn)，一起為了項目上線熬夜，總監(jiān)為我們買夜宵一起吃的時候，那就是兄弟情誼，那會有種相見恨晚的感覺。
如果一個函數(shù)10次中有7次正確，3次錯誤，問題可能出現(xiàn)在哪里?
這樣的問題通過應聘者的分析，可以知道應聘者的功底如何。很多人的回答會是很簡單的，沒有從多方面去分析。這樣的問題也是很有意義的，在項目開發(fā)中所產(chǎn)生的bug，有的時候會出現(xiàn)這樣的情況，而代碼量比較大且業(yè)務比較復雜時，通過其他工具并不能分析出來是什么bug，但是我們卻可以根據(jù)出現(xiàn)的頻率推測。筆者把這個問題當作測試部反饋過來的bug描述問題來分析一下。
參考答案：
從問題描述可知，bug不會必現(xiàn)的，因此無法直接定位出錯之處。從以下角度出現(xiàn)來分析可能出錯之處：
因出錯并不是崩潰，因此沒有錯誤日志可看。第一步就是分析函數(shù)中的所有分支，是否在語法上存在可能缺少條件的問題。所以，檢查所有的分支，確保每個分支執(zhí)行的結果的正確的
檢測函數(shù)的參數(shù)，保證必傳參數(shù)不能為空，若為空應該拋出異常。因此，用斷言檢測參數(shù)的正確性是很重要的。
檢測函數(shù)中每個分支所調用的函數(shù)返回結果是正確的，其實就是一個遞歸的過程(步驟1、2)