如何在招聘中考核.NET架构师

.NET架构师招聘不如JAVA那么顺利，可以搜索到的.NET架构师可以说是凤毛菱角。当然好的架构师都是需要长期观察和挖角才能得手，如何去招聘到合适的.NET架构师可能是摆在所有求贤者面前的难题。这里的难分两方面，一个是数量少，二个是考核点难。那么到底.NET架构师需要具备哪些必备的技能和素质呢？这里结合这次公司的招聘遇到的困难和个人对架构师的理解，做以下的分享。

一、技能方面

　　在写招聘技能要求的时候，脑子里会闪现一系列清单，比如

• 不低于5年的基于.NET平台架构设计经验【必须】

• 融会贯通常用的设计模式【必须】

• 扎实的数据结构和算法、操作系统、网络等基础知识【必须】

• 熟悉分布式架构设计和实战经验，有大型分布式系统架构的实际经验，比如分布式事务、分布式存储、性能调优、高并发、高可用的设计经验；【必须】

• 熟悉流程引擎，规则引擎，消息引擎；有Redis或Kafka或RabbitMQ等中间件使用或开发经验。【必须】

• 对新技术有一定的敏锐度，有广博的知识面，虽然不一定很深入，但是能很好的做技术判断和选型。【必须】

• 熟悉基于.NET Core的微服务架构和相关技术栈；熟悉Docker容器化技术，对K8S有一定的熟悉度；有DevOps的开发经验【加分】

• 拥有自己的开源的框架，并且Star数量不低于某一个阈值【加分】

• 拥有自己的博客，具备长期写博的习惯【加分】

• 研究并精通不少于5个以上的开源框架【加分】

• 有物联网架构经验优先考虑【加分】

• 高效强大、持续输出的学习能力，特别是对新技术有比较敏锐的意识【非必须】

• 有大数据业务处理的实践经验优先考虑。【非必须】

• 社区活跃度高，有个人技术博客或个人开源框架【非必须】

　　由于公司要招牛人，我想怎么的也要技术在我之上，于是就有了上面的内容，不知道这个清单看起来有没有恐怖，至少我写完自己吓一跳。写招聘需求的目的是要招到合适的人才，但是这个合适的度在哪儿？是不是为了招聘而招聘？至少个人觉得【必须】的选项对架构师的要求不算是高了。我有个困惑在为数不多的.NET架构师群体里，又是在小城市厦门，如何能淘到这个宝？就算存在，贤人也都是每个公司的宝贝，拿着不低的待遇和公司的荣誉，想去跳槽基本上是不大可能了，就算是跳了是否意愿继续做架构开发也是未知数。

　　所以非常的困惑和迷茫，想在.NET架构师池里挖到宝难度可想而知，除了更高的职位或待遇，对于中小公司挖宝的机会真的微乎其微。所以招聘的标准如果再往下调整调整，比如不苛求是否有自己的开源框架，也不必苛求是否有写博客的习惯，或者直接从高级开发招聘起，然后进行培养。从随手罗列的条件看，人才的缺乏源于对人才的苛刻要求，掌握这些技能的人除了要聪明还要能坚持，面对各种扑面而来的诱惑和浮躁的社会，能坚持下来的几乎又阵亡了不少。

二、非技能方面

　　当你对面试者的架构技术赞叹不已的时候，你也许会继续想去了解对方的非技术能力，具体要了解哪些内容呢？我这边结合自己在招聘过程中的经验，做如下几个维度的分享。非技术方面主要表现在角色认知，沟通能力，技术规划，技术管理，任务管理五个方面来考察。

　　这五个方面如果单独写可以形成一个专栏，这里只是为了招聘本身设置问题而做简单的分析。

2.1角色认知：

　　为什么架构师要有角色认知的概念。我觉得有个重要的原因是很多架构师从一线开发起来，往往喜欢过程导向，技术能力没有任何问题，但是忽视了自己除了是要攻克难题，还要服务其他的开发人员。至于如何巧妙得去提升团队的战斗力往往并没有投入思考。

角色认知应该是刘建国老师讲的，是空气，无处不在。因为架构师的成果最终还是要通过团队最后的结果来检验。所以无时无刻，无处不在的角色认知将最终决定一个项目的质量高低。至少架构师是通过服务他人来满足自己的成就感，所以我把这个角色认知放在招聘考核的首位。

2.2沟通能力：

　　沟通可以看做承载事情的大地，厚德载物。但我更细化把沟通看做润滑剂，从团队建设的齿轮模型来看，团队之间的协作不应该只是看得见的命令式，显得生硬，毕竟人不是代码和机器。更多的沟通应该回归文化和人性上，以人为本，遵循科学民主的方式来审视。

沟通大概分向上、向下、平级三个维度，如下图所示。架构师更多的是向上和向下两个方面居多，而最难的是向上沟通。

　　沟通也是技术人的短板，技术是死的，人是活的，很多技术人刚开始都会本能的排斥沟通，觉得和领导沟通太累了，一则领导喜欢神龙见首不见尾，不怎么懂细节，但是特别关注你的设计流程；二则明明很简单的内容，还要向领导汇报设计和实现思路，内心会本能的鄙视领导技术能力；三是汇报过程中的各自文档编写和PPT，会让技术人觉得没有技术水平。

　　以上是向上沟通的麻烦事，架构师内置管理因子这是这个岗位本身的重要性决定的。所以沟通看似务虚，其实非常关键，我把它作为考核的第二个位置。

2.3技术规划：

　　这里的规划主要指技术方面的规划和选型、研究。技术规划应该从哪几个维度来考核呢？这里借用前人的马车模型进行分析，如下图所示

　　马车模型至少包含以下四个要素：第一是要到达的架构目标是什么？第二是到达目的要选择什么路径？第三是马群这个团队要如何排兵布阵，以少胜多？第四是每匹马的职能要如何设置？

能对这四个要素很好的给出合理的方案，对症下药，开出针对性的技术药方，我觉得这种架构师应该值得去珍惜。

2.4技术管理：

　　我在想架构师其实并不是真正意义上的管理人员，但是他确有着管理整个项目技术的要求。也就是说架构师管的不是人，是技术，是属于有职无权的角色。当然不妨碍架构师可能拿的薪资比管理人员还高，我觉得这是合理的。

　　所以考核架构师如何把技术开发流程管理好，如何让技术落地开花，如何保证开发者规范、标准等等是技术之外的软实力。

2.5任务管理：

　　架构师有点像将军，除了自己有过硬技术本领，还要带兵打仗搞管理，兼职做点军师的活。所以任务分配，排兵布阵这些管理者做的事一个也不能少。那么如何去考察架构师的排兵布阵的能力呢？

这里参考我尊敬的刘老师的建议，按照时间维度，了解对方事前、事中、事后如何做技术管理。事前是如何做任务规划，这些规划是否遵循架构标准，是否遵循SMART原则；事中是否有效执行，风险如何做预案；事后有没有归纳总结等。

三、问题设置

　　以下是个人从以上两个方面设置的简单提问，纯属个人编制，希望对你有所启发。