各位大牛，请问如何面试架构师级别的开发人员？

心里念着架构师算个屁，代码写不好滚一边去……然后就可以了

p.s. 小弟我曾经司职某大公司中型团队架构师……

做这个ps只是想说我不是仇富，哈哈哈

介绍下经验吧。

这么说吧，任何代码相关的工作，由测试到架构，都应该基础于代码能力。

代码能力不强的，基本上做不好工作，无论是哪一个位置。

第二个问题是：你们公司，或团队需要一个架构师来做什么。如果你能理解这个位置的角色，

就可以针对这个角色进行面试。每个公司或团队，对架构师的理解都可能不一样。

小公司会希望架构师有搭建原型系统的能力，论证方案的可行性；有规模的公司会希望架构师有

足够的经验和能力指导产品的方向，引导产品的质量，也就是所谓的前瞻能力之类。

也有人，比如Martin Fowler认为架构师没什么特别用处，他把他认可的一个“架构师”形容成

一个助人为乐的雷峰（见Is Design Dead?），利用自身的知识，深入群众，进行救苦救急。

如果从能力的角度来说，架构师首要的能力是代码能力。很多人找一个不会写Java的人做Java团队

的架构师，认为构架的能力是相通的 —— 事实上，如果一个人不会写Java而做了Java团队的架构师，

最可能发生的第一件事就是看不起团队里的开发人员，然后否定团队的技术方向和决定。

然后是基础编程理论，比如基础算法素养，设计模式，对clean code的理论和应用能力……

基本上就是高级开发人员的要求，要一一达到。这个源于代码能力，而又略高于代码能力。

总之，如果架构师本身达不到一个高级码农的标准，第一件他会做的事就是看不起码农 …… 因为他

自己在同一个领域方向上达不到一流水平，最简单的事就是告诉自己这方面不重要

（比如我自己从来都不认同SQL的能力有多重要）。第三件事才是所谓的大局知识。

我不说大局观，因为这东西没什么标准。你随便找到大学毕业一两年的小孩一样可以吹大局观吹到天上去。

让他讲述一些他参与或了解的系统的一些架构问题以及他实践过的解决方向可能是一个好的面试话题。

最后就是产品路线设计，如果有这个需要的话。

我个人比较认同Martin Fowler的观点，架构师这个位置不重要，或不需要。

基层代码能力和高层商业方向决定了产品的成败，其他都是次要的。

（简单来说，不要聘请架构师，事实上很多公司开始删掉架构师这个title）

谢谢，转寄先。

再灌一点。

架构师这个 title ，如果没有非常明确的必要性，好还是回避。我倒不反对一个核心架构团队，

或者把系统的主要核心架构在短期内由某一个或两个人建立原型。但架构师这个角色，在我见到过的团队里，

（包括我自己担任这个角色的时候），都往往是阻力大于推动力，很容易成为团队发展的瓶颈。

我不知道有多少人认同“架构师必须首先是一个高水平码农”这样的观点。如果你不认同这点，估计

有不同的思路。但我是认同的。很多人的期望架构师的能力是高水平码农 ＋ 架构能力 —— 然而什么是架构能力？

决定产品技术方向？决定接口？制定开发标准？如果这些都需要，我想问，一个人离开一线开发之后多久

会基本上失去这些能力 —— 两年？五年？无论时间有多长，只要离开一线开发，能力只会慢慢下降 ——

最后的结果，就是让一个能力不足的人去引导一群能力更强的人在同一个方向上走，

让一个不在一线的“开发人员”去决定一线开发人员的工作方向，这个东西，只要想想就知道不靠谱。

我一直认为很多能力强的人可以带一个蓝翔团队或青鸟团队做出很好的产品。这个时候的确需要一个“架构师”。

但更多时候，在公司环境里，大家的能力虽然有参差，但很少会有一个人技术能力远高于其他人。架构师这样的角色，

却让某个人成为权威中心。我不是说架构师不能接受其他人的意见，但更好的做法可能是采用一些弱管理的方式，

以动态回归的方式来反复验证方案，而不是采用这种决定->执行的模式。简单地说，一个公司的技术模式应该

积极而动态。贵站有位牛人说过，把东西都做成容易替换；Martin Fowler认为Simplicity是eventual design的

核心；这些都是最重要的架构思想……有了一些思想，大家都是架构师，而大家都不是架构师；所有的开发人员，

能力不论高低，一起动态地构建产品，通过测试和验证来获得产品的进化，通过pair consulting/pair programming，

