• 如何识别人的技术能力和水平?


     

    作者: 威灵顿  发布时间: 2018-04-16 17:57  阅读: 3231 次  推荐: 13   原文链接   [收藏]  
    博文链接https://kb.cnblogs.com/page/593985/
     

      这个题目是比较复杂的,它包含的东西比较多,认真讨论估计能写几万字。如果是专业研究,我看能写一本书了。这里打算根据自己的学习过程和工作经验,谈一下要点问题,均属个人看法,欢迎讨论。

      写这篇文章的初衷,跟前段时间跟朋友们聊招聘有关。因为技术招聘除了考察人的协作精神和工作态度,一大目标便是判断人的技术能力和实际水平。在这件事情上多做观察、思考是很有意义的。

      对于考察人的技术等级,学界是有认真的研究的。参见:德雷福斯模型解说

      德雷福斯模型把人的技能水平,分成5级:新手、高级新手、胜任者、精通者、专家。

      对不同技能等级的认定是这样的:

    • 新手:依靠指令清单,必须按部就班。就是必须给出详细而具体的操作规则,才能工作。比如你做一道从未做过的菜,需要看菜谱的说明,第一步做什么,第二步做什么等等,直到最后烹饪结束。
    • 高级新手:有限的情景洞察力,同等对待工作的各个方面。对全局性、体系性的东西没兴趣。这是小工的水平。比如他能跟着师傅干点活,打打下手。可以靠着反复检索搜索引擎、StackOverflow解决具体的小问题。
    • 胜任者:能够独立解决各种各样的领域内问题。这是一般的企业招聘,比较希望招到的等级,招进来稍作适应就能干活了,省心省力。
    • 精通者:经验丰富,可以自我纠正、自我改进。这类等级的人,思考可以指向内在,通过反省、反馈改善技能。这种在企业可以算上高手、大拿了,培养不易。
    • 专家:依靠直觉工作,不需要解释和理由。实际你让他解释,他可能也说不出个所以然,就是直觉给出答案,然后还是对的。专家人数稀少,需要很长时间训练、实践。通常的说法是10年出专家,10000小时定律。

      这个是理论上的研究,实践中比较缺乏操作性,难以迅速的判定应聘者的实际情况。不信你打开收进来的大把简历,刚毕业的学生,每个技能名词上面都是一堆堆的“精通” – 你相信么?但它可以当成一个职业技能等级判定的参照标准。

      于是乎,各家企业开启了各种“笔试”、“机试”,多轮面试,并且严格要求学历以及出身院校,试图以此过滤掉不合意的应征者,留下合格的人选。它当然是可行的,但是效果一般,而且容易出错,错失有思想有水平的人。不然也不会催生出各类“推荐式”的招聘。看重学历、学校当然也有其优点:它是快速过滤的手段,毕竟能考上好学校的人智商不会太差吧。但在大数字公司的一朋友说,公司里面还有初中毕业,一直精研安全领域的人,技术能力也是十分出色。如果严苛对待背景,这些人就会错过了。因为人的生活多种多样,有各种历史的背景因素影响经历。而部分人的经历,就是跟一些人不同的,可是不妨碍他们同样可以变得优秀。招聘,实际上是建立信任关系。如果有充足的信息证明,应聘者足够优秀,这就够了。条条框框只是辅助手段,并不是目的。

    任正非的洞察力一流

      推荐式的招聘实际要靠谱的多,因为人很容易了解熟悉的人的水平。这是靠推荐者的信用背书。人平时沟通时说什么话,日常看什么书,关注哪些领域,琢磨过啥问题,哪些东西很熟,这个经常聊的熟人往往都知道。可是,这类招聘局限性也很大:面窄、靠机缘。靠推荐能招几个好手啊?好手往往是各家争抢的对象,窗口期有限,基本不会缺工作的。

      说了一圈,还是要在技能水准判定上有更高效率的办法,招进合适的人来。

      回到开头的德雷福斯模型,既然人的技能是分级的,那么对待不同的职位要求,也应该侧重不同的考察角度。如果千篇一律的走招聘流程,就容易出问题了。比如你明明要找的是“精通者”,可上来就让人一堆笔试、机试,这是不合适的。对方会十分的厌烦。体现高水平技术能力的并不在默写什么“字符串算法”那里。这反倒是刚毕业的人占便宜,因为才学过不久,印象深。不信你让工作10年的人跟计算机专业应届生比比写排序算法,真未必能赢。但是这并不重要 – 你干活不看手册不查文档吗?聪明人从不死记硬背。重要的地方在于对问题域的准确、深刻的理解,对各类技术优劣点、各种条件平衡的评判和把握。

      对待初阶新人,应着重考察的是基本功是否扎实,专业成绩是否优秀。更重要的,是他对职业的热情,学习能力和研究精神。某类人要说起技术来,滔滔不绝,两眼放光,充满热情,对未知的、新生的各类概念、技术非常好奇,这种人想差都难。因为他会自我驱动,不用督促,自己就钻研前进。反之,觉得这个职业待遇高,只是想混饭吃的人,很少走得长远。这类初阶新人以毕业生、工作年限少者为多。测试考核,可以笔试查看其对基础概念的理解是否准确,知识领域的大致范围。甚至,布置一个有点挑战性的小任务,让他尝试解决,说明思路。

      考察胜任、精通者的策略不一样。笔试做题没啥用,原因前面说了。这类招聘是重头戏,企业都喜欢找这样的,能干活。所以考核评估的地方也较多。我觉得可以分成几个方面去看。意识是否先进,是否会反省思考;是否善于解决问题,富有创造性;是否有比较深的积累和广阔的知识面。

      业界的开发思想也是在不断变化,工具链一直在革新。聪明的人不用蛮力,而爱用工具提升效率,喜欢自动化操作解放人力。要查看人用什么开发工具链,用什么开发环境,解释下为什么?好的开发者会及时注意新出现的工具,挖掘它能解决什么问题,并尝试吸收,解决自己的需求。如果没有这个思想意识,工作效率就会打折扣了。因为你会落后行业发展水平。人善于自我反省,则会催动自我纠正,这正是精通者的特征。参考:优秀的开发者为什么要学习研究新的编程语言?

      解决问题的能力是重头戏,也是企业招聘人的主因。人要善于解决实际问题,而且,要学会聪明的解决问题。解决问题要看思路,看手段,看是否有创造性,这是真正考验人能力的地方。好的开发者,会考虑很多可能选项,预估各种优劣,给出一个较优的方案。 遇到难题,会用各种方法尝试。经验丰富的人,常常会使用技术的组合手段来处理难题,而不是一个语言一个工具到处用。所以,要查看下过往的项目经历遇到的问题、困难,是如何解决的,思路如何。一些公司据说不招聘不会用谷歌的工程师。谷歌打不开?嘿嘿,这就是你要克服的困难啊。这你都解决不了,还做什么研发。谷歌是人类最全、最新知识的总索引,充分利用事半功倍。

      考察知识的深度、广度,对重要领域的概念是否有深刻的理解和掌握,以及从各类工作经验中得到的认知。问问他看过什么书,研究过什么东西。说白了,知道的东西是否多。一些公司很喜欢用CheckList模式来考核,列一堆领域的知识点、概念,问人懂不懂,知道就是水平好,不懂就是水平差。实际情况并非如此。人的工作过程是独立的,一些事情如果没有工作机会去接触并解决,那么一些冷僻的问题就永远都碰不上。当然也就不知道。但你能说没做过就一定做不好么?

      另外,人的技能树,其实也是“犬牙交错、参差不齐”的。什么意思?技术领域非常的广阔,你真的没办法每个领域都很精通,实际上是这个做的多,懂的多,那个用的少,知道的少。这个时候,应看具体知识领域,是哪一类。它是否需要复杂的、难度较高的背景。门槛高的技术,需要的配套技能多得多,比如AI、机器学习。而一般产品应用领域则不然,了解核心概念、设计意图,看着手册、最佳实践,也就能上手了。这个暂时不会,实际无关紧要的,工作一段学的认真点就会了。但是门槛高的领域,就需要很长时间的学习了。这是本质的差别。

      我曾看见某公司放出的职员技能树,包罗万象,几乎一切IT领域的知识技能都在里面了,还声称要求“全部精通”。我不知道它如何定义的“精通”,如果按德雷福斯模型的定义,能做到的那是神,不是人类。这个纯属吹牛皮,我压根就不信。如果真有这样的人,出来让我膜拜下。因为每个稍大点的领域,都足够让你钻研一辈子,因为它们也在迅速发展呀。业内流传“全栈工程师”的说法,鼓吹自己是全栈的人经常是前端工程师。而研究后端工作领域的技术高手经常鄙视这类人:真以为会点Node.js就能解决一堆后端的事务了么?我也懂一些前端,也能号称“全栈”,但在不同领域的专业性是什么水准,自己明白的很。前端要解决的事情也有很多复杂性。全栈实际是反专业化的,是人力资源稀缺时候的低成本选择。

      更高一层,则是考察人本身了。人的视野够广阔么?其它领域的知识有了解吗?一些问题的解答并不在问题域本身,而是在外面的领域。所谓“功夫在诗外”。公司讲求团队协作,总要面临不同的分工合作问题。比如产品、运营的人提需求,可以换位思考吗?合作意识强么?谁也不想招个刺头进来吧?把团队的气氛和人际关系搞的一团糟,大家做事都不痛快、不顺心,又如何安心做好工作?最终只能让团队工作效率下降,甚至瓦解。

      要说专家,实际上有研究者认为是需要刻意练习+充分实践才能功成。并不是每个人经过足够的工作年限,都自动成为专家。有的人工作10年,可能后面9年都在重复第一年的工作任务,毫无改进。而职业上的训练机会,又跟大环境乃至运气息息相关,并不是每个人都有机缘的。但是把个人的职业技能做到胜任乃至精通,则是完全可行的,这只需要认真和勤奋,工作态度问题。

  • 相关阅读:
    SAP C4C OBN(Object Based Navigation)不能工作的原因分析
    使用SAP C4C自定义BO association创建动态下拉列表
    如何使用SAP HANA Studio的PlanViz分析CDS view性能问题
    如何使用jMeter测试SAP OData服务并发访问时的性能
    OData服务在SAP CRM,Cloud for Customer和S/4HANA上的实现比较
    SAP UI5和Vue的数据双向绑定实现原理比较
    在SAP WebClient UI里显示倒数计时的UI
    【年度重磅】2020华为云社区年度技术精选合集,700页+免费下载!
    面试必问:如何实现Redis分布式锁
    聊聊架构模式的变迁:从分层架构到微服务架构
  • 原文地址:https://www.cnblogs.com/mike-mei/p/8884113.html
Copyright © 2020-2023  润新知