怎么判断程序员怼产品

⑴ 产品经理该如何跟程序员沟通

产品经理面试的过程中面试官特别喜欢会问一个问题，如果开发人员以无时间为理由拒绝你的需求怎么办？工作中产品经理和技术人员打交道的次数太多了，行业内也流行着一些图片来调侃产品和技术之间的关系，两者的关系可以用相爱相杀来形容。

之所以这么说有两个理由，相爱是因为两者要互利合作，把老板交给的任务完成，而且只有彼此合作才能让工作进展的更顺利。相杀是因为这两个职业又存在着很大的矛盾，产品经理的需求间接决定了技术人员的工作量，有些技术人员确实对产品经理比较反感。

我也看过一些关于产品与技术如何沟通的文章。这篇文章我想结合我自己的亲身经验，分享一些小技巧，可以当做是保持良好关系的润滑剂。

1

首先我们分析一下技术与产品之间产生矛盾的原因。在分析之前，先设一个前提，每个公司在招人的时候都有其标准，寻找价值观相同的人，所以我一直都相信开发人员并不会无故找理由拖延项目周期。反过来，如果开发人员因为品性而偷懒或者说是耍心眼不干活的话，那就没办法了，个人主观因素太大。

第一种情况是产品经理的需求与开发人员手头的项目撞期了，解决的办法很简单，就是根据需求的优先级来调整开发排期。碰到这种事，有些领导也总是期望产品经理靠着自己的方法解决。但是除了跟上级领导申请调整优先级，没有别的好办法。一个客观事实，公司在多个项目中确实有优先级之分，虽然你自己的孩子自己最看重但是在别人眼里并不是这样。第二个原因是开发人员是按照公司意愿办事，说严重点你总不希望别人因为你的事情跟领导闹僵，搞砸自己的饭碗吧。

第二种情况技术人员并不认同产品经理的观点，虽然产品经理和技术人员各司其职，但是在工作中会碰到有些技术对产品特别关心，如果产品经理的做法自己不认同的话会提出质疑。如果质疑的人是技术老大，产品经理往往会更被动。遇到这种情况我觉得很正常，想办法说服技术人员。

除了搬出之前做的产品分析和用户调研外，我在工作中总结了一点经验，平时可以多跟技术聊聊天，增进彼此了解，观察他们经常上使用的产品，在沟通说服他们的过程中，可以拿他们经常用的产品举例，这样的话他们本身对那个产品更熟悉，自然也更好理解。另外，在跟技术讲解产品的时候也要适当的画饼，描绘一下产品上线成功后的美好未来，这会带动起他们的积极性。

2

产品经理要做好自己的基础工作，这利于给开发人员留个好印象。做好这方面的工作有两点，一是想好产品规划的原由，避免被技术的同学问住。技术人员也特别讨厌产品经理说“某某产品就是这么做的，我们按照他们的做就行了”这样的话；二是写好产品文档，在产品文档中避免有遗漏的地方，特别是一些比较复杂的功能，一定要解释清楚，因为技术人员会遵照着产品文档进行开发，所以说如果有疏漏的地方会增加沟通成本，如果文档写错了，造成开发出来的产品功能不符合预期就是产品经理的责任了。

为了提高文档的可读性，我们也可以多使用图文、流程图的表现形式，如果只是干巴巴的一个word文档，几千个文字，看起来确实很枯燥。

对于产品经理和开发人员来说信任尤为重要，如果开发对产品经理缺乏了信任，结果就是你的话开发人员不会再听了，每个需求他们需要经过你的领导确认后才会去做。获取对方信任的一个很重要前提就是说话算数，当技术人员询问你某一个问题时如果自己没想清楚，可以先暂时别回答，考虑清楚后再说。要是随口一说，过后又让开发人员修改，不仅会造成开发人员返工，这种行为也是非常不负责任的。

即便文档写的再完善，在产品开发过程中也难免需要当面沟通。项目跟进，需要产品经理极大的责任心和积极性。一个项目立项后，公司通常会把参与人员列为一个小组，产品人员需要根据开发排期跟进开发进展，避免开发出来的产品与预期不符，验收产品功能是否与产品期望一致。这个过程产品人员的工作往往会比较繁琐，也会比较忙，当然也会锻炼产品经理的沟通能力。

3

