关于如何面试架构师的问题
其实本文想说的是： 当面试一个架构师的时候， 我们应该问什么问题?我觉得，问什么样的问题体现了 team leader 更加看重架构师的哪些特点。
我一直认为，做技术就跟练武一样，在练武的不同阶段，分招式和心法。技术也一样，在不同的阶段，也分招式和心法。另外，就我个人而言，经常忘记招式，一方面可以说十二年来，我用过的招式很多，到了现在也不记得几个。另一方面我自己也不会特意去记。事实上，十二年代码写下来，我反而越来越不关注招式，而是越来越关注如何解决问题，也就是心法。所以我作为 team leader 的时候，我会更加看重这个架构师候选人是不是有一套属于自己的心法。
上面说的听着很玄，下面我就直接回到正题：我们面试架构师候选人时，应该问什么样的问题?大致会有几种类型的问题：
1. 当前技术领域中的一些技术细节
2. 算法和数据结构
3. 方案设计思路
第一类：当前技术领域的技术细节类问题
针对第一类问题，我认为是很有必要问的，架构师对技术细节的理解，是很能够影响他做架构时的设计思路的。毕竟每一个领域都有不同，了解不同领域的差异，以及特定领域的技术细节，很影响架构时的设计思路和实现手段。
然而，这并不是鼓励大家去挖出各种细节的问题，然后去考察架构师候选人，这里需要有一个度。举个例子：
你如何去把一个 view 的所有 subview 清空?
1. 如果知道 NSArray 有makeObjectsPerformSelector 这个方法的人，他们能够说出直接使用这个方法，然后在selector 里面写 removeFromSuperView 的 selector，就好了，而且很省事，一句话就搞定。
2. 如果知道 NSArray 有 enumerator 方法的人，他们会说出使用这种方法枚举每一个 subview，在 block 里把removeFromSuperView 调用起来，也差不多两三行的事儿。
3. 不知道 NSArray 有上面这些方法的人，他会说用for…in… 的方法遍历，然后取到这每一个 subview，让他们执行 removeFromSuperView。可能要花费大概四五行。
这几种答案谁的更好?在我看来一样好。为什么?
因为这个问题其实考察的是这个人知不知道某个方法，当然你可以说他知道这个方法是因为他仔细看过文档或者头文件。但除了这个以外，这个问题对判 断这个人是不是一个合格的架构师没有任何意义。架构师的任务在于使用合理的手段完成架构的任务，上面三种做法都是合理的手段，只不过是实现技巧上的不同而已。
这样的问题还可以拓展开来：你完全可以问一个架构师候选人某一个领域的这种类似问题，而恰好你比他熟悉，如果候选人答不上来，你会认为他可能在这方面花的时间还不够，这方面的理解不够深，导致减分。但如果答上来了，有可能加分有可能不加分。
然而，这一切并没有什么卵用。如果角色对调，让候选人来面试你，他完全可以问出各种这样类似的问题，一样让你抓耳挠腮百思不得其解。那么该如何考察一个架构师候选人对自己领域中技术细节的理解呢?我们来看下面这些问题：
1. 你觉得 block 当初是为了解决什么样的问题而设计的?你如何区分何时使用 block，何时不使用?
2. 你觉得 ReactiveCocoa 当初是为了解决什么样的问题而设计的?你何时会考虑使用 RAC，何时不用?
3. 你觉得 MVVM 这样的思想是为了解决什么样的问题而产生的?
当然，答案在本文不是重点。 在我遇到的各种面试官中， 我从来没遇到过能问出这样类似问题的面试官 。我面试别人的时候，我问过这种比较侧重对某一项技术的理解的问题，有人能答好有人答不好，然后从招进来的人看，当初答好这种问题的人，后来都在团队中起到了顶梁柱的作用。答不好这样问题的人，但是他们因为知道很多技术细节，也还是招进来了，虽然也能很好地完成需求和任务，但是代码结构、设计思路都会有或 多或少的缺陷，写出来的组件在使用上也会感觉怪怪。
所以，考察一个架构师候选人在某一领域的技术时，通用的技术细节的问题可以问一下，偏门的技术细节问出来就很没有意义。一个架构师最关键的是他 对技术的理解深度，理解深刻的人，才能写出简单易用易拓展的架构。然后面试官需要区分好问题，有些问题是属于“知道、不知道”，有些问题是属于“理解、不理解”，对于面试一个高级工程师来说，可能会比较偏向前者，因为他需要知道足够多，然后完成需求的速度才快，不需要总是去 Google。但对于面试一个架构师来说，其实大部分基础知识应该是已经具备了的，不至于写个 TableView 还要去翻 Google。但在做 SDK 的时候，是会遇到一些偏门问题的，是需要去 Google 的。但架构师跟高级工程师的区别就在于，架构师知道该往哪个方向去 Google，能够把握住问题的实质去解决问题。所以对于考察架构师而言，应该更加偏向后者，理解和不理解。
回想一下，其实有很多类似知道、不知道的问题，你是在 code review 中，其他人的博客中，文档中就能学到的。但是那些理解、不理解的问题，其实大部分都是你多年代码的经验思考出来的，即便你去看了博客看了文档，该不理解的还是不理解。而作为一名架构师，真正要考察的就是理解、不理解的问题。所以你明白，为什么当初那些技术细节答不上来的人，但是对技术理解很深刻的人能成为顶梁柱，成为架构师。而技术细节知道很多，但技术理解不深刻的人还是只能做高级工程师的原因了吧?
第二类：算法和数据结构类问题
第二类问题，算法和数据结构相关的问题。这种问题也是很需要问的，但似乎现在在社招的时候会问这种问题的面试官不太多，只有在面试比较初级的人或者应届生的时候才会拿来问。
我觉得面试官即便在面试架构师的时候，还是要问这样的问题的，只是要注意考察侧重点。一个架构师如果不了解数据结构和算法，那他真的很难做出靠 谱的架构，毕竟很多 SDK 底下充斥着各种各样的数据结构，而且有经验的人都很清楚，对于一类数据而言，不同的结构设计或表达方式，很影响最终实现的方案的优雅程度。所以我们面试架构师时，侧重点在于，对于某个问题，你如何去选择合适的数据结构，合适的算法来解决这样的问题。