? ? ?其實本文想說的是：當(dāng)面試一個架構(gòu)師的時候恼蓬，我們應(yīng)該問什么問題？我覺得淮捆，問什么樣的問題攀痊，體現(xiàn)了team leader更加看重架構(gòu)師的哪些特點苟径。
? ? ? 我一直認(rèn)為棘街，做技術(shù)就跟練武一樣承边，在練武的不同階段，分招式和心法险污。技術(shù)也一樣拯腮，在不同的階段蚁飒，也分招式和心法狼电。另外肩碟，就我個人而言削祈，經(jīng)常忘記招式髓抑，一方面可以說十二年來，我用過的招式很多优幸，到了現(xiàn)在也不記得幾個吨拍。另一方面我自己也不會特意去記。事實上网杆，十二年代碼寫下來羹饰，我反而越來越不關(guān)注招式，而是越來越關(guān)注如何解決問題碳却，也就是心法队秩。所以我作為team leader的時候，我會更加看重這個架構(gòu)師候選人是不是有一套屬于自己的心法昼浦。
上面說的聽著很玄馍资，下面我就直接回到正題：我們面試架構(gòu)師候選人時，應(yīng)該問什么樣的問題？
大致會有幾種類型的問題：
當(dāng)前技術(shù)領(lǐng)域中的一些技術(shù)細(xì)節(jié)
算法和數(shù)據(jù)結(jié)構(gòu)
方案設(shè)計思路
當(dāng)前技術(shù)領(lǐng)域的技術(shù)細(xì)節(jié)類問題
針對第一類問題锦针，我認(rèn)為是很有必要問的，架構(gòu)師對技術(shù)細(xì)節(jié)的理解，是很能夠影響他做架構(gòu)時的設(shè)計思路的绍哎。畢竟每一個領(lǐng)域都有不同，了解不同領(lǐng)域的差異，以及特定領(lǐng)域的技術(shù)細(xì)節(jié)，很影響架構(gòu)時的設(shè)計思路和實現(xiàn)手段。
然而，這并不是鼓勵大家去挖出各種細(xì)節(jié)的問題龄糊，然后去考察架構(gòu)師候選人他嚷，這里需要有一個度。舉個例子：
你如何去把一個view的所有subview清空瓮下？
如果知道NSArray有makeObjectsPerformSelector這個方法的人，他們能夠說出直接使用這個方法，然后在selector里面寫removeFromSuperView的selector，就好了，而且很省事朝群，一句話就搞定右莱。
如果知道NSArray有enumerator方法的人晨抡，他們會說出使用這種方法枚舉每一個subview伪朽，在block里把removeFromSuperView調(diào)用起來坚洽，也差不多兩三行的事兒。
不知道NSArray有上面這些方法的人，他會說用for...in...的方法遍歷，然后取到這每一個subview涮俄，讓他們執(zhí)行removeFromSuperView÷眨可能要花費大概四五行低匙。
這幾種答案誰的更好？在我看來一樣好碗誉。為什么哮缺？
因為這個問題其實考察的是這個人知不知道某個方法，當(dāng)然你可以說他知道這個方法是因為他仔細(xì)看過文檔或者頭文件谋竖。但除了這個以外韧骗，這個問題對判斷這個人是不是一個合格的架構(gòu)師沒有任何意義沿腰。架構(gòu)師的任務(wù)在于使用合理的手段完成架構(gòu)的任務(wù)，上面三種做法都是合理的手段，只不過是實現(xiàn)技巧上的不同而已斩跌。
這樣的問題還可以拓展開來：你完全可以問一個架構(gòu)師候選人某一個領(lǐng)域的這種類似問題，而恰好你比他熟悉捞慌，如果候選人答不上來耀鸦，你會認(rèn)為他可能在這方面花的時間還不夠，這方面的理解不夠深啸澡，導(dǎo)致減分揭糕。但如果答上來了萝快，有可能加分有可能不加分。
然而著角，這一切并沒有什么卵用。如果角色對調(diào)旋恼，讓候選人來面試你吏口，他完全可以問出各種這樣類似的問題，一樣讓你抓耳撓腮百思不得其解冰更。那么該如何考察一個架構(gòu)師候選人對自己領(lǐng)域中技術(shù)細(xì)節(jié)的理解呢产徊？我們來看下面這些問題：
你覺得block當(dāng)初是為了解決什么樣的問題而設(shè)計的？你如何區(qū)分何時使用block蜀细，何時不使用舟铜？
你覺得ReactiveCocoa當(dāng)初是為了解決什么樣的問題而設(shè)計的？你何時會考慮使用RAC奠衔，何時不用谆刨？
你覺得MVVM這樣的思想是為了解決什么樣的問題而產(chǎn)生的？
答案在本文不是重點归斤，當(dāng)然如果各位對答案感興趣痊夭，可以在評論區(qū)問一下，我在評論區(qū)回答脏里。在我遇到的各種面試官中她我，我從來沒遇到過能問出這樣類似問題的面試官。我面試別人的時候迫横，我問過這種比較側(cè)重對某一項技術(shù)的理解的問題番舆，有人能答好有人答不好，然后從招進(jìn)來的人看矾踱，當(dāng)初答好這種問題的人恨狈，后來都在團(tuán)隊中起到了頂梁柱的作用。答不好這樣問題的人介返，但是他們因為知道很多技術(shù)細(xì)節(jié)拴事，也還是招進(jìn)來了，雖然也能很好地完成需求和任務(wù)圣蝎，但是代碼結(jié)構(gòu)刃宵、設(shè)計思路都會有或多或少的缺陷，寫出來的組件在使用上也會感覺怪怪徘公。
所以牲证，考察一個架構(gòu)師候選人在某一領(lǐng)域的技術(shù)時，通用的技術(shù)細(xì)節(jié)的問題可以問一下关面，偏門的技術(shù)細(xì)節(jié)問出來就很沒有意義坦袍。一個架構(gòu)師最關(guān)鍵的是他對技術(shù)的理解深度十厢，理解深刻的人，才能寫出簡單易用易拓展的架構(gòu)捂齐。然后面試官需要區(qū)分好問題蛮放，有些問題是屬于“知道、不知道”奠宜，有些問題是屬于“理解包颁、不理解”，對于面試一個高級工程師來說压真，可能會比較偏向前者娩嚼，因為他需要知道足夠多，然后完成需求的速度才快滴肿，不需要總是去Google岳悟。但對于面試一個架構(gòu)師來說，其實大部分基礎(chǔ)知識應(yīng)該是已經(jīng)具備了的泼差，不至于寫個TableView還要去翻Google贵少。但在做SDK的時候，是會遇到一些偏門問題的拴驮，是需要去Google的春瞬。但架構(gòu)師跟高級工程師的區(qū)別就在于，架構(gòu)師知道該往哪個方向去Google套啤，能夠把握住問題的實質(zhì)去解決問題宽气。所以對于考察架構(gòu)師而言，應(yīng)該更加偏向后者潜沦，理解和不理解萄涯。
回想一下，其實有很多類似知道唆鸡、不知道的問題涝影，你是在code review中，其他人的博客中争占，文檔中就能學(xué)到的燃逻。但是那些理解、不理解的問題臂痕，其實大部分都是你多年代碼的經(jīng)驗思考出來的伯襟，即便你去看了博客看了文檔，該不理解的還是不理解握童。而作為一名架構(gòu)師姆怪，真正要考察的就是理解、不理解的問題。所以你明白稽揭，為什么當(dāng)初那些技術(shù)細(xì)節(jié)答不上來的人俺附，但是對技術(shù)理解很深刻的人能成為頂梁柱，成為架構(gòu)師溪掀。而技術(shù)細(xì)節(jié)知道很多事镣，但技術(shù)理解不深刻的人還是只能做高級工程師的原因了吧？
算法和數(shù)據(jù)結(jié)構(gòu)類問題
第二類問題膨桥，算法和數(shù)據(jù)結(jié)構(gòu)相關(guān)的問題蛮浑。這種問題也是很需要問的，但似乎現(xiàn)在在社招的時候會問這種問題的面試官不太多只嚣，只有在面試比較初級的人或者應(yīng)屆生的時候才會拿來問。
我覺得面試官即便在面試架構(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)設(shè)計或表達(dá)方式，很影響最終實現(xiàn)的方案的優(yōu)雅程度定拟。所以我們面試架構(gòu)師時于微，側(cè)重點在于，對于某個問題青自，你如何去選擇合適的數(shù)據(jù)結(jié)構(gòu)株依，合適的算法來解決這樣的問題。
但是延窜，在面試應(yīng)屆生時恋腕，我們問算法和數(shù)據(jù)結(jié)構(gòu)問題時，其實更加關(guān)注的是他的動手能力逆瑞，給一個很簡單的問題荠藤，然后讓他把代碼寫出來，或白板获高，或IDE哈肖。就國內(nèi)大部分公司招聘的情況和其公司自身的情況來看，如果你學(xué)facebook／google那樣出算法題谋减，你基本上招不到人牡彻。因為會這些題目的人，都在facebook／google那兒排隊呢。
然后算法和數(shù)據(jù)結(jié)構(gòu)相關(guān)的問題第二個考察點在于庄吼，候選人的思考是否足夠細(xì)密缎除。這個不管是對架構(gòu)師候選人，還是對應(yīng)屆生還是對社招的高級工程師而言总寻，重要程度都是一樣的器罐。這個就不多說了。
你讓一名架構(gòu)師候選人在面試的時候做一個華容道算法渐行，在你而言其實是對他的一種鄙視轰坊，在他而言他也很有可能寫不出。但如果你讓一名架構(gòu)師候選人在面試時候展示他對各數(shù)據(jù)結(jié)構(gòu)的理解祟印，不同場景下如何設(shè)計合理的數(shù)據(jù)結(jié)構(gòu)和算法肴沫，如何權(quán)衡時間與空間的取舍，這才是對他的一種重視蕴忆。
方案設(shè)計思路類問題
第三類問題颤芬，方案設(shè)計思路。大概一年以前我在面試攜程的時候套鹅，遇到過面試官問我這種問題站蝠，其它我就沒有遇到過了，一般都是我在自我介紹的時候主動挑一個去講卓鹿。我在面試別人的時候菱魔，我也會問這樣的問題，比如說：
對于一個app的網(wǎng)絡(luò)層吟孙，你在設(shè)計時澜倦，你會考慮哪些問題？
對于一個app的持久層拔疚，如果讓你直接用sqlite肥隆，你如何設(shè)計版本遷移方案？
工作中稚失，你會采用哪些手段來做解耦栋艳？
嚴(yán)格來說，大部分面試官也會問這樣的問題句各，但是是看到你簡歷上寫過你有這個經(jīng)驗吸占，然后直接問這個方案你是怎么做的，而不是問這個方案你是怎么設(shè)計的凿宾。在我看來矾屯，大部分方案的實現(xiàn)其實沒有什么技術(shù)含量，真正有技術(shù)含量的地方在于初厚，拿到這個問題時件蚕，你是如何思考的孙技。就比如數(shù)據(jù)庫版本遷移方案，設(shè)計的過程是很艱苦的排作，但設(shè)計完畢實現(xiàn)的時候牵啦，就是碼代碼，不能說完全沒有技術(shù)含量妄痪，只能說實現(xiàn)的時候所需要耗費的腦力跟設(shè)計時候比哈雏，差太遠(yuǎn)了，在我看來屬于沒有什么技術(shù)含量衫生。
說到技術(shù)含量的事情裳瘪，我也遇到過特別多的面試官喜歡問這個問題：過去你解決了哪些比較有技術(shù)含量的問題？我一般不會拿這個問題去問候選人罪针，因為我覺得真的到了代碼層面彭羹，是基本上不存在技術(shù)含量的概念的，碼代碼這個工作本身泪酱，就是用計算機(jī)能懂的方式告訴計算機(jī)應(yīng)該怎么做事皆怕，其實就是一件很沒技術(shù)含量的事情。
所以我認(rèn)為的技術(shù)含量是西篓，你如何去設(shè)計一個靠譜的解決方案，這個解決方案足夠周密憋活，思考足夠長遠(yuǎn)岂津，提供的API很好看，代碼很容易閱讀悦即，很好維護(hù)吮成。
還有就是逃不掉的23種設(shè)計模式。設(shè)計模式這種東西早年被業(yè)界說了很多辜梳，都說爛了粱甫，但我不否認(rèn)的是，這種對設(shè)計方法的總結(jié)作瞄，是每個架構(gòu)師的起步和入門茶宵。如果一個架構(gòu)師連什么場合使用設(shè)么設(shè)計模式都分不清楚，各種設(shè)計模式他的設(shè)計初衷和希望解決的問題都不知道宗挥，那他算是不合格的架構(gòu)師乌庶。然而面試官也很少會去問這樣的問題，一方面可能覺得問這種問題很low契耿，另一方面其實也有少部分面試官對設(shè)計模式僅僅處在了解和知道的情況瞒大，不敢隨便拿出來問。
總結(jié)
? ? ? 面試架構(gòu)師其實是一件不容易的事情搪桂，能考察架構(gòu)師候選人實力的面試官透敌，首先自己就已經(jīng)對架構(gòu)本身有了很好的理解，就應(yīng)該是一個合格的架構(gòu)師，其次是需要足夠務(wù)實酗电，有合理的手段合理的問題魄藕，通過面試來了解候選人是不是一個適合做架構(gòu)師的人。最后顾瞻，要有足夠識人的眼光以及合適的判斷標(biāo)準(zhǔn)泼疑，通過候選人的回答，對候選人進(jìn)行篩選荷荤。從我對目前面試的情況來看退渗，對這個我持悲觀態(tài)度。大部分面試官給候選人的感覺更多的是：我問你一個這個問題蕴纳，看你知不知道会油？而不是：我問你一個這個問題，看你怎么去思考古毛？
? ? ? ?架構(gòu)師和更高級的高級工程師之間翻翩，還是有區(qū)別的。所以各家公司如果要想找到合理靠譜的架構(gòu)師稻薇，還是很不容易的嫂冻。