说一下行业内一直讨论的一个问题，产品经理该不该懂技术？我觉得这个问题并没有什么好讨论的，无论是从个人知识量还是从是否有利工作的角度讲肯定是懂技术要更好，而之所以能吸引那么大的热议，可能是由于很多产品经理不懂技术，但是又没有兴趣学习，所以心底一直会纠结这个问题。

从我个人的经验来看，特别是你做项目比较多的时候，会发现懂点技术跟技术人员沟通起来会顺畅很多，一个重要的体现是技术人员也很愿意跟你交流技术实现的一些想法，而不会说“算了，跟你说了也没用”这样的话。

产品经理懂技术还有一个很重要的益处是当业务部门提出需求时，自己就能评估出技术实现的可行性，对于实现起来比较困难的需求自己就可以跟业务部门商量优化方案。而不必每个功能都去询问技术，无形中也减少了技术的麻烦。

不过我跟很多人的观点也一样，产品经理对技术的了解不需要太精通，说到这我还得庆幸自己大学时候学的是计算机专业，虽然学的不好，但对于现在的工作还是非常有益处的。不过我在工作中也会碰到技术人员偶尔说了一个名词自己不理解的，这时候两种办法，要么主动问一下，要么自己去网上查，明白其中的逻辑关系，知道是怎么一回事就好。

毕竟术业有专攻，虽然我们希望知识越多越好，但也别给自己太大压力。况且技术知识也在更新迭代，他们使用的框架也会变化，技术的语言也有很多，如HTML、Java、PHP等，你不可能全都精通。

4

最后说点工作中会遇到的个人主观因素。

当产品经理跟其他部门提需求或是沟通确认的时候也不排除其他同事有未及时回复的情况，为了确保项目上线也为了争取资源，这个时候就需要产品人员更加主动一些，所以产品经理有时候还需要脸皮厚一点。

当提交一个需求给开发部门制定排期，你会发现他们都会把时间定的很充足。也许你会因此对其他同事有看法，但其实在工作中都是这样子，大家都不会把自己的时间安排的太紧张，而且还要考虑过程中可能会出现的风险因素，例如请假的情况。当然也不能把时间定的太长，那样老板该不开心了，所以最好是产品经理根据上线时间与开发人员定一个时间结点，让开发人员在这个时间点前完成即可。

⑵ 根据做项目的多少判断程序员的水准合理吗为什么呢

根据做项目的多少判断程序员的水准合理吗？为什么呢？程序员的水平，不是通过语言或外部表现就能看到的，不是看有多少技术，参与了多少项目，他会写多少博客，而是看他在实际业务场景中解决问题的能力，尤其是面对一些特殊复杂的问题，或在高强度和高压工作条件下解决问题的能力和态度。能够编写满足需求的代码不再是评判程序员的标准。

一个经验丰富的程序员能够承受来自各个方面的压力，在复杂条件下找到核心问题，通过深入分析找到问题的原因，并迅速处理。经过及时的回顾和总结，减少出现类似问题的概率。随着互联网的发展，越来越多的人涌向程序员的轨道，竞争越来越激烈，新技术层出不穷，更新和迭代速度很快，程序员使用的语言、框架和模式将发生巨大的变化。

如果你不主动学习，你可能很快就会过时。在日常工作中，程序员往往希望将业务、产品、运营，甚至老板作为对接交换需求和技术项目来连接和配合内部交换等，而流畅的沟通可以使事情推得更加顺畅高效，沟通或信息不对称，可能会导致项目启动时出现相反的情况（不要相信，这种事情真的发生过）。判断一个程序员的水平，核心是他解决问题的能力，而解决问题的能力需要坚实的基础支撑，要综合代码质量、项目经验、框架能力、逻辑思维等方面，而不仅仅是一个方面。

⑶ 有哪些话一听就知道一个程序员是个水货

其实如果要严格说起来，工作经验少于一年半的程序员基本上可以算是“假”的程序员。这里的“假”可以这样来理解。

你的编程能力只有复制粘贴的水准

