自我介紹

　　自我介紹時(shí)，一定要簡潔明了，不要長篇大論。以我個(gè)人而言，最不喜歡自我介紹說了一大堆，最后連她/他叫什么名字都沒記住。

　　參考答案：

　　自我介紹時(shí)，突出重點(diǎn)，說話慢一些，在關(guān)鍵點(diǎn)聲音大一點(diǎn)。本人回答時(shí)，就簡單地說： 我叫某某某，做iosX年了，曾在XX公司擔(dān)任過XX職務(wù)，在YY公司擔(dān)任過XX職務(wù)，主要負(fù)責(zé)ZZ工作。業(yè)余喜歡做NN(要說積極點(diǎn)的)，擅長LL(把自己的特長說明白)等。

　　最近這兩天你有學(xué)到什么知識(shí)/技能么?

　　對(duì)于這個(gè)問題，面試官肯定知道作為求職者，這兩天肯定是在忙于找工作、面試。那么，面試官問出這樣的問題的目的是什么?如果我是面試官，我最想了解的是這兩天你為此次面試準(zhǔn)備了什么而不僅僅是告訴面試官這兩天學(xué)習(xí)了某一方面的知識(shí)。

　　參考答案：

　　這兩天為了準(zhǔn)備面試，整理了以前所做過的一些項(xiàng)目的筆記，回頭看了看以前的工作日志。一來是整理一些在工作中經(jīng)常遇到的坑，比如cell重用問題、ios6適配問題等;二來是回頭告別過去的自己，在思想上、技術(shù)上迎來全新的自我;三來定位自己下一個(gè)目標(biāo)：往架構(gòu)師方向深入研究。

　　最近有做過比較酷或者比較有挑戰(zhàn)的項(xiàng)目么?

　　這個(gè)問題的關(guān)鍵是酷和挑戰(zhàn)。其實(shí)這里所說的酷對(duì)應(yīng)于開發(fā)中的動(dòng)畫，而挑戰(zhàn)則對(duì)應(yīng)于開發(fā)中的沖刺。對(duì)于筆者而言，其實(shí)并沒有做過特別酷的項(xiàng)目，但是做過有挑戰(zhàn)性的項(xiàng)目。但是沒有做過并不是就不用回答，面試官想看到的是你的學(xué)習(xí)能力、應(yīng)用能力以及解決問題的能力，而不是一句沒做過或者沒什么挑戰(zhàn)性這樣的話語。

　　參考答案：

　　我之前所負(fù)責(zé)的項(xiàng)目大多是電商項(xiàng)目，因此并不會(huì)特別酷，但是業(yè)務(wù)比較多，很有技術(shù)挑戰(zhàn)性。不過，平時(shí)我也深入研究過ios核心動(dòng)畫相關(guān)知識(shí)，對(duì)于常用的動(dòng)畫是很熟悉的。在我看來，用戶體驗(yàn)并不是所謂的酷，而是簡單、方便且明了。我很在意用戶體驗(yàn)問題，在開發(fā)中會(huì)不斷地站在用戶的角度地問自己用戶討厭什么、喜歡什么和怎樣才能讓用戶感覺容易上手且使用簡單等問題。比如，我會(huì)很在意網(wǎng)絡(luò)狀態(tài)的變化給用戶的提示、請(qǐng)求網(wǎng)絡(luò)時(shí)右上角的轉(zhuǎn)圈圈是否開啟、滾動(dòng)cell時(shí)是否有卡頓的問題等。

　　我待過幾家公司，從一個(gè)人開發(fā)到帶領(lǐng)團(tuán)隊(duì)，從小公司到大公司，因此對(duì)于不同的公司對(duì)項(xiàng)目的要求完全不一樣。對(duì)于大公司，一般項(xiàng)目管理機(jī)制相對(duì)比較完善，而且會(huì)有比較多經(jīng)驗(yàn)豐富的技術(shù)VP，因此對(duì)于工作的要求比較高，對(duì)于用戶的體驗(yàn)及反饋會(huì)非常地關(guān)注;而對(duì)于一些小公司，可能就一個(gè)人在開發(fā)，而這個(gè)人往往是菜鳥的多，因此都是東拼西湊而形成的項(xiàng)目，技術(shù)不成熟、水平不夠，而且還被壓著不斷加班，因此幾乎不會(huì)過多關(guān)注用戶體驗(yàn)問題，當(dāng)然這樣項(xiàng)目也不會(huì)有什么好的構(gòu)架(初創(chuàng)技術(shù)合伙人除外)。

　　現(xiàn)在我所在的公司不算大，也就1000+號(hào)人，而做ios也才40號(hào)人左右。本公司是按業(yè)務(wù)方向劃分成多個(gè)團(tuán)隊(duì)，不同團(tuán)隊(duì)開發(fā)不同的業(yè)務(wù)需求，因此這樣就面臨技術(shù)架構(gòu)問題、安全問題、團(tuán)隊(duì)開發(fā)如何做到互不干擾等問題了。而我在團(tuán)隊(duì)中的主要職責(zé)是處理團(tuán)隊(duì)之間沖突的問題、如何代碼模塊化以減少團(tuán)隊(duì)之外的依賴問題、移動(dòng)端安全通信問題、項(xiàng)目存儲(chǔ)安全問題、公共框架等問題，這一系列都是非常有技術(shù)挑戰(zhàn)的，需要花費(fèi)很多非工作時(shí)間去調(diào)研、寫demo、寫文檔等

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

