Jackyfei

如何在招聘中考核.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原则;事中是否有效执行,风险如何做预案;事后有没有归纳总结等。

三、问题设置

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

 

posted @ 2019-02-20 09:58 张飞洪 阅读(...) 评论(...) 编辑 收藏