刚工作的程序员大致可以分为两类人：1 高校毕业；2 培训班出身。对于第一类的人来说，在读书期间老师和学校教的内容都是基础内容，而且要学的内容非常的多。但学校只让你学广，并没有让学生专研一门学科。毕竟学校并不能保证每个学生对某个方向一定感兴趣，只能把基础知识教给学生。让学生自己去选择自己感兴趣的方向，自己自学。所以在校期间对于大部分学生来说，实战能力基本为零，都是像刚重生在新手村，无知茫然，这也是许多企业爱招应届生的原因。开始工作，基本只能靠谷歌、靠网络上网找代码，复制粘贴。这段时间就比谁找代码能力强了。而对于培训的人来说更是如此。不要看你在培训期间学习了非常多的编程知识，好像做了非常多的练习，甚至还自己写了一个实战项目。但这些都是在短时间内，靠着培训老师手把手带你们写的。你只管跟着老师走就好，不懂的问下老师就行。你根本就没有过自己的思考，就只懂：好！今天老师叫我们写这个代码！我们就写！换个角度来看，培训机构就像富士康工厂一样，批量制造编程机器，没有自己的思维。

想要摆脱“假”程序员的身份，你只有努力提升自己的编程水平，让自己有更好的能力。在工作上能靠自己的实力，去完成分配的任务。你只有这样才能提升，才能突破薪水的瓶颈，达到更高的层次。

⑷ HR怎么通过简历来判断程序员是否优秀

01.简历中项目的参与度、贡献度
简历本身的效用信息往往非常局限，看了简历之后，也难以形成对候选人的初步判断。但我们其实可以通过项目经历上的信息，来评估候选是否完整、深入参与其中。
在候选人简历的项目板块，我们可以查找是否有以下关键信息：本人在项目中的角色？比如后台系统开发，主导搭建了页面框架，提高代码质量；公共组建的提取、编写。解决了什么样的问题？比如通过自动化，让代码易于管理；统一的编码规范，更有利于多人合作，降低了代码出错率；性能上带来多少提升？比如单页应用让请求次数变少、页面呈现更快，用户体验更好了。通过以上信息，我们基本上可以判断候选人在项目中的角色，或者从解决的结果来看能基本评估出候选人在整个项目中的贡献度。
另外一种是简历上的项目阐述，可以通过以下两个例子对比：例子一：A：应用 xx 技术，解决了XXXB：应用 xx 技术，解决了XXX，出错率降低了 0.1% 等。例子二：A：结合使用 xx，实现了 app 登录和个人资料的自动填充B：结合使用 xx，实现了 app 登录和个人资料的自动填充，提高了多少的转化率我们可以直观看出，有量化的结果的项目履历更有说服力，也可以侧面证明候选人是有深度参与到项目中，才能对数据结果有一定的了解。
02.候选人在技术社区的使用情况
很多优秀的技术人才都有分享的习惯，比如在GitHub、知乎等社区都会分享一些自己的技术经验贴。通常来讲，如果候选人有在社区发帖的习惯，确实会增色不少。比如全球最大的开源社区GitHub，大多数程序员都会有账号，但这个只能算是真正的“圈内人”，如果是GitHub的重度用户，其实非常亮眼的：如候选人在GitHub发布的项目经常能收获很多follower和star，那正是其能力的体现，可以通过其贡献的项目来评估；如果能长期坚持使用GitHub，也能说明的是这个人心态比较开放，对业界比较关注、律己、有耐心；GitHub上大多数代码是经过长时间构思和反复修改重构，代码质量可以很好反映其当前的Code水平，其中也可以窥见解决问题的能力。
经常在技术社区发帖互动，可以说是判断是否为优秀技术程序员的加分项，但也只能是敲门砖，不能过份强调它的重要性。
03.通过代码笔试，直击简历
要看能力最终还是应该考查编码能力。面试官或HR其实可以通过一场在线笔试，在简历初筛阶段来进一步判断是否为大牛。
面试官可以设置一些耗时较短，考察具体硬技能的题目，来考察候选人的基本功，将简历造假的同学筛掉，在ShowMeBug笔试平台，支持不同职级、不同语言、不同维度等题目，面试官可以快速发一起一场笔试，可以节省面试官大量的时间；
对于简历中的项目，其实可以设计一个非常真实的问题，比如你目前有独立设计实现过一个完整的功能吗？你研发的这个功能产生了什么作用，你在项目中扮演一个什么角色？ShowMeBug笔试支持音视频题型，面试官可以量身设计，让候选人更加真实的回答。

⑸ 有哪些话一听就知道一个程序员是个水货

有hover切换功能，不能直接换成png ，现在的官网取消了hover才换的png

