TIP
本文主要是介绍 技术能力-评估要素总结 。
# 如何真正识别一个程序员能力的高低？我们可以通过这几点！
平时我们程序员都是不显山露水的，感觉大部分人都是同一种样子：双肩包？格子衫？头发或蓬松或稀疏。有些网友就开玩笑：我们要看一个程序员厉不厉害，看看发际线不是一目了然！其实不然，头发少有些因为熬夜呀，或者虚耗你的身体等之类的原因。好了！笑谈归笑谈，那么如何真正分别出一个程序员能力的高低呢？我们其实可以通过这几点！
# 编程基本功
说到基本功可能范围非常广泛，有编程语言语法方面的也有编程算法需要的数学基础，甚至直接阅读英文文档的熟练程度也是基本功的一种体现。
在良好的基本功的驱动下，编程能力会有一个非常大的提升。
曾经共事过一个同事，在编程写代码的时候写过的代码几乎都是一遍过，很少回过头来修改，这是基本功非常直接的表现。
# 解决复杂问题的能力
这是一种无形的能力，在项目推进过程中有些人针对遇到的问题总能想出恰当的解决方案，把复杂的问题简单化。
实际项目推进过程中需要这种人进行攻坚，这是一种综合能力的体现，需要长时间的修炼完成，很多初学者甚至都不能讲一个问题描述表达清楚差距一目了然。
# 编程框架思想
这点主要是写的代码模块，维护性非常高，能提前想到可能用到的场景，后续添加新的功能也不会影响现有的功能，这都是框架思想一种体现，有些工作很多年的程序员都不具备整体框架设计能力，除了经验积累之外有时候需要些许灵气补充。
编程的核心本质是解决问题能力以及框架思想能力，单纯的一些工具的使用只是锦上添花的作用，很难成为点睛之笔。
# 【----------------------------】
# 如何看出一个程序员的技术能力和水平？
这个题目是比较复杂的，它包含的东西比较多，认真讨论估计能写几万字。如果是专业研究，我看能写一本书了。这里打算根据自己的学习过程和工作经验，谈一下要点问题，均属个人看法，欢迎讨论。
写这篇文章的初衷，跟前段时间跟朋友们聊招聘有关。因为技术招聘除了考察人的协作精神和工作态度，一大目标便是判断人的技术能力和实际水平。在这件事情上多做观察、思考是很有意义的。
对于考察人的技术等级，学界是有认真的研究的。参见：德雷福斯模型解说。
德雷福斯模型把人的技能水平，分成 5 级：新手、高级新手、胜任者、精通者、专家。
# 对不同技能等级的认定是这样的：
新手：依靠指令清单，必须按部就班。就是必须给出详细而具体的操作规则，才能工作。比如你做一道从未做过的菜，需要看菜谱的说明，第一步做什么，第二步做什么等等，直到最后烹饪结束。
高级新手：有限的情景洞察力，同等对待工作的各个方面。对全局性、体系性的东西没兴趣。这是小工的水平。比如他能跟着师傅干点活，打打下手。可以靠着反复检索搜索引擎、StackOverflow 解决具体的小问题。
胜任者：能够独立解决各种各样的领域内问题。这是一般的企业招聘，比较希望招到的等级，招进来稍作适应就能干活了，省心省力。
精通者：经验丰富，可以自我纠正、自我改进。这类等级的人，思考可以指向内在，通过反省、反馈改善技能。这种在企业可以算上高手、大拿了，培养不易。
专家：依靠直觉工作，不需要解释和理由。实际你让他解释，他可能也说不出个所以然，就是直觉给出答案，然后还是对的。专家人数稀少，需要很长时间训练、实践。通常的说法是 10 年出专家，10000 小时定律。
这个是理论上的研究，实践中比较缺乏操作性，难以迅速的判定应聘者的实际情况。不信你打开收进来的大把简历，刚毕业的学生，每个技能名词上面都是一堆堆的“精通” – 你相信么？但它可以当成一个职业技能等级判定的参照标准。
于是乎，各家企业开启了各种“笔试”、“机试”，多轮面试，并且严格要求学历以及出身院校，试图以此过滤掉不合意的应征者，留下合格的人选。它当然是可行的，但是效果一般，而且容易出错，错失有思想有水平的人。不然也不会催生出各类“推荐式”的招聘。
看重学历、学校当然也有其优点：它是快速过滤的手段，毕竟能考上好学校的人智商不会太差吧。但在大数字公司的一朋友说，公司里面还有初中毕业，一直精研安全领域的人，技术能力也是十分出色。如果严苛对待背景，这些人就会错过了。因为人的生活多种多样，有各种历史的背景因素影响经历。而部分人的经历，就是跟一些人不同的，可是不妨碍他们同样可以变得优秀。招聘，实际上是建立信任关系。如果有充足的信息证明，应聘者足够优秀，这就够了。条条框框只是辅助手段，并不是目的。
# 如何招聘到高能力的程序员
任正非的洞察力一流
# 推荐式招聘
推荐式的招聘实际要靠谱的多，因为人很容易了解熟悉的人的水平。这是靠推荐者的信用背书。人平时沟通时说什么话，日常看什么书，关注哪些领域，琢磨过啥问题，哪些东西很熟，这个经常聊的熟人往往都知道。可是，这类招聘局限性也很大：面窄、靠机缘。靠推荐能招几个好手啊？好手往往是各家争抢的对象，窗口期有限，基本不会缺工作的。
说了一圈，还是要在技能水准判定上有更高效率的办法，招进合适的人来。
# 岗位胜任能力评价
回到开头的德雷福斯模型，既然人的技能是分级的，那么对待不同的职位要求，也应该侧重不同的考察角度。如果千篇一律的走招聘流程，就容易出问题了。比如你明明要找的是“精通者”，可上来就让人一堆笔试、机试，这是不合适的。对方会十分的厌烦。体现高水平技术能力的并不在默写什么“字符串算法”那里。这反倒是刚毕业的人占便宜，因为才学过不久，印象深。不信你让工作 10 年的人跟计算机专业应届生比比写排序算法，真未必能赢。但是这并不重要 – 你干活不看手册不查文档吗？聪明人从不死记硬背。重要的地方在于对问题域的准确、深刻的理解，对各类技术优劣点、各种条件平衡的评判和把握。
对待初阶新人，应着重考察的是基本功是否扎实，专业成绩是否优秀。更重要的，是他对职业的热情，学习能力和研究精神。某类人要说起技术来，滔滔不绝，两眼放光，充满热情，对未知的、新生的各类概念、技术非常好奇，这种人想差都难。因为他会自我驱动，不用督促，自己就钻研前进。反之，觉得这个职业待遇高，只是想混饭吃的人，很少走得长远。这类初阶新人以毕业生、工作年限少者为多。测试考核，可以笔试查看其对基础概念的理解是否准确，知识领域的大致范围。甚至，布置一个有点挑战性的小任务，让他尝试解决，说明思路。
考察胜任、精通者的策略不一样。笔试做题没啥用，原因前面说了。这类招聘是重头戏，企业都喜欢找这样的，能干活。所以考核评估的地方也较多。我觉得可以分成几个方面去看。意识是否先进，是否会反省思考；是否善于解决问题，富有创造性；是否有比较深的积累和广阔的知识面。
# 开发者学习和创新能力
业界的开发思想也是在不断变化，工具链一直在革新。聪明的人不用蛮力，而爱用工具提升效率，喜欢自动化操作解放人力。要查看人用什么开发工具链，用什么开发环境，解释下为什么？好的开发者会及时注意新出现的工具，挖掘它能解决什么问题，并尝试吸收，解决自己的需求。如果没有这个思想意识，工作效率就会打折扣了。因为你会落后行业发展水平。人善于自我反省，则会催动自我纠正，这正是精通者的特征。参考：优秀的开发者为什么要学习研究新的编程语言？
解决问题的能力是重头戏，也是企业招聘人的主因。人要善于解决实际问题，而且，要学会聪明的解决问题。解决问题要看思路，看手段，看是否有创造性，这是真正考验人能力的地方。好的开发者，会考虑很多可能选项，预估各种优劣，给出一个较优的方案。 遇到难题，会用各种方法尝试。经验丰富的人，常常会使用技术的组合手段来处理难题，而不是一个语言一个工具到处用。所以，要查看下过往的项目经历遇到的问题、困难，是如何解决的，思路如何。一些公司据说不招聘不会用谷歌的工程师。谷歌打不开？嘿嘿，这就是你要克服的困难啊。这你都解决不了，还做什么研发。谷歌是人类最全、最新知识的总索引，充分利用事半功倍。
# 广度深度考察
考察知识的深度、广度，对重要领域的概念是否有深刻的理解和掌握，以及从各类工作经验中得到的认知。问问他看过什么书，研究过什么东西。说白了，知道的东西是否多。一些公司很喜欢用 CheckList 模式来考核，列一堆领域的知识点、概念，问人懂不懂，知道就是水平好，不懂就是水平差。实际情况并非如此。人的工作过程是独立的，一些事情如果没有工作机会去接触并解决，那么一些冷僻的问题就永远都碰不上。当然也就不知道。但你能说没做过就一定做不好么？
# 合理的技能树(全栈 or 高级专家)
另外，人的技能树，其实也是“犬牙交错、参差不齐”的。什么意思？技术领域非常的广阔，你真的没办法每个领域都很精通，实际上是这个做的多，懂的多，那个用的少，知道的少。这个时候，应看具体知识领域，是哪一类。它是否需要复杂的、难度较高的背景。门槛高的技术，需要的配套技能多得多，比如 AI、机器学习。而一般产品应用领域则不然，了解核心概念、设计意图，看着手册、最佳实践，也就能上手了。这个暂时不会，实际无关紧要的，工作一段学的认真点就会了。但是门槛高的领域，就需要很长时间的学习了。这是本质的差别。
我曾看见某公司放出的职员技能树，包罗万象，几乎一切 IT 领域的知识技能都在里面了，还声称要求“全部精通”。我不知道它如何定义的“精通”，如果按德雷福斯模型的定义，能做到的那是神，不是人类。这个纯属吹牛皮，我压根就不信。如果真有这样的人，出来让我膜拜下。因为每个稍大点的领域，都足够让你钻研一辈子，因为它们也在迅速发展呀。业内流传“全栈工程师”的说法，鼓吹自己是全栈的人经常是前端工程师。而研究后端工作领域的技术高手经常鄙视这类人：真以为会点 Node.js 就能解决一堆后端的事务了么？我也懂一些前端，也能号称“全栈”，但在不同领域的专业性是什么水准，自己明白的很。前端要解决的事情也有很多复杂性。全栈实际是反专业化的，是人力资源稀缺时候的低成本选择。
更高一层，则是考察人本身了。人的视野够广阔么？其它领域的知识有了解吗？一些问题的解答并不在问题域本身，而是在外面的领域。所谓“功夫在诗外”。公司讲求团队协作，总要面临不同的分工合作问题。比如产品、运营的人提需求，可以换位思考吗？合作意识强么？谁也不想招个刺头进来吧？把团队的气氛和人际关系搞的一团糟，大家做事都不痛快、不顺心，又如何安心做好工作？最终只能让团队工作效率下降，甚至瓦解。
要说专家，实际上有研究者认为是需要刻意练习 + 充分实践才能功成。并不是每个人经过足够的工作年限，都自动成为专家。有的人工作 10 年，可能后面 9 年都在重复第一年的工作任务，毫无改进。而职业上的训练机会，又跟大环境乃至运气息息相关，并不是每个人都有机缘的。但是把个人的职业技能做到胜任乃至精通，则是完全可行的，这只需要认真和勤奋，工作态度问题。
# 【----------------------------】
# 能力评估参考摘选-能力分类
# 第一新领域的上手和学习能力
我觉得第一要看新领域的上手和学习能力。比如，从来没有用过go，让你用go实现一个东西要花多长时间？一个纯陌生的codebase，要实现一个需求要花多少时间？去一个新的公司或者新的部门，第一个项目要花多少时间？
我把这个放第一，不光因为技术更新换代快，不停要学习新技能。更是因为，第一印象太重要了。我曾经有个超级厉害的实习生。周一入职，我给她介绍了一下项目要做啥，给了一个code pointer，然后她就去参加为期一周的培训了。周五结束培训的时候，她跑来找我，给了我一个一千来行的end to end的整个项目的原型系统。她后来提前一年本科毕业，入职Google，并为入职9个月从3升4，是我见过的最快的人之一了。 而对应的，差一点的程序员，上手真的需要手把手的教，得把任务分解得很细很细，甚至每个很细很细的任务都得把伪代码或者code example给他写好。再差的程序猿，拿着code example和tutorial也都看不懂，入职两个月一行代码也写不出来，我也是醉了。
# 第二是领域的熟悉程度。
如果负责的产品出现了奇怪现象（bug），你能很快反应出哪儿可能出问题吗？公司里面别人有这个方面的问题，第一个会想到来问你吗？ 举个例子，以前一个回答也提到过。某天下班前，突然发现了一个惊天大bug 。我当时debug了半个小时毫无头绪，于是找老板汇报。老板马上说这个问题可能出现在A或者B或者C，C是最后可能的，你马上去看一下这个地方验证一下是不是Ｃ。最后问题很快解决，按时下了班。
# 第三是解决问题分解问题的能力。
比如debug，假设有人在论坛上讨论你们产品的奇怪现象，你能根据论坛上的讨论直找出bug 吗？一个性能优化目标，你会如何着手找出bottleneck？一个open problem，如何把问题简化？
我就真遇到一次Twitter 上大家讨论我们产品的奇怪现象，一群领导们一脸懵逼无法复现bug甚至不能确定这是一个bug，PR不准我们去直接找Twitter讨论的人，技术支持那儿也没收到任何bug report。我那天看到那么多领导在讨论，冲动了一下想刷visibility，就写了个脚本来搜log，猜了根据Twitter描述猜的一些条件sample了一堆可能出现bug的账号。然后手动后台登录看看这些账号有没有这些奇怪现象。十来分钟我就找到第一个出bug的账号。然后根据这个账号改进了一下脚本，更精确地sample出来了几千个受影响的账号。然后再一个小时写了个脚本抓了这几千个账号的live traffic。再然后领导们都知道我了，根据我的推测找到了对应部门拿着我的东西接着debug了，还给我发了个几千美刀的spot bonus。感觉这是我hourly pay最高的一次了。顺便，出bug 的这个系统，我从来一行代码都没碰过，整个过程纯黑盒的。
# 第四，领导力。
领导力不是领导才有的能力。领导自己也是领导力。比如自己的项目，自己能自信地做出正确技术决断吗，甚至能说服领导，还是必须请示领导怎么做决定？自己项目能规划好工期，给出准确的时间预估吗？知道自己下一步应该做什么吗？
我的期待，初级程序员能规划自己一周做啥。中级程序员能规划一个月。特别优秀的程序员老板把任务布置下去后，就可以不用操心，等着直接收成果了。如果要每天去告诉这个程序猿今天该做啥，做完第一步永远想不到下一步，作为领导表示这种程序猿也不算不能干活，就是带得真的很累。
# 第五，团队协作沟通能力。
比如你的领导，你的团队，知道你的进度和进展是否顺利吗？你能处理和团队成员的冲突吗？你和领导，团队意见不一致的时候如何处理？你能推动夸部门合作吗，跨部门的沟通顺畅吗？你能带新人培养新人吗？你能临危受命去救火吗？你能带团队吗？
# 第六，产品/业务认识。
你知道你的部门做什么样的产品和业务是有意义的吗？产品提出不靠谱的要求你能有理有据把他打回去，而且大佬们都觉得你更有道理而不是产品更有道理？你有能力和客户直接沟通聊需求吗？
我觉得一个优秀的程序员，尤其是级别特别高的，由于对领域特别熟，会参与和拍板产品相关的很多方面，很多时候会和产品重叠。所以市场调研，客户采访，需求分析什么的，不说做的比PM好，至少会做并且不会被不靠谱的PM带入坑。不说跳槽能拿到同级别的PM职位，跳槽做个比平均水平高的的同领域的PM没啥难度。
以上是我想到的硅谷的优秀程序猿的标准。我猜国内（部分）也通用吧。
# 【----------------------------】
# 能力评估参考摘选-招聘
这个问题是每年招聘的时候都会遇到的问题哈！正确的问法应该是怎样在比较短的时间内辨别一个程序员水平的高低。因为如果给你个三五年的时间天天盯着他，估计什么方法都是好用的。而这个过程需求量最大的时候就是招聘的时候，候选人太多，要迅速筛出来优质的苗子为公司所用。
# 首先第零点公理，相同的方法，时间越长，辨别度越高
这个上面也提到了，你花在一个候选人身上的时间越长就对他了解的越多，对他综合素质的评价就会越准确。所以下面就不说时间的事情了，说说我们公司招人时候的一些点吧。
# 第一，知识的考察。
这个是几乎每个公司都会做的，也是很有效的手段，基本就是考试。包括问语法问标准算法问API问一切有标准答案的问题。一个人懂得多，不一定写得特别好，但是什么都不懂一定写不明白。这个方式还可以按需求选人才，比如我们就在php做前端，那我就可以问一堆关于php的，如果我是做嵌入式的，那我可以问一堆c。可以考察这个程序员在和公司需求的交集上完成的怎么样。这也是最最简单和直观的方法。
# 第二，对过往项目的理解
这个也是在简历关很常问的，说说你当时做的这个项目吧。这个问题非常有效地考察了他是否理解他之前做的东西。有的人简历写的巨漂亮可是实际那项目和他没关系，或者他就是复制粘贴的代码，其实自己啥都没写。这种时候你和他聊的足够深入之后能很明显地发现他自己说不明白了。同时还可以考察一定的语言表达能力和逻辑能力。用我们的话说，先问到面试官不会的深度，然后让他给面试官讲明白。如果他做的东西，他蒙圈的时候比面试官还早（前提是面试官不是搞这方向的），那一般就比较悲剧了。
# 第三，对写程序本身的理解。
我们很喜欢问一道题，描述一下你是怎么写程序的。凡是说我事先design好所有的模块、接口、功能，然后逐一实现，然后程序就work的，我们都心里默默补上“呵呵”。因为这是不可能的，只能说明他没写过大程序或者没总结过写程序的经验。没有人在完成一千行以上的程序的时候在没写之前就做好所有模块设计的，何况更大的程序。当然还有就是他会不会认为程序跑通一次就完成了（即写程序有没有test阶段）之类的。
# 第四，动手写程序的能力。
这个说实话是面试的时候不太容易考的，因为时间有限。现在的大公司基本是45－60分钟一轮，一轮还要问好几个程序题，所以写的代码都是片段的，大概20行左右，根本没法体现一个人会不会写程序。所以很多人不需要会写程序，只需要刷好leetcode之类的算法题库就可以进大公司（相信我我认识很多）。
我们认为一个好的程序员一定要在限定时间之内完成一个完整工作，满足要求的程序。从输入到输出到corner case的验证。而不仅仅是研究明白某个基础算法如何用nlogn而不是n^2解决。这一关卡下去了无数看起来很美好的人。因为我们的题目是不可能在那个时间内找到最优解的，就像绝大部分工程中的编程一样。一个较好的可用解往往比最优解要有价值的多，因为后者需要大量的时间，很可能没有前者直白，而且提升未必很高。这是我们公司最在乎的一点。
当然，这说的都是面试过程中的方法，如果你想辨别同事是不是厉害，问问他就行了。
# 【----------------------------】
# 能力评估参考摘选
程序员行业有一个特点：优秀程序员的产出是普通程序员的好多倍，甚至是10倍！这是因为编程不是一门「线性科学」，而是一门「非线性科学」。
「线性科学」，比如跑步的速度就是，世界冠军的速度也不可能是普通人的10倍。「非线性科学」是指很多种因素交汇在一起，极大增加了系统的复杂度。
而蹩足的程序员实际上还有副作用，不少团队光是处理前人埋下的坑，就耗费了全部精力。
成为优秀程序员不易，我们首先要避开「复制粘贴」、「造轮子」、「布道」这三个陷阱。
进一步，我们要做到以下7点：
# 1.具备裸编程能力
处理程序实际实现部分的子任务，实现函数或者算法之类的能力。
听起来很简单对吧？实际上很多程序员缺失这样的能力。
# 2.具备强悍的调试能力
调试能力某种程度上比编码能力更重要。查找和解决BUG会占用程序员大量的时间。
查找BUG产生的根源不是一件简单的事情，需要整体的分析和经验的沉淀，同时还需要对各种调试工具熟练应用。
# 3.追求简约
代码的注释是否恰到好处、函数模块和类的结构是否能让其他人直接秒懂、架构的设计是否足够清晰等等，都属于程序员追求简约的范畴。
# 4.准确预计工期的能力
老板想了个idea授意产品经理估工期。产品经理原型都没画出来，只有个大概想法，就找技术排工期。
这个时候，技术的内心大概多了几道菜式：清蒸产品经理、红烧产品总监、油炸CTO。其实准确预测技术工期是程序员一项非常重要的能力。为什么这么说？只有具备这项能力，才能让开发工作游刃有余、可进可退。
# 5.理解底层系统原理
比如数据结构、网络协议、操作系统相关知识，等等。
程序的很多问题都是源于对计算机工作原理的误解，即使是使用高级语言开发的程序也一样。
另外，一些更偏应用层的架构或框架，基础一定是更底层的系统。
# 6.严格把控关键设计
无论是大的系统还是小的模块，一定都有最关键的功能。要在最关键功能上投入大量设计时间，才能规避开发过程中的各种坑。
# 7.拒绝完美主义
完美主义包含两种情况，一种是追求极致性能的工程师文化、还有一种是个人性格使然。无论哪一种，过分追求完美都会对业务交付产生影响。
程序员之间的差距，恐怕要比人类和猿猴之间的差距，还要大。
# 参考文章
- https://www.bilibili.com/read/cv2292463/
- https://blog.csdn.net/xiamiflying/article/details/81477821
- https://www.zhihu.com/question/35194924
