怎麼面試架構師

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

我一直認為，做技術就跟練武一樣，在練武的不同階段，分招式和心法。技術也一樣，在不同的階段，也分招式和心法。另外，就我個人而言，經常忘記招式，一方面可以說十二年來，我用過的招式很多，到了現在也不記得幾個。另一方面我自己也不會特意去記。事實上，十二年**寫下來，我反而越來越不關注招式，而是越來越關注如何解決問題，也就是心法。所以我作為team leader的時候，我會更加看重這個架構師候選人是不是有一套屬於自己的心法。

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

大致會有幾種型別的問題：

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

演算法和資料結構

方案設計思路

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

然而，這並不是鼓勵大家去挖出各種細節的問題，然後去考察架構師候選人，這裡需要有乙個度。舉個例子：

你如何去把乙個view的所有subview清空？

如果知道nsarray有makeobjectsperformselector這個方法的人，他們能夠說出直接使用這個方法，然後在selector裡面寫removefromsuperview的selector，就好了，而且很省事，一句話就搞定。

如果知道nsarray有enumerator方法的人，他們會說出使用這種方法列舉每乙個subview，在block裡把removefromsuperview呼叫起來，也差不多兩三行的事兒。

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

這幾種答案誰的更好？在我看來一樣好。為什麼？

因為這個問題其實考察的是這個人知不知道某個方法，當然你可以說他知道這個方法是因為他仔細看過文件或者標頭檔案。但除了這個以外，這個問題對判斷這個人是不是乙個合格的架構師沒有任何意義。架構師的任務在於使用合理的手段完成架構的任務，上面三種做法都是合理的手段，只不過是實現技巧上的不同而已。

這樣的問題還可以拓展開來：你完全可以問乙個架構師候選人某乙個領域的這種類似問題，而恰好你比他熟悉，如果候選人答不上來，你會認為他可能在這方面花的時間還不夠，這方面的理解不夠深，導致減分。但如果答上來了，有可能加分有可能不加分。

然而，這一切並沒有什麼卵用。如果角色對調，讓候選人來面試你，他完全可以問出各種這樣類似的問題，一樣讓你抓耳撓腮百思不得其解。那麼該如何考察乙個架構師候選人對自己領域中技術細節的理解呢？我們來看下面這些問題：

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

你覺得reactivecocoa當初是為了解決什麼樣的問題而設計的？你何時會考慮使用rac，何時不用？

你覺得mvvm這樣的思想是為了解決什麼樣的問題而產生的？

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

回想一下，其實有很多類似知道、不知道的問題，你是在code review中，其他人的部落格中，文件中就能學到的。但是那些理解、不理解的問題，其實大部分都是你多年**的經驗思考出來的，即便你去看了部落格看了文件，該不理解的還是不理解。而作為一名架構師，真正要考察的就是理解、不理解的問題。所以你明白，為什麼當初那些技術細節答不上來的人，但是對技術理解很深刻的人能成為頂梁柱，成為架構師。而技術細節知道很多，但技術理解不深刻的人還是只能做高階工程師的原因了吧？

演算法和資料結構類問題

第二類問題，演算法和資料結構相關的問題。這種問題也是很需要問的，但似乎現在在社招的時候會問這種問題的面試官不太多，只有在面試比較初級的人或者應屆生的時候才會拿來問。

我覺得面試官即便在面試架構師的時候，還是要問這樣的問題的，只是要注意考察側重點。乙個架構師如果不了解資料結構和演算法，那他真的很難做出靠譜的架構，畢竟很多sdk底下充斥著各種各樣的資料結構，而且有經驗的人都很清楚，對於一類資料而言，不同的結構設計或表達方式，很影響最終實現的方案的優雅程度。所以我們面試架構師時，側重點在於，對於某個問題，你如何去選擇合適的資料結構，合適的演算法來解決這樣的問題。

但是，在面試應屆生時，我們問演算法和資料結構問題時，其實更加關注的是他的動手能力，給乙個很簡單的問題，然後讓他把**寫出來，或白板，或ide。就國內大部分公司招聘的情況和其公司自身的情況來看，如果你學facebook／google那樣出演算法題，你基本上招不到人。因為會這些題目的人，都在facebook／google那兒排隊呢。

然後演算法和資料結構相關的問題第二個考察點在於，候選人的思考是否足夠細密。這個不管是對架構師候選人，還是對應屆生還是對社招的高階工程師而言，重要程度都是一樣的。這個就不多說了。

你讓一名架構師候選人在面試的時候做乙個華容道演算法，在你而言其實是對他的一種鄙視，在他而言他也很有可能寫不出。但如果你讓一名架構師候選人在面試時候展示他對各資料結構的理解，不同場景下如何設計合理的資料結構和演算法，如何權衡時間與空間的取捨，這才是對他的一種重視。

方案設計思路類問題

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

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

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

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

所以我認為的技術含量是，你如何去設計乙個靠譜的解決方案，這個解決方案足夠周密，思考足夠長遠，提供的api很好看，**很容易閱讀，很好維護。

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

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

架構師和更高階的高階工程師之間，還是有區別的。所以各家公司如果要想找到合理靠譜的架構師，還是很不容易的。

怎麼面試架構師

其實本文想說的是 當面試乙個架構師的時候，我們應該問什麼問題？我覺得，問什麼樣的問題，體現了team leader更加看重架構師的哪些特點。我一直認為，做技術就跟練武一樣，在練武的不同階段，分招式和心法。技術也一樣，在不同的階段，也分招式和心法。另外，就我個人而言，經常忘記招式，一方面可以說十二年來...

小白聊架構師 怎麼成為架構師

還有人說 我早就掌握了物件導向設計，也看了 企業應用架構模式 架構之美 大型 技術架構 等等架構的書，為啥還當不了架構師？是啊，這高階，大氣，上檔次的架構師是怎麼煉成的？這裡講乙個小王的故事吧。又到了畢業季，一批應屆生進了乙個軟體公司，小王也在其中。新人進入公司，基本上都是從最底層做起，做那些最髒最...

新加坡架構師面試總結

本來是想把之前面試的一些經歷和體會以乙個系列的形式寫出來，但一直都有這樣或者那樣的事情 從中作梗 所以直到現在也未能如願。鑑於很多朋友發郵件提到這個問題，我本意是很想把這些文章補上，但是這個月忙著趕專案，下個月又要和老婆去澳大利亞旅遊大半個月，所以先發一張之前概述的總結圖，希望對需要這些資料的朋友一...