当面试一个架构师的时候，咱们应该问什么问题？

　　给你一次机会面试架构师 你会问什么问题？

 

　　其实本文想说的是：当面试一个架构师的时候，咱们应该问什么问题？我以为，问什么样的问题，体现了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那儿排队呢。

而后算法和数据结构相关的问题第二个考察点在于，候选人的思考是否足够细密。这个不论是对架构师候选人，仍是对应届生仍是对社招的高级工程师而言，重要程度都是同样的。这个就很少说了。

你让一名架构师候选人在面试的时候作一个华容道算法，在你而言实际上是对他的一种鄙视，在他而言他也颇有可能写不出。但若是你让一名架构师候选人在面试时候展现他对各数据结构的理解，不一样场景下如何设计合理的数据结构和算法，如何权衡时间与空间的取舍，这才是对他的一种重视。

 

第三类问题方案设计思路类问题

　　大概一年之前我在面试携程的时候，遇到过面试官问我这种问题，其它我就没有遇到过了，通常都是我在自我介绍的时候主动挑一个去讲。我在面试别人的时候，我也会问这样的问题，好比说：

• 对于一个app的网络层，你在设计时，你会考虑哪些问题？
• 对于一个app的持久层，若是让你直接用sqlite，你如何设计版本迁移方案？
• 工做中，你会采用哪些手段来作解耦？

　　严格来讲，大部分面试官也会问这样的问题，可是是看到你简历上写过你有这个经验，而后直接问这个方案你是怎么作的，而不是问这个方案你是怎么设计的。在我看来，大部分方案的实现其实没有什么技术含量，真正有技术含量的地方在于，拿到这个问题时，你是如何思考的。就好比数据库版本迁移方案，设计的过程是很艰苦的，但设计完毕实现的时候，就是码代码，不能说彻底没有技术含量，只能说实现的时候所须要耗费的脑力跟设计时候比，差太远了，在我看来属于没有什么技术含量。

说到技术含量的事情，我也遇到过特别多的面试官喜欢问这个问题：过去你解决了哪些比较有技术含量的问题？我通常不会拿这个问题去问候选人，由于我以为真的到了代码层面，是基本上不存在技术含量的概念的，码代码这个工做自己，就是用计算机能懂的方式告诉计算机应该怎么作事，其实就是一件很没技术含量的事情。

因此我认为的技术含量是，你如何去设计一个靠谱的解决方案，这个解决方案足够周密，思考足够长远，提供的API很好看，代码很容易阅读，很好维护。

　　还有就是逃不掉的23种设计模式。设计模式这种东西早年被业界说了不少，都说烂了，但我不否定的是，这种对设计方法的总结，是每一个架构师的起步和入门。若是一个架构师连什么场合使用设么设计模式都分不清楚，各类设计模式他的设计初衷和但愿解决的问题都不知道，那他算是不合格的架构师。然而面试官也不多会去问这样的问题，一方面可能以为问这种问题很low，另外一方面其实也有少部分面试官对设计模式仅仅处在了解和知道的状况，不敢随便拿出来问。

 

总结

　　面试架构师实际上是一件不容易的事情，能考察架构师候选人实力的面试官，首先本身就已经对架构自己有了很好的理解，就应该是一个合格的架构师，其次是须要足够务实，有合理的手段合理的问题，经过面试来了解候选人是否是一个适合作架构师的人。最后，要有足够识人的眼光以及合适的判断标准，经过候选人的回答，对候选人进行筛选。从我对目前面试的状况来看，对这个我持悲观态度。大部分面试官给候选人的感受更多的是：我问你一个这个问题，看你知不知道？而不是：我问你一个这个问题，看你怎么去思考？

因此各家公司若是要想找到合理靠谱的架构师，仍是很不容易的。