首先，有些公认的水货，比如熊节，根本就是一个文艺编辑，就不用废话了。其次，有争议的，比如陈皓。这货的博客多年保持livelock状态。什么意思呢，就是看起来系统还是在跑，但没有任何有用功。常年都是给入门马农做科普的内容。这种属于大自然的搬运工，把搜索引擎里的资料编译一下就拿来做自己的内容。然后是比较隐藏的水货。比如陈硕。言必让读者看自己的书第几页。但他那本书纯属基础知识和常识列举。看几个man page和rfc就够了。另外，他的书里错误很多，言之凿凿的地方其实都是挂一漏万，把特例当公理。云风当属最隐蔽的水货。都是实打实的产品，代码，难题，分析。内容都是网络，高性能，并发，分布。但不幸的是，老子才是这方面的行家。就拿他最新那个所谓的乐观悲观锁来说吧，里面每个结论每个分析我都指出其不靠谱之处。还有其他一些水货，就不一一列举了。他们有如下显着特征:话题以程序科普为主。内容都是在其他它地方能轻易获得的，缺少自己的思想。问题分析流于猜测，不能达到问题本质。轻易下结论，下过多总结陈词。缺乏量化分析，以主观感受和特例作为依据。如果有不服的，欢迎讨论。我可以具体问题具体分析给你看，他们的思想有多毛糙，基本功有多不扎实。

⑹ 如何辨别一个程序员水平的高低

1.自己介绍项目，看对项目的提炼总结能力（也是抽象能力）；
2.自己印象最深的bug，可以知道大概技术深度；
3.设计模式提问，看有没有学习方法；
4.语法基础问题，多线，分布，安全等问题，看知识面广度；
5.智力问题，看反应能力，分析问题思路等
上述五步基本可知是否是一个好程序猿

计科专业从事软件开发十几年了，主要在浏览器内核领域研究的比较多，最近在研究服务器后台方向，辨别程序员水平高低主要看做出了什么产品，如同现在的程序员主要是项目经验，简历上写的一堆项目经验都是面试的时候主要提及的问题。经常在面试中会问两个关键点：一个是做过什么项目；一个是在项目组中承担什么职务，毕竟参与过和做的多少程度是不一样的，这些都是可以通过一些具体的细节检测出来，问题越具体越是容易看出水准，具体的东西不是能够编造出来的。

有很多技术公司直接不通过笔试，仅仅通过简单的面试就确定工资水准了，最简单的测试程序员水平的直接用笔试的方式，笔试可以把一些细节量化，尽量的细节化也是能测试出程序员基本功的，但这种基本用来测试初级程序员的，很多高级的程序员看到有笔试直接就抬腿走人了，因为有些程序员在一个方向做的时间太长了，很多基本功都忘得差不多了，所以笔试可能不过关，现实中很多程序员笔试不过关，面试还可以，也一样可以做项目说的就是这类人，起码这算是非常优秀的程序员。

有很多公司采用谷歌的方式，直接采用上机写代码的方式检验程序员水平，这种方式比较直接，但在现实中可能消耗的时间以及面试官的精力，目前只有极少数的公司用这种方式，国外的公司用这种方式比较多，这种看基本功非常有效。通过代码可以看到编码习惯以及算法的设计上，都能直接看的出来。

普通的程序员直接看项目的经验，高级的直接看做过的产品，特别是产品主要设计人员，这就是程序员内心的自豪感，毕竟作为一个程序员起码要有自己设计开发的产品，也算是不白做一个程序员，在程序员的职业经历中如果能经历过一个产品从开始设计的初稿到最后推向市场，如果是完整的经历，将是一种巨大的财富，只要经历过一次都会对产品设计有一个比较层次的认识，这种能力需要靠直接的面试语言表达来展示出来，谈下对产品的认识以及产品稳定性性能等方面的总结，能到这个层面起码是高级软件工程师的级别。

当然有些程序员内在的东西不是靠语言或者写代码看出来的，因为一个优秀的程序员不仅仅是代码能力以及框架能力，还有几个非常重要的能力

程序员的能力表面是可以直接展示出来，但很多内在需要是需要时间的磨合才能了解，人就才能见人心，而且很多优秀的程序员是培养出来的，能够长时间在一起的队友都是时间长了磨练出来的。

希望能够帮到你。

