前言
學如逆水行舟，不進則退吼畏。共勉督赤！
今天想跟大家分享一下當我們?nèi)ッ嬖囈粋€架構(gòu)師。會遇到什么問題泻蚊？team leader會更看重架構(gòu)師的那些特點躲舌。僅供參考學習，可互相討論性雄。畢竟不同的人有不同的想法没卸。
大致會有的幾種類型問題：
- 當前技術(shù)領域中的一些技術(shù)細節(jié)
- 算法和數(shù)據(jù)結(jié)構(gòu)
- 方案設計思路
我也會從以上幾個問題來分享自己的一些經(jīng)驗。
當前技術(shù)領域的技術(shù)細節(jié)類問題
針對第一類問題秒旋，我認為是很有必要問的约计，架構(gòu)師對技術(shù)細節(jié)的理解，是很能夠影響他做架構(gòu)時的設計思路的迁筛。畢竟每一個領域都有不同病蛉，了解不同領域的差異，以及特定領域的技術(shù)細節(jié)瑰煎，很影響架構(gòu)時的設計思路和實現(xiàn)手段。
然而俗孝，這并不是鼓勵大家去挖出各種細節(jié)的問題酒甸，然后去考察架構(gòu)師候選人，這里需要有一個度赋铝。舉個例子：
你如何去把一個view的所有subview清空插勤？
- 如果知道NSArray有makeObjectsPerformSelector這個方法的人，他們能夠說出直接使用這個方法革骨，然后在selector里面寫removeFromSuperView的selector农尖，就好了，而且很省事良哲，一句話就搞定盛卡。
- 如果知道NSArray有enumerator方法的人，他們會說出使用這種方法枚舉每一個subview筑凫，在block里把removeFromSuperView調(diào)用起來滑沧，也差不多兩三行的事兒并村。
- 不知道NSArray有上面這些方法的人，他會說用for...in...的方法遍歷滓技，然后取到這每一個subview哩牍，讓他們執(zhí)行removeFromSuperView×钇可能要花費大概四五行膝昆。
這幾種答案誰的更好？在我看來一樣好叠必。為什么荚孵？
因為這個問題其實考察的是這個人知不知道某個方法，當然你可以說他知道這個方法是因為他仔細看過文檔或者頭文件挠唆。但除了這個以外处窥，這個問題對判斷這個人是不是一個合格的架構(gòu)師沒有任何意義。架構(gòu)師的任務在于使用合理的手段完成架構(gòu)的任務玄组，上面三種做法都是合理的手段滔驾，只不過是實現(xiàn)技巧上的不同而已。
這樣的問題還可以拓展開來：你完全可以問一個架構(gòu)師候選人某一個領域的這種類似問題俄讹，而恰好你比他熟悉哆致，如果候選人答不上來，你會認為他可能在這方面花的時間還不夠患膛，這方面的理解不夠深摊阀，導致減分。但如果答上來了踪蹬，有可能加分有可能不加分胞此。
然而，這一切并沒有什么卵用跃捣。如果角色對調(diào)漱牵，讓候選人來面試你，他完全可以問出各種這樣類似的問題疚漆，一樣讓你抓耳撓腮百思不得其解酣胀。那么該如何考察一個架構(gòu)師候選人對自己領域中技術(shù)細節(jié)的理解呢？我們來看下面這些問題： 你覺得block當初是為了解決什么樣的問題而設計的娶聘？你如何區(qū)分何時使用block闻镶，何時不使用？\
你覺得ReactiveCocoa當初是為了解決什么樣的問題而設計的丸升？你何時會考慮使用RAC铆农，何時不用？\
你覺得MVVM這樣的思想是為了解決什么樣的問題而產(chǎn)生的狡耻？\
答案在本文不是重點顿涣，當然如果各位對答案感興趣波闹，可以在評論區(qū)問一下，我在評論區(qū)回答涛碑。在我遇到的各種面試官中精堕，我從來沒遇到過能問出這樣類似問題的面試官 。我面試別人的時候蒲障，我問過這種比較側(cè)重對某一項技術(shù)的理解的問題歹篓，有人能答好有人答不好，然后從招進來的人看揉阎，當初答好這種問題的人庄撮，后來都在團隊中起到了頂梁柱的作用。答不好這樣問題的人毙籽，但是他們因為知道很多技術(shù)細節(jié)洞斯，也還是招進來了，雖然也能很好地完成需求和任務坑赡，但是代碼結(jié)構(gòu)烙如、設計思路都會有或多或少的缺陷，寫出來的組件在使用上也會感覺怪怪毅否。
所以亚铁，考察一個架構(gòu)師候選人在某一領域的技術(shù)時，通用的技術(shù)細節(jié)的問題可以問一下螟加，偏門的技術(shù)細節(jié)問出來就很沒有意義徘溢。一個架構(gòu)師最關(guān)鍵的是他對技術(shù)的理解深度，理解深刻的人捆探，才能寫出簡單易用易拓展的架構(gòu)然爆。然后面試官需要區(qū)分好問題，有些問題是屬于“知道黍图、不知道”施蜜，有些問題是屬于“理解、不理解”雌隅，對于面試一個高級工程師來說，可能會比較偏向前者缸沃，因為他需要知道足夠多恰起，然后完成需求的速度才快，不需要總是去Google趾牧。但對于面試一個架構(gòu)師來說检盼，其實大部分基礎知識應該是已經(jīng)具備了的，不至于寫個TableView還要去翻Google翘单。但在做SDK的時候吨枉，是會遇到一些偏門問題的蹦渣，是需要去Google的。但架構(gòu)師跟高級工程師的區(qū)別就在于貌亭，架構(gòu)師知道該往哪個方向去Google柬唯，能夠把握住問題的實質(zhì)去解決問題。所以對于考察架構(gòu)師而言圃庭，應該更加偏向后者锄奢，理解和不理解。
回想一下剧腻，其實有很多類似知道拘央、不知道的問題，你是在code review中书在，其他人的博客中灰伟，文檔中就能學到的。但是那些理解儒旬、不理解的問題栏账，其實大部分都是你多年代碼的經(jīng)驗思考出來的，即便你去看了博客看了文檔义矛，該不理解的還是不理解发笔。而作為一名架構(gòu)師，真正要考察的就是理解凉翻、不理解的問題了讨。所以你明白，為什么當初那些技術(shù)細節(jié)答不上來的人制轰，但是對技術(shù)理解很深刻的人能成為頂梁柱前计，成為架構(gòu)師。而技術(shù)細節(jié)知道很多垃杖，但技術(shù)理解不深刻的人還是只能做高級工程師的原因了吧男杈？
算法和數(shù)據(jù)結(jié)構(gòu)類問題
第二類問題，算法和數(shù)據(jù)結(jié)構(gòu)相關(guān)的問題调俘。這種問題也是很需要問的伶棒，但似乎現(xiàn)在在社招的時候會問這種問題的面試官不太多，只有在面試比較初級的人或者應屆生的時候才會拿來問彩库。
我覺得面試官即便在面試架構(gòu)師的時候肤无，還是要問這樣的問題的，只是要注意考察側(cè)重點骇钦。一個架構(gòu)師如果不了解數(shù)據(jù)結(jié)構(gòu)和算法宛渐，那他真的很難做出靠譜的架構(gòu)，畢竟很多SDK底下充斥著各種各樣的數(shù)據(jù)結(jié)構(gòu)，而且有經(jīng)驗的人都很清楚窥翩，對于一類數(shù)據(jù)而言业岁，不同的結(jié)構(gòu)設計或表達方式，很影響最終實現(xiàn)的方案的優(yōu)雅程度寇蚊。所以我們面試架構(gòu)師時笔时，側(cè)重點在于，對于某個問題幔荒，你如何去選擇合適的數(shù)據(jù)結(jié)構(gòu)糊闽，合適的算法來解決這樣的問題。
但是爹梁，在面試應屆生時右犹，我們問算法和數(shù)據(jù)結(jié)構(gòu)問題時，其實更加關(guān)注的是他的動手能力姚垃，給一個很簡單的問題念链，然后讓他把代碼寫出來，或白板积糯，或IDE掂墓。就國內(nèi)大部分公司招聘的情況和其公司自身的情況來看，如果你學facebook／google那樣出算法題看成，你基本上招不到人进统。因為會這些題目的人柿估，都在facebook／google那兒排隊呢滤否。
然后算法和數(shù)據(jù)結(jié)構(gòu)相關(guān)的問題第二個考察點在于侣夷，候選人的思考是否足夠細密。這個不管是對架構(gòu)師候選人梦重，還是對應屆生還是對社招的高級工程師而言兑燥，重要程度都是一樣的。這個就不多說了琴拧。
你讓一名架構(gòu)師候選人在面試的時候做一個華容道算法降瞳，在你而言其實是對他的一種鄙視，在他而言他也很有可能寫不出蚓胸。但如果你讓一名架構(gòu)師候選人在面試時候展示他對各數(shù)據(jù)結(jié)構(gòu)的理解挣饥，不同場景下如何設計合理的數(shù)據(jù)結(jié)構(gòu)和算法，如何權(quán)衡時間與空間的取舍沛膳，這才是對他的一種重視扔枫。
方案設計思路類問題
第三類問題，方案設計思路于置。大概一年以前我在面試攜程的時候，遇到過面試官問我這種問題，其它我就沒有遇到過了八毯，一般都是我在自我介紹的時候主動挑一個去講搓侄。我在面試別人的時候，我也會問這樣的問題话速，比如說：
對于一個app的網(wǎng)絡層讶踪，你在設計時，你會考慮哪些問題泊交？\
對于一個app的持久層乳讥，如果讓你直接用sqlite，你如何設計版本遷移方案廓俭？\
工作中云石，你會采用哪些手段來做解耦？\
嚴格來說研乒，大部分面試官也會問這樣的問題汹忠，但是是看到你簡歷上寫過你有這個經(jīng)驗，然后直接問這個方案你是怎么做的雹熬，而不是問這個方案你是怎么設計的宽菜。在我看來，大部分方案的實現(xiàn)其實沒有什么技術(shù)含量竿报，真正有技術(shù)含量的地方在于铅乡，拿到這個問題時，你是如何思考的烈菌。就比如數(shù)據(jù)庫版本遷移方案阵幸，設計的過程是很艱苦的，但設計完畢實現(xiàn)的時候僧界，就是碼代碼侨嘀，不能說完全沒有技術(shù)含量，只能說實現(xiàn)的時候所需要耗費的腦力跟設計時候比捂襟，差太遠了咬腕，在我看來屬于沒有什么技術(shù)含量。
說到技術(shù)含量的事情葬荷，我也遇到過特別多的面試官喜歡問這個問題：過去你解決了哪些比較有技術(shù)含量的問題涨共？我一般不會拿這個問題去問候選人，因為我覺得真的到了代碼層面宠漩，是基本上不存在技術(shù)含量的概念的举反，碼代碼這個工作本身，就是用計算機能懂的方式告訴計算機應該怎么做事扒吁，其實就是一件很沒技術(shù)含量的事情火鼻。
所以我認為的技術(shù)含量是，你如何去設計一個靠譜的解決方案，這個解決方案足夠周密魁索，思考足夠長遠融撞，提供的API很好看，代碼很容易閱讀粗蔚，很好維護尝偎。
還有就是逃不掉的23種設計模式。設計模式這種東西早年被業(yè)界說了很多鹏控，都說爛了致扯，但我不否認的是，這種對設計方法的總結(jié)当辐，是每個架構(gòu)師的起步和入門抖僵。如果一個架構(gòu)師連什么場合使用設么設計模式都分不清楚，各種設計模式他的設計初衷和希望解決的問題都不知道瀑构，那他算是不合格的架構(gòu)師裆针。然而面試官也很少會去問這樣的問題，一方面可能覺得問這種問題很low寺晌，另一方面其實也有少部分面試官對設計模式僅僅處在了解和知道的情況世吨，不敢隨便拿出來問。
總結(jié)
面試架構(gòu)師其實是一件不容易的事情呻征，能考察架構(gòu)師候選人實力的面試官耘婚，首先自己就已經(jīng)對架構(gòu)本身有了很好的理解，就應該是一個合格的架構(gòu)師陆赋，其次是需要足夠務實沐祷，有合理的手段合理的問題，通過面試來了解候選人是不是一個適合做架構(gòu)師的人攒岛。最后赖临，要有足夠識人的眼光以及合適的判斷標準，通過候選人的回答灾锯，對候選人進行篩選兢榨。從我對目前面試的情況來看，對這個我持悲觀態(tài)度顺饮。大部分面試官給候選人的感覺更多的是：我問你一個這個問題吵聪，看你知不知道？而不是：我問你一個這個問題兼雄，看你怎么去思考吟逝？
架構(gòu)師和更高級的高級工程師之間，還是有區(qū)別的赦肋。所以各家公司如果要想找到合理靠譜的架構(gòu)師块攒，還是很不容易的励稳。
更多iOS進階書籍資料，請關(guān)注個人資料囱井。