　　詢問最近看過的書或者文章，其實(shí)通過所回答的書的性質(zhì)差不多就可以猜出當(dāng)前狀態(tài)下應(yīng)聘者的技術(shù)水平大致處于什么樣的水準(zhǔn)了。下面的參考答案是筆者的常態(tài)。

　　參考答案：

　　最近在看《iOS應(yīng)用逆向工程》、《The Swift Programming Language》。不過本人更喜歡的是閱讀博客文章和官方文檔，雖然官方文檔是英文的，閱讀起來相對(duì)要費(fèi)勁一些，但是一方面可以提高英文閱讀能力，另一方面英文原版表達(dá)的語義才是最準(zhǔn)確的，其他翻譯過來的文章會(huì)有一些變味之處。

　　為什么要學(xué)習(xí)編程，編程對(duì)你而言的樂趣在哪兒?

　　這樣的話題在很多社區(qū)都出現(xiàn)過，其實(shí)問這樣的問題只是想知道應(yīng)聘者的態(tài)度而已。通過應(yīng)聘者的回答，一方面可初步了解應(yīng)聘者對(duì)編程的認(rèn)知程度，另一方面可從應(yīng)聘者口出得出編程對(duì)于應(yīng)聘者而言是什么樣的態(tài)度。下面是結(jié)合筆者的事跡寫下的參考答案，僅供參考。

　　參考答案：

　　說到這個(gè)問題，我曾經(jīng)也問過自己為什么要學(xué)習(xí)編程�；叵氘�(dāng)年高考結(jié)果出來的時(shí)候，需要選擇學(xué)校和專業(yè)的時(shí)候是很迷茫的，不知上大學(xué)應(yīng)該學(xué)點(diǎn)什么。后來，我選擇了計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)，并為了這個(gè)專業(yè)而選擇學(xué)校。由于高考考得不好，雖然超過一本線，但是高不成低不就，很多高校的計(jì)算機(jī)專業(yè)要求總分達(dá)到560(當(dāng)時(shí)一本線是502分)左右才能穩(wěn)拿到這個(gè)專業(yè)，而我才考了526分，想想計(jì)算機(jī)專業(yè)很強(qiáng)的高校是很難進(jìn)的。于是選擇了從廣西到沈陽這么遙遠(yuǎn)的地方上學(xué)，竟然是為了計(jì)算機(jī)專業(yè)，現(xiàn)在回想起來還自己偷笑。

　　在大學(xué)的時(shí)候，大一天天在圖書館提前學(xué)習(xí)編程，因?yàn)閯?dòng)手能力突出，到大二的時(shí)候有好多教計(jì)算機(jī)的老師提前知道了這樣的我，感謝他們的認(rèn)可，在大學(xué)這幾年，是他們引導(dǎo)我如何編程實(shí)戰(zhàn)。大學(xué)的時(shí)候做過很多PC端的軟件(.net開發(fā)的)、給老師做過教程網(wǎng)站(ASP.net開發(fā)的)、參加學(xué)習(xí)的ACM訓(xùn)練等等，一切的一切，都要感謝那些教導(dǎo)我的恩師們。

　　后來通過學(xué)長了解到未來就業(yè)的一些動(dòng)向，了解到畢業(yè)后如何找工作，學(xué)習(xí)了iOS開發(fā)，于是越來越愛她了。如果非要說編程的樂趣在哪里，我想說在討論技術(shù)的時(shí)候就像和同學(xué)、朋友一起玩LOL的時(shí)候;在解決掉一個(gè)別人解決不了的bug的時(shí)候，那是一種想要向全世界大聲說：YES,I Can;當(dāng)我們與技術(shù)總監(jiān)并肩作戰(zhàn)，一起為了項(xiàng)目上線熬夜，總監(jiān)為我們買夜宵一起吃的時(shí)候，那就是兄弟情誼，那會(huì)有種相見恨晚的感覺。

　　如果一個(gè)函數(shù)10次中有7次正確，3次錯(cuò)誤，問題可能出現(xiàn)在哪里?

　　這樣的問題通過應(yīng)聘者的分析，可以知道應(yīng)聘者的功底如何。很多人的回答會(huì)是很簡單的，沒有從多方面去分析。這樣的問題也是很有意義的，在項(xiàng)目開發(fā)中所產(chǎn)生的bug，有的時(shí)候會(huì)出現(xiàn)這樣的情況，而代碼量比較大且業(yè)務(wù)比較復(fù)雜時(shí)，通過其他工具并不能分析出來是什么bug，但是我們卻可以根據(jù)出現(xiàn)的頻率推測(cè)。筆者把這個(gè)問題當(dāng)作測(cè)試部反饋過來的bug描述問題來分析一下。

　　參考答案：

　　從問題描述可知，bug不會(huì)必現(xiàn)的，因此無法直接定位出錯(cuò)之處。從以下角度出現(xiàn)來分析可能出錯(cuò)之處：

　　因出錯(cuò)并不是崩潰，因此沒有錯(cuò)誤日志可看。第一步就是分析函數(shù)中的所有分支，是否在語法上存在可能缺少條件的問題。所以，檢查所有的分支，確保每個(gè)分支執(zhí)行的結(jié)果的正確的

　　檢測(cè)函數(shù)的參數(shù)，保證必傳參數(shù)不能為空，若為空應(yīng)該拋出異常。因此，用斷言檢測(cè)參數(shù)的正確性是很重要的。

　　檢測(cè)函數(shù)中每個(gè)分支所調(diào)用的函數(shù)返回結(jié)果是正確的，其實(shí)就是一個(gè)遞歸的過程(步驟1、2)