怎麼面試架構師

http://www.cocoachina.com/ios/20150617/12148.html

 

其實本文想說的是：當面試一個架構師的時候，咱們應該問什麼問題？我以爲，問什麼樣的問題，體現了team leader更加看重架構師的哪些特色。

我一直認爲，作技術就跟練武同樣，在練武的不一樣階段，分招式和心法。技術也同樣，在不一樣的階段，也分招式和心法。另外，就我我的而言，常常忘記招式，一方面能夠說十二年來，我用過的招式不少，到了如今也不記得幾個。另外一方面我本身也不會特地去記。事實上，十二年代碼寫下來，我反而愈來愈不關注招式，而是愈來愈關注如何解決問題，也就是心法。因此我做爲team leader的時候，我會更加看重這個架構師候選人是否是有一套屬於本身的心法。

上面說的聽着很玄，下面我就直接回到正題：咱們面試架構師候選人時，應該問什麼樣的問題？

大體會有幾種類型的問題：

• 當前技術領域中的一些技術細節

• 算法和數據結構

• 方案設計思路

當前技術領域的技術細節類問題

針對第一類問題，我認爲是頗有必要問的，架構師對技術細節的理解，是很可以影響他作架構時的設計思路的。畢竟每個領域都有不一樣，瞭解不一樣領域的差別，以及特定領域的技術細節，很影響架構時的設計思路和實現手段。

然而，這並非鼓勵你們去挖出各類細節的問題，而後去考察架構師候選人，這裏須要有一個度。舉個例子：

你如何去把一個view的全部subview清空？

1. 若是知道NSArray有makeObjectsPerformSelector這個方法的人，他們可以說出直接使用這個方法，而後在selector裏面寫removeFromSuperView的selector，就行了，並且很省事，一句話就搞定。

2. 若是知道NSArray有enumerator方法的人，他們會說出使用這種方法枚舉每個subview，在block裏把removeFromSuperView調用起來，也差很少兩三行的事兒。

3. 不知道NSArray有上面這些方法的人，他會說用for...in...的方法遍歷，而後取到這每個subview，讓他們執行removeFromSuperView。可能要花費大概四五行。

這幾種答案誰的更好？在我看來同樣好。爲何？

由於這個問題其實考察的是這我的知不知道某個方法，固然你能夠說他知道這個方法是由於他仔細看過文檔或者頭文件。但除了這個之外，這個問題對判斷這我的是否是一個合格的架構師沒有任何意義。架構師的任務在於使用合理的手段完成架構的任務，上面三種作法都是合理的手段，只不過是實現技巧上的不一樣而已。

這樣的問題還能夠拓展開來：你徹底能夠問一個架構師候選人某一個領域的這種相似問題，而剛好你比他熟悉，若是候選人答不上來，你會認爲他可能在這方面花的時間還不夠，這方面的理解不夠深，致使減分。但若是答上來了，有可能加分有可能不加分。

然而，這一切並無什麼卵用。若是角色對調，讓候選人來面試你，他徹底能夠問出各類這樣相似的問題，同樣讓你抓耳撓腮百思不得其解。那麼該如何考察一個架構師候選人對本身領域中技術細節的理解呢？咱們來看下面這些問題：

你以爲block當初是爲了解決什麼樣的問題而設計的？你如何區分什麼時候使用block，什麼時候不使用？ 

你以爲ReactiveCocoa當初是爲了解決什麼樣的問題而設計的？你什麼時候會考慮使用RAC，什麼時候不用？ 

你以爲MVVM這樣的思想是爲了解決什麼樣的問題而產生的？ 

答案在本文不是重點，固然若是各位對答案感興趣，能夠在評論區問一下，我在評論區回答。在我遇到的各類面試官中，我歷來沒遇到過能問出這樣相似問題的面試官 。我面試別人的時候，我問過這種比較側重對某一項技術的理解的問題，有人能答好有人答很差，而後從招進來的人看，當初答好這種問題的人，後來都在團隊中起到了頂樑柱的做用。答很差這樣問題的人，可是他們由於知道不少技術細節，也仍是招進來了，雖然也能很好地完成需求和任務，可是代碼結構、設計思路都會有或多或少的缺陷，寫出來的組件在使用上也會感受怪怪。

因此，考察一個架構師候選人在某一領域的技術時，通用的技術細節的問題能夠問一下，偏門的技術細節問出來就很沒有意義。一個架構師最關鍵的是他對技術的理解深度，理解深入的人，才能寫出簡單易用易拓展的架構。而後面試官須要區分好問題，有些問題是屬於「知道、不知道」，有些問題是屬於「理解、不理解」，對於面試一個高級工程師來講，可能會比較偏向前者，由於他須要知道足夠多，而後完成需求的速度才快，不須要老是去Google。但對於面試一個架構師來講，其實大部分基礎知識應該是已經具有了的，不至於寫個TableView還要去翻Google。但在作SDK的時候，是會遇到一些偏門問題的，是須要去Google的。但架構師跟高級工程師的區別就在於，架構師知道該往哪一個方向去Google，可以把握住問題的實質去解決問題。因此對於考察架構師而言，應該更加偏向後者，理解和不理解。

