面试时交流时间有限，应该问你的架构师候选人什么问题？

Q1：架构工作有些什么步骤？架构工作与其它开发工作的关系如何？……

有些架构师认为此类问题比较重要。只有弄清楚了这些问题，才能算是掌握了架构方法论，能够保证可控可重复地进行架构设计。而另一些架构师则认为，只要能产出切实可用的系统，架构设计是什么，它如何达成的都不重要。

个人认为方法论是重要的。你团队中的架构过程和成果需要积累和传承，适当的方法论可以在架构师（包括开发团队）之间统一讨论语言和产出物，利于积累和传承。

特别是，如果你认为你的架构师应该负责建立或提高架构和开发的团队和流程，你需要问此类问题。

Q2：假设现在需要搭建XX类型的系统，你如何思考？

这类问题是开放式的主观题。涵盖范围很广，可以全面地考察架构师的思维方式、方法论、知识、经验，所以被广泛使用。这类问题很好用，但需要注意。它常常引来候选人的长篇大论，从方法到模式，从前台到后台，从需求到设计，…… 所以交流过程中需要控制和引导，避免被淹没在回答当中，当候选人提到了想要重点考察的领域，需要有针对性地进行专门的提问和讨论。

Q3：假设现在遇到X问题，解决方案是什么？

这类问题考察的是架构师的经验。如果他¹遇到和解决过同类问题，并且记住了解决方案，他就能回答，如果没有，就不能回答。因为没有人能够在四目相对的几秒十几秒时间里解决一个陌生的架构问题。要知道架构决策和设计不是一个靠急智能够胜任的工作。

所以如果你需要架构师招聘进来以后能够立即解决一个问题——也就是你提问中的那个问题，你需要问这类问题。个人认为这种情况要尽量避免，因为这样就放弃了对其它方面素质的考量和选择。

Q4：AA设计模式中……、BB数据库中……、CC算法中……、DD类里面……

这类是涉及到某些领域的细节问题，如果你需要架构师兼任此领域的技术专家（这种情况常见），那你需要问这类问题。

有些架构师可能对某些领域的细节问题解决能力不足，但他隔离和描述问题的能力很强，进而可以很快从外部找到并应用现成的解决方案。这样的架构师虽然称不上技术专家，但一定程度上其实可以解决大量的具体问题。

依据你面对的问题、团队规模及可以负担的成本，你需要判断是否需要真正的技术专家。

Q5：在你做过的YY事情中，是如何考虑ZZ问题的？

这类问题跟Q2问题功能相似。同时它可以避免Q2问题的一个弱点：万一候选人没有XX类型系统的工作经验，考察就没办法进行下去。除非：你的职位必需这类系统的知识和经验。这种情况常见，比如招聘互联网产品的架构师往往认为必需“大并发系统”的知识和经验。

Q6：最近在干什么？学什么？比较关注什么？

个人比较喜欢此类问题。但这类问题完全没有参考答案，需要提问人注意从回答中挖掘想要的信息。比如候选人对职业生涯的规划、对技术走势的判断等等。否则问答完了之后，对候选人是否适合职位的判断帮助不大。