自认为不是一个好的面试官，因为我认为在这么短的时间内，准确地衡量出来程序员水平的高低是有比较大的难度的，并且我有多次看走眼的时候，面试的时候觉得能力还不错，但是入职工作了一段时间之后，编程能力不忍直视。

工作之后接触一段时间，我会从这么几个方面观察他们，以判断技术能力的高低和发展潜力。

能不能把开发任务按时按质量地完成，当然是最主要的衡量标准了:

在开发过程中，难免会遇到没有见过的问题，有些程序员遇到问题无从下手，而优秀的程序员，自有一套解决问题的方法。

有人会认为，程序员的主要工作就是敲代码，上班大部分时候都是在敲代码，其实并不是这样：

好的程序员，相同的问题不会犯第二次，差的程序员，总会在一个问题上栽跟头：

不请自来，一介码农路过，留下些看法。

程序员主要是有四种综合能力，也就是debug 能力、 performance分析、 保护性编程和 投入产出比。

在这里不能说一棒子打死，至少对于很多人来说，能独立完成是没什么问题的，有的是因为对业务熟悉，有的是真的基础扎实。但怎么说呢，程序员和浏览器打交道是最多的，现在这个互联网时代，遇到的大部分问题网络都是可以解决的，也就是普通程序员 + 网络 = 超级程序员。 但很多人也没明白具体的原理，甚至都是这个项目抄抄那个项目抄抄的，久而久之虽然解决了平时的业务，但进步的空间却很少，甚至止步不前，写出来的代码也可能存在很多坑，所以，仅仅能独立完成任务的话，离高手还有比较远的一段距离。

也就是结合我们一开始列举的那四个能力进行判断。不同级别的程序员，在那综合能力面前，强弱也是不同的。例如在奔溃的或者其他性能调优问题上，即使是面对大量复杂的代码，在信息不全的时候也会一步步的分析，抽丝剥茧缩小范围，最终定位根本原因

，并且最终给出一个好的方案。

当然还有看他摘了帽子是否秃顶这样的笑话，就再不赘述了。

第一阶段（黄金）:会用编程语言实现需求，比如现在的业务系统，都会找一些会搬代码的人来拼工作量，也就是能自己独立基于搭好的框架实现crud常规操作。

第二阶段（铂金）:除了crud，还会有一些自己踩过坑的经验，知道如何处理一些常见问题，或者可以基于搜索引擎快速解决一些异常情况。

第三阶段（钻石）:能解决一些疑难杂症和会通过debug部分源码类库查看到这些疑难杂症是如何引发的，并通过编码解决这些问题，还能进行一些局部的性能优化，类似某个系统接口缓慢可以单独去优化。

第四阶段（星耀）:会基于整个系统进行设计和规划，根据业务特性选择合适的框架，从源头控制开发遇到问题的频率，可以自主的搭建框架并完善机制，了解各个组件工作原理。

第五阶段（王者）:小说里面总是说练武功的永远比不过创造武功的，同样的道理，用框架的也往往不如写框架的，所以写框架的这类人单独分层。

第六阶段（荣耀）:其实这个阶段不应该列入进来，因为这类人往往不编码的，只是给出思想；像Hadoop这种框架就是基于人家发表的一些论文（bigdata)进行编码实现的，这类人注重的是思想和算法，区块链，大数据，云计算等等概念的创造和理论的支撑是这类人提出来的，这些人才是真正影响行业走向的人。

程序员的水平高低，不是靠语言或外在表现就能看出来的，不是看他会多少技术、参加过多少项目、写了多少博客，而是看他在实际业务场景中解决问题的能力，尤其是面对一些特别复杂的问题，或在高强度、高压工作状态下解决问题的能力与态度。

技术可以通过学习掌握，但是解决问题、定位问题的能力却不是一蹴而就。大家可能会说，“解决问题的能力”这个太宽泛了吧，可以更具象化吗，有具体的测量方法吗？简单整理了以下几点供参考。

会写出满足需求的代码，早就不是评判程序员水平的标准了。代码编写既要满足业务需求，同时还要考虑后续的软件维护，说得通俗些，既要自己爽，也要别人爽。一个优秀的程序员，会致力于写出更简单、更效率、可读性强、扩展性强的程序代码。

程序员在日常工作中，需要理解各式各样的业务需求，所以这就需要程序员具备一定的逻辑思维能力。可以说，逻辑思维是程序员的灵魂，因为每一行代码都是程序员逻辑的体现。