code review，refactoring来控制细节质量。这样的话，产品更容易成功。

我不否认一个牛人能非常大程度地影响一个公司的成败；然而，现在的开发技术太细太多，在DIP的模式下，又或者软件开发

自身的特点就是这样，由细节决定成败；大方向不能有大错；但大方向决定不了太多东西；又或者大方向也是有细节的。

我认识和欣赏的一个牛人，最后亲眼看着他作为架构师后成为团队的瓶颈。

总之，可以避免的话，不要设立架构师这个title。把架构师这个钱给团队里的高水平开发人员，会是一个更合适的做法。

很简单啊，问他做过什么。然后集中在他的项目中一个你认为的难点上，考察他当时如

何解决问题。如果他做过，这个问题你一定难不倒他。

然后，再拿出一个你自己解决过的难题，问他怎么解决。这个问题再难不倒他，基本上可以过关了。如果难倒他，属于水平一般。

对于真正的架构师，你就拿你自己解决不了的难题，让他解决。

完全同意，所表达的是一个正常的软件工程的生命过程，架构师这个岗位确实没有存在必

要，应该称为具备架构能力的程序员，而不应单独设置架构师这种岗位。

构团队，

我见到过的团队里，

不敢说，也不能说你这个观点有问题。事实上很多人都会这样做。

然而，就象我前面说的，开发时细节非常关键；一些你认可的方案，或难题，是建立在很多细节之上。

除非你有过人的能力，不然在面试的时候，单单要把自己遇过的问题大致讲明白都不容易。

所谓把自己遇过的难题来测试别人的能力，基本上很难有什么好的效果：不妨想一想，这个问题之所以

成为你“曾经”的难题，说明本身包含了很多东西。除非你已经远远超越了当初的自己，

不然，这个所谓的难题就是你自己的颈瓶线；你又如何在自己的颈瓶线上看出别人的优劣？

我被某著名公司的一个人面试过。他尝试说他们的技术难点，然后问我有什么解决方案。

他说完之后我就知道这个团队最直接的解决方案就是把这个人干掉。原因很简单，他问的问题很简单，

是一个典型的烂实现导致问题复杂化而他自己又不知道，以为这是什么大问题，结果两年来

一直在“想”方案。而通常这种问题主要是由于代码的原作者一直影响代码的进化导致。

当然，因为是面试，不可能把真实问题说出来。我只是简单地说了一下自己的想法，

他也听不进去，认为我的想法不靠谱。我的方案一般都很简单，估计他直接b4。

（这个人的问题如果用我自己的话来总结就是：一个简单的多系统文件缓冲实现两年来一直有问题）

最后从中介那里反馈回来的信息，说对方认为我回答问题不着边际。好吧……

我也觉得自己不着他的边际，哈哈哈

学习了

很多细节之上。

易。

赞，不靠谱的领导就是公司的灾难

你把那个人的问题，描述得更清楚详细一点。

不认同啊。amazon的老总，王江民，都是这些的反例。

当然我不是说所有地方非得要个arch，但是项目大了有个不错的领军人物还是很有必要的。否则搞定那些半瓶子水，会花费很大的沟通成本

有架构师的位置的目的是让一个高水平的带领一群低水平的打天下，而不是让高层看一帮子中等水平的成天扯皮。当然，如果贵公司的程序员个个年薪百万，水平认知都一致，都清楚知道公司的情况和未来发展方向，而且不内斗，当我没说。

事实上，如果一个人不会写Java而做了Java团队的架构师，

最可能发生的第一件事就是看不起团队里的开发人员，然后否定团队的技术方向和决定。

--------------------------------------------------------------------------------------------------

这句话说的太赞了！

en

根据我的经验，最开始设计系统的那个人往往以后也成为阻力。架构的演进到这个人那

里成为了瓶颈。

心架构团队，

色，在我见到过的团队里，

是啊，@loafer 要不展开描述下。

不是特别赞同你的观点。

你的说法忽略了很重要的一个环节，经验+思路+视野。

在软件工程中，每种需求都会有多种实现方式，需要分几部分、几块实现，每部分实现采用的关键技术，哪部分是最关键的。 这些都属于架构师考虑的一部分。这部分应该很多高级开发人员不能承担。

基于敏捷，实现的思路和碰到问题如何解决也是架构师需要快速反馈的一点。

或者，绝招同途异路（前名是论武功，尘世中不知边个高 :) )

编程有个人风格。很多好的程序员不是好的政工人员。