其实这篇文章想说的是：在面试建筑师的时候，我们应该问哪些问题？我觉得问什么样的问题，更能反映团队负责人更看重架构师的哪些特质。我一直认为，做技术和练武是一样的。练武的不同阶段，都有招式和心法。技术也是如此。在不同的阶段，也有招式和心法。此外，就我而言，我经常忘记动作。一方面，可以说这十二年来自己用过很多招式，现在已经记不得几个了。另一方面，我自己也懒得去记。其实写了十二年的代码，我越来越不注重招数，而是越来越注重如何解决问题，也就是心法。所以我在做teamleader的时候，会更加关注架构师候选人是否有一套自己的想法。上面说的听起来很玄乎，那我就回归正题：面试架构师应聘者应该问什么样的问题？题型大致有几类：当前技术领域的一些技术细节算法和数据结构设计思路***：当前技术领域的技术细节针对***类问题，我觉得很有必要至于问题，架构师在做架构的时候，对技术细节的理解，可以极大地影响他的设计思路。毕竟每个领域都不一样。了解不同领域的差异和特定领域的技术细节，将极大地影响架构的设计思路和实现方法。但是，这并不是鼓励大家去挖掘各种细节，然后考察架构师候选人。这里需要有学位。例如：如何清除一个视图的所有子视图？如果知道NSArray有makeObjectsPerformSelector方法的人，可以告诉他们直接使用这个方法，然后在selector中写上removeFromSuperView的selector就可以了，而且很方便，一次搞定句子。如果有人知道NSArray有一个enumerator方法，就会说用这个方法枚举每一个subview，在block中调用removeFromSuperView大概就是两三行吧。不知道NSArray有以上方法的人，他会用for...in...方法遍历，然后分别获取这些子视图，让它们执行removeFromSuperView。可能需要大约四五行。这些答案中哪个更好？在我看来一样好。为什么？因为这道题其实是考察这个人是否知道某种方法。当然你可以说他知道这个方法，因为他仔细看了文档或者头文件。但除此之外，这个问题对于判断这个人是不是合格的建筑师没有任何意义。架构师的任务就是用合理的手段来完成架构师的任务。以上三种方式都是合理的手段，只是实现技巧不同而已。这样的问题还可以扩展：你可以问一个架构师候选人这种在某个领域的类似问题，恰好你比他更熟悉。时间不够，对这方面的了解不够深入，导致减分。但是如果答出来了，可能会有加分，也可能没有加分。然而，这一切都没有用。如果角色对调，应聘者来面试你，他可以问各种类似的问题，同样会让你摸不着头脑，摸不着头脑。那么如何考察一个架构师候选人对其领域技术细节的理解程度呢？让我们看看以下问题：您认为该区块最初旨在解决什么样的问题？你怎么知道什么时候使用块，什么时候不使用？你认为ReactiveCocoa旨在解决什么样的问题？您什么时候会考虑使用RAC，什么时候不会？你认为创建MVVM的想法是为了解决什么样的问题？答案不是本文的重点。当然，如果大家对答案感兴趣，可以在评论区提问，我会在评论区一一解答。在我遇到的各种面试官中，我还从来没有遇到过能问出如此类似问题的面试官。我在面试别人的时候，问过这种比较侧重于对某项技术的理解的问题。有些人可以很好地回答，有些人则不能。从新兵的角度来看，一开始回答得很好的人，后来都在团队中起到了顶梁柱的作用。不能很好回答这类问题的人，但因为知道很多技术细节，所以还是录用了。虽然他们也能很好的完成需求和任务，但是代码结构和设计思路或多或少都会有缺陷。写出来Components用起来也感觉怪怪的。所以，考察某个领域的架构师候选人的技术时，可以问一般的技术细节问题，问偏门的技术细节是没有意义的。架构师最重要的是对技术的深刻理解。只有理解深刻的人，才能写出易用易扩展的架构。那么面试官就需要区分好问题，有的问题属于“知道，不知道”，有的问题属于“懂，不懂”，对于面试高级工程师，可能更倾向于前者，因为他需要知道的足够多，然后完成需求的速度就快了，没必要老是去谷歌。但是对于面试一个架构师来说，其实大部分的基础知识应该已经有了，没必要去谷歌写一个TableView。但是在做SDK的时候，会遇到一些sideissues，需要去Google一下。但是架构师和高级工程师的区别在于，架构师知道去Google往哪个方向走，能够抓住问题的本质来解决问题。所以，对于考察建筑师，我们应该更倾向于后者，理解与不理解。回想一下，实际上有很多诸如知道和不知道之类的问题。您可以在代码审查、其他人的博客和文档中学习它们。但是大部分你懂的和不懂的问题，其实都是你多年编码经验想出来的。就算看了博客，看了文档，还是不明白不该明白的地方。作为架构师，我们真正需要审视的是懂与不懂的问题。所以你明白为什么那些一开始答不上技术细节的人，但是对技术有深刻理解的人却能成为顶梁柱和架构师。并且知道很多技术细节，但是没有很深的技术理解的人只能是高级工程师吧？算法和数据结构问题第二类问题与算法和数据结构有关。这种问题也是要问的，不过好像社招的时候问这种问题的面试官不是太多。他们只在面试相对资历较浅的人或应届毕业生时才会被问到。我觉得面试官在面试架构师的时候还是要问这样的问题，只是要注意考察的重点。如果一个架构师不懂数据结构和算法，他真的很难做出可靠的架构。毕竟很多SDK里面充斥着各种各样的数据结构，有经验的人都非常清楚，对于一个类数据而言，不同的结构设计或者表达方式，极大的影响着最终方案的优雅程度。所以我们在面试架构师的时候，重点是针对某个问题，如何选择合适的数据结构，合适的算法来解决这样的问题。但是面试应届生的时候，我们问算法和数据结构的时候，其实更看重他的动手能力，给一个很简单的问题，然后让他写代码，或者白板，或者IDE。从国内大部分公司的招聘情况和公司自身的情况来看，像facebook/google这样学算法题的，基本招不到人。因为知道这些话题的人都在facebook/google上排队。那么算法和数据结构相关问题的第二个考察点就是候选人的思维是否足够细化。这一点的重要性，无论是对于应届建筑师、新生还是社会招聘的高级工程师来说，都是一样的。这个我就不多说了。如果你在面试的时候让一个架构师候选人做一个花容道算法，对你来说，其实是对他的一种蔑视，对他来说，他不一定能写出来。但是如果你让一个架构师候选人在面试的时候表现出他对各种数据结构的理解，如何在不同的场景下设计出合理的数据结构和算法，如何权衡时间和空间之间的权衡，这对他来说是一种方式注意。方案设计思路题第三类题是方案设计思路。大概一年前面试携程的时候，遇到面试官问我这种问题。我从未遇到过其他人。通常，我在自我介绍时会主动挑一个来谈。我面试别人的时候也会问这样的问题，比如：对于一个app的网络层，你在设计的时候会考虑哪些问题？对于一个app的持久层，如果让你直接使用sqlite，你如何设计一个版本迁移的方案？在你的工作中，你会用什么方法来解耦？严格来说，大部分面试官也会问这样的问题，但是他们看到你简历上写了这段经历，然后直接问你这个计划是怎么做的，而不是问你这个计划是怎么设计的。在我看来，大多数解决方案的实现都没有技术含量。真正的技术含量在于你拿到这个题的时候是怎么想的。比如数据库的版本迁移方案，设计的过程是非常困难的，但是当设计完成并实施的时候，就是代码了。不能说完全没有技术含量。只能说实现需要的脑力比设计还差。太远了，在我看来，没什么技术含量。说到技术含量，我也遇到过很多面试官喜欢问这样的问题：你过去解决过哪些技术问题？我一般不会问应聘者这个问题，因为我觉得说到代码层面，基本没有技术含量的概念。编码代码本身的工作就是用计算机能够理解的方式告诉计算机该做什么，其实是一件很没有技术含量的事情。所以我觉得技术含量是，你如何设计一个靠谱的方案，这个方案够周到，思路够长，提供的API漂亮，代码易读，易维护。还有23种设计模式是逃不掉的。设计模式早年被业界津津乐道，但我不否认这种对设计方法的总结是每个架构师的开始和入门。如果一个架构师连什么时候使用设计模式都不知道，不知道各种设计模式的初衷和希望解决的问题，那么他就是一个不合格的架构师。但是，面试官很少问这样的问题。一方面，他们可能会觉得问这样的问题很低级。另一方面，也有小部分面试官只懂设计模式，不敢随便拿出来。问。综上所述，面试架构师其实不是一件容易的事。一个能够考察架构师候选人实力的面试官，首先对架构本身有很好的理解，应该是一个合格的架构师。够实际，用合理的手段和合理的问题，通过面试了解应聘者是否适合做建筑师。***，你必须有足够的洞察力和适当的判断标准来根据他们的答案筛选候选人。从我目前的面试情况来看，我对此持悲观态度。大多数面试官对候选人的感觉更多：我问你这个问题，你知道吗？而不是：让我问你这个问题，你怎么看？因此，企业要找到合理可靠的架构师并不容易。