项目着急上线，发布时出现问题？

业务高峰时段，系统宕机了？

业务催、运营催、用户催、老板催！

各种形态的bug，各种着急的心情，背后无数支眼睛盯得内心慌慌......

这些都是一位合格程序员所需要面对的日常。不同的程序员，在解决问题的方法、效率、质量等方面，都各有千秋。一个经验丰富的程序员，能够扛住各方压力，在复杂条件下找到核心问题，通过抽丝剥茧的分析来找到产生问题的原因，并快速进行应对处理，事后及时复盘总结，减少同类问题出现的概率。

随之互联网的发展，越来越多的人涌入程序员这个赛道，竞争日益激烈，加之新技术层出不穷，更新迭代快，程序员所使用的语言、框架、模式都会发生天翻地覆的变化。如果不主动学习，你很快就会被落伍淘汰。

这种其实在面试过程中能体现出来，沟通主要是技术沟通，以及和客户之间的沟通，所有技术都不是闭门造车就能搞定的，沟通能让事情推进起来更加顺畅，包括和产品经理之间的流畅的沟通也显得非常重要。程序员的能力表面是可以直接展示出来，但很多内在需要是需要时间的磨合才能了解，人就才能见人心，而且很多优秀的程序员是培养出来的，能够长时间在一起的队友都是时间长了磨练出来的。

线上出bug了，第一时间响应、处理；

团队项目进度紧张、人手紧缺，主动补位；

又或者，在项目推进过程中如果只是关心自己模块内容，对于整个项目置之不理，只守着自己的一亩三分地。

随着时间轴的拉长，你会发现，有此f技术能力不是最好的，甚至不如你的小伙伴，最后做到了技术主管或经理、甚至更高职位，这里面除了技术实力，还有一个叫“责任心”的东西。

结束语

判断一个程序员的水平高低，核心是其解决问题的能力，而解决问题的能力养成，需要扎实的底层基础来支撑，要综合其代码质量、项目经验、框架能力、逻辑思维等等多方面，不能单看某一方面。

而对于1-6岁的程序员来说，想要成为一个高级程序员，变得越来越优秀，唯有持之以恒去学习、积累、实践、修炼。

----end----

一：50岁的时候，头发还是黑色的浓密的。

二：赚到的钱能保证家人快乐的生活。

三：当公司不要你的时候能成功转型。

其他的例如编程经验、写代码厉害啊什么的根本不值一提。

这就是程序员的面试嘛 :-)

（1）是否能熟练使用所用编程语言的主要功能；

（2）是否知道用合适的数据结构解决问题；

（3）是否知道基本的算法，并且用这些算法解决问题；

（4）只看少量代码的话，从变量命名和程序结构一般能够判断是否是新手；

（5）给出具体问题，能够用程序解决，能考虑到所有的边界条件；

（6）考虑程序的可扩展性，可维护性；

再往高一点走，就需要

（7）面对模糊的问题能够分析并且找到细节和具体的需求；

（8）知道利用已有的库，架构和工具等来解决新的问题，而不是什么都自己实现；

（9）能发现并改进已有程序中的瓶颈；

（10）对整个大项目的程序架构有很清晰的了解，知道相互之间的依赖，以及知道为什么采用这样就架构；

（11）给一个大的项目，能够对整个项目的程序架构和组件进行合理的设计，考虑并行性，低延迟，大数据量等各种需求和应对方式。

带领团队已多年，项目数十个，对判别程序员水平的高低，我有自己的看法，欢迎大家一起交流。

1.代码质量。

优质的代码，首先是经得起考验。静态分析工具过一遍，无错误，无警告。当然警告部分需要人工重审，因为静态分析工具不一定完全正确。过了这一关，重要的还须过测试关，少Bug或无Bug的代码，才是好代码。优质的代码带有技术气质和艺术气质。阅读起来，有一种赏心悦目的快感，即工整美观，干净利落，又蕴含着理论常识，运用技巧，精准到位。

2.表达能力。

3.文档能力。

文档形式包括但不限于PPT，文字，图表，音视频。文档内容包括但不限于API说明，工具手册，项目事项，技术论述，陷阱总结，方案展示，指导手册。文档要求必须是满足公司或部门的规范和格式，否则五花八门的，不利于交流和传承。