回想一下，其實有不少相似知道、不知道的問題，你是在code review中，其餘人的博客中，文檔中就能學到的。可是那些理解、不理解的問題，其實大部分都是你多年代碼的經驗思考出來的，即使你去看了博客看了文檔，該不理解的仍是不理解。而做爲一名架構師，真正要考察的就是理解、不理解的問題。因此你明白，爲何當初那些技術細節答不上來的人，可是對技術理解很深入的人能成爲頂樑柱，成爲架構師。而技術細節知道不少，但技術理解不深入的人仍是隻能作高級工程師的緣由了吧？

算法和數據結構類問題

第二類問題，算法和數據結構相關的問題。這種問題也是很須要問的，但彷佛如今在社招的時候會問這種問題的面試官不太多，只有在面試比較初級的人或者應屆生的時候纔會拿來問。

我以爲面試官即使在面試架構師的時候，仍是要問這樣的問題的，只是要注意考察側重點。一個架構師若是不瞭解數據結構和算法，那他真的很難作出靠譜的架構，畢竟不少SDK底下充斥着各類各樣的數據結構，並且有經驗的人都很清楚，對於一類數據而言，不一樣的結構設計或表達方式，很影響最終實現的方案的優雅程度。因此咱們面試架構師時，側重點在於，對於某個問題，你如何去選擇合適的數據結構，合適的算法來解決這樣的問題。

可是，在面試應屆生時，咱們問算法和數據結構問題時，其實更加關注的是他的動手能力，給一個很簡單的問題，而後讓他把代碼寫出來，或白板，或IDE。就國內大部分公司招聘的狀況和其公司自身的狀況來看，若是你學facebook／google那樣出算法題，你基本上招不到人。由於會這些題目的人，都在facebook／google那兒排隊呢。

而後算法和數據結構相關的問題第二個考察點在於，候選人的思考是否足夠細密。這個不論是對架構師候選人，仍是對應屆生仍是對社招的高級工程師而言，重要程度都是同樣的。這個就很少說了。

你讓一名架構師候選人在面試的時候作一個華容道算法，在你而言實際上是對他的一種鄙視，在他而言他也頗有可能寫不出。但若是你讓一名架構師候選人在面試時候展現他對各數據結構的理解，不一樣場景下如何設計合理的數據結構和算法，如何權衡時間與空間的取捨，這纔是對他的一種重視。

方案設計思路類問題

第三類問題，方案設計思路。大概一年之前我在面試攜程的時候，遇到過面試官問我這種問題，其它我就沒有遇到過了，通常都是我在自我介紹的時候主動挑一個去講。我在面試別人的時候，我也會問這樣的問題，好比說：

對於一個app的網絡層，你在設計時，你會考慮哪些問題？ 

對於一個app的持久層，若是讓你直接用sqlite，你如何設計版本遷移方案？ 

工做中，你會採用哪些手段來作解耦？ 

嚴格來講，大部分面試官也會問這樣的問題，可是是看到你簡歷上寫過你有這個經驗，而後直接問這個方案你是怎麼作的，而不是問這個方案你是怎麼設計的。在我看來，大部分方案的實現其實沒有什麼技術含量，真正有技術含量的地方在於，拿到這個問題時，你是如何思考的。就好比數據庫版本遷移方案，設計的過程是很艱苦的，但設計完畢實現的時候，就是碼代碼，不能說徹底沒有技術含量，只能說實現的時候所須要耗費的腦力跟設計時候比，差太遠了，在我看來屬於沒有什麼技術含量。

說到技術含量的事情，我也遇到過特別多的面試官喜歡問這個問題：過去你解決了哪些比較有技術含量的問題？我通常不會拿這個問題去問候選人，由於我以爲真的到了代碼層面，是基本上不存在技術含量的概念的，碼代碼這個工做自己，就是用計算機能懂的方式告訴計算機應該怎麼作事，其實就是一件很沒技術含量的事情。

因此我認爲的技術含量是，你如何去設計一個靠譜的解決方案，這個解決方案足夠周密，思考足夠長遠，提供的API很好看，代碼很容易閱讀，很好維護。

還有就是逃不掉的23種設計模式。設計模式這種東西早年被業界說了不少，都說爛了，但我不否定的是，這種對設計方法的總結，是每一個架構師的起步和入門。若是一個架構師連什麼場合使用設麼設計模式都分不清楚，各類設計模式他的設計初衷和但願解決的問題都不知道，那他算是不合格的架構師。然而面試官也不多會去問這樣的問題，一方面可能以爲問這種問題很low，另外一方面其實也有少部分面試官對設計模式僅僅處在瞭解和知道的狀況，不敢隨便拿出來問。

總結

面試架構師實際上是一件不容易的事情，能考察架構師候選人實力的面試官，首先本身就已經對架構自己有了很好的理解，就應該是一個合格的架構師，其次是須要足夠務實，有合理的手段合理的問題，經過面試來了解候選人是否是一個適合作架構師的人。最後，要有足夠識人的眼光以及合適的判斷標準，經過候選人的回答，對候選人進行篩選。從我對目前面試的狀況來看，對這個我持悲觀態度。大部分面試官給候選人的感受更多的是：我問你一個這個問題，看你知不知道？而不是：我問你一個這個問題，看你怎麼去思考？

架構師和更高級的高級工程師之間，仍是有區別的。因此各家公司若是要想找到合理靠譜的架構師，仍是很不容易的。