以上3点，是我量化判断程序员水平的标准，仅供参考。相比水平，其实我更看重程序员的态度，执行力，时间观念，自学力等等，也是很重要的团队作战能力，也可以说是程序员水平的考量吧。

谢谢大家。

⑺ 因安排不当产品无法在预期上线，领导把锅甩给程序员怎么怼回去

委婉一点说这不是自己的一个人问题，不要将错误归结到自己一个人身上，不要总是让无辜的人受冤枉，有问题大家可以一起解决，公司出现了问题不是一个人的错，大家都难辞其咎，即使是领导也是有错误的，领导没有起来好带头作用，才会导致这样的局面发生，我觉得这是非常好的一种怼回去的方式。

领导出了错，就应该让他们承担错误呗，即便是老员工，就更应该具备职员的基本素质，而不是逃避责任，你不应为他们背黑锅。每个人都要为自己的行为负责，犯了错误，我们可以互相帮助，但是拒绝背黑锅，这样的感觉真的很不爽。要是领导一直不改的话，就直接怼回去，不要害怕撕破脸皮，有些人就是越给脸越不要脸。

⑻ HR如何快速判断应聘的程序员是否靠谱

招人这个事情放到如何重要的地位，其实都不为过。前赶集网CEO杨浩涌在一次开放式演讲中说过，CEO要花一半精力去找人。其实在Google、Facebook、Alibaba等一些公司在招聘一个员工的时候，他们是很耗费时间和精力的。一个好的人是值得花非常多的时间。你看重的人，在他身上花精力是非常值得的，他会被打动，他会感知到你确实非常在乎他，士为知己者死，好的人才觉得跟你是有共鸣的，他愿意加入你这个团队。

其实在一些中小公司，可能HR会初步筛选一些简历，然后给面试官进行面试。但其实很多时候，面试官面试的这位应聘者根本不靠谱（注意，我们现在说的是程序员招聘这个方向）。这样一来其实不仅浪费面试官的时间（其实，你知道，一般能够作为面试官的，在公司里面其实是很忙碌的），也是在浪费面试者的时间。所以，我个人觉得，HR在招聘的时候，首先可以通过一些基本的问题来快速判断应聘的程序员是否靠谱，通过HR的初步筛选后，面试官再和应聘者电话或者当面聊一些技术层面、逻辑思维层面以及团队合作层面的问题，这样就大大的增加了招聘的效率。

我个人觉得有两点：

因为程序这个行业变化更新很快，不要说刚入行的程序员，就是工作了十年的老司机，也需要不断的学习，而看书是学习的最直接体现。

HR可以在和应聘者电话沟通的过程中，可以询问他的业余时间都是怎么过的，如果应聘者没有提到读书、看书之类，我觉得多半不靠谱。当然看书并不局限于一些技术方面的书，也可以是一些非技术的书，我觉得爱看书的人，两方面的书都会看的。

我觉得第二点非常重要，首先我想要的是，应聘者简介、清晰、有条理的描述出他最近做完的一个项目或者产品的大的需求是什么，他自身在整个团队里面充当的是什么样的角色，能否描述清楚他自己做的某些功能。

如果HR能够很清晰的理解应聘者所描述的这些问题，我觉得他是靠谱的。

首先，如果作为一个非技术性的HR，能够听懂应聘者的解释，我觉得应聘者沟通、理解能力是完全没有问题。

其次，他能描述出来这个项目或者产品的大的需求是什么，说明他不是在蛮干，也说明他并非只是关注于手头上的事情，他还在关注整个团队在做什么样的事情，这也体现了团队精神。

然后，他能描述出来自己做的某个功能，说明他是真正的去实践过和思考过，思考和实践是作为一个靠谱程序员必备的素质。

总体上，快速判断一个程序员是否靠谱也就是这两点，如果这两点都OK ，没有问题后，我觉得HR再和应聘者约时间，再和面试官聊。

提出一点建议

就是HR先进行一轮电话面，沟通一些基本问题，从中觉察应聘者在表达、沟通、描述以及学习方面的能力。如果还行，可以和应聘者约定一个时间进行技术面，而面试官可以把时间选择在晚上，也就是7-9点钟，这个时候，上了一天的班，可以更好的投入到面试的上面。通过电话面，了解一下技术，以及以前的工作经历，没有问题的话，再约时间当面聊。

这是我能想到的，不喜可以喷......