01 痛苦的编程题评卷
试想如下一个场景：
“技术面试官Arron 的企业要招聘Java 后端工程师，考核 SpringBoot 框架和 MyBatis 这两个后端开发的必备技能。而他要负责评审多份候选人的编程题试卷，题目是要求使用SpringBoot 和MyBatis实现一个购物车结算功能。
Arron 经常跟另个一个面试官对代码打分产生分歧。
比如一位候选人使用SpringBoot编写了购物车控制器，实现了加入购物车和结算请求的API。他使用MyBatis调用存储过程，完成了库存扣减等逻辑。代码整洁，测试用例完整，另一位面试官称赞了他的SpringBoot应用结构。
但是Arron评审时发现，他直接在控制器中写了业务逻辑，没有遵循MVC分层的架构设计原则，导致可维护性较差，这点另一个面试官却不太在意。
Arron已花费大量时间对代码进行逐行评审，他除了测试用例完整与否，还会在可维护性与解题思路等多方面进行考察。
时间离截止只有两小时，他与另一个面试官依旧争执不下，难以达成共识，编程题评审的复杂性让Arron倍感压力…”
以上技术招聘的场景，反映出了Arron 面临的什么问题呢？
02 编程题的作用以及评卷困境
要回答这个问题，先要了解企业使用编程题进行技术测评的原因。正如Linux的创始人Linus Torvalds 所说：“Talk is cheap，show me the code”。相对于选择题、问答题，编程题最能直观展示候选人在实际工作环境下的编程能力。
但企业对编程题进行评卷时，往往面临如下三大麻烦：
一、评审耗时费力
正如Arron所遇到的，当侯选人的测试用例完整通过，但企业仍想深入考察其他方面的代码能力；又或者测试用例没通过，企业还是想深入了解他的代码出了什么问题，这些都需要Arron逐行反复审阅代码，耗费他巨大的时间与精力。
评审一位候选人所花时间可能平均需要几十分钟不等，更何况还不止一位候选人，可见评卷工作对Arron 来说确实是件苦差事。
二、评审维度单一
有的企业会出于提升效率的考虑，仅以简单的OJ 系统评价候选人代码是否通过测试用例，并不会进一步考核代码的其他方面，该评审方式可能更适用于海量候选人情况下的初步粗略筛选。
但若想进行更加精准的招聘，则需要考核候选人是否有真正的解决问题的能力，那么在技术测评中候选人的代码除了“能跑通”外，其他维度也极为重要，这也是Arron 如此费心考核候选人代码的原因。
根据知名技术问答网站 Stack Overflow 针对8万名开发者的调研显示，他们觉得除了代码的“正确性”与“功能性”外，代码的“可读性”、“可维护性”、“可拓展性”、“安全性”、“代码规范”、“开发效率”等维度的重要性也名列前茅。
三、评审受主观偏差影响
但即便企业建立了更多的评分维度，也会由于面试官对不同维度的重视程度不同，而产生像Arron跟别的面试官之间，难以达成一致的问题。
国外一份发表于ESEM研究调查了127名来自17家公司的开发者，考察他们在代码审查时关注的维度。结果显示，开发者关注的维度因其岗位、工作经验和项目而异。例如，高级开发者比初级开发者更注重代码设计和可维护性，嵌入式系统开发者比web应用开发者更重视可测试性。
由以上三点可知，要解决编程题评卷的麻烦，需要建立自动化方式以节省时间，并且建立客观全面的评价体系，而且同时还要尽量避免人为主观偏好所产生的偏差。
那有什么方法可以实现呢？
03 编程题AI评分——全面、自动、高效、客观的评价体系
AI 的出现带来了破局之道。其依据算法所建立的标判断准，以及全自动化流程，很合适搭建编程题评卷机制。ShowMeBug 也深知AI 的巨大意义，并实现了独有的编程题AI评分功能，使用AI建立起了全自动化、高可靠性的评分体系，并在其中体现出了三大功能价值：
第一，该功能可对候选人的编程题答案进行自动化评分，在数秒内即可完成几十分钟甚至数小时的代码评卷工作，并给出相应分数，让评卷投入的时间与精力成本降至为0。
第二，针对候选人代码，ShowMeBug 还依据实际工作场景中的代码测试方法，设计了五大考核维度，分别为：
代码正确性：评估候选人是否能够按要求，编写出测试用例正确通过的代码，反映了候选人的基本编程水平和语言掌握程度。
解题思路：评估候选人是否能够理解问题，提出合理的方案，并将其转化为代码。反映了候选人的需求梳理和问题解决能力，以及创新性思维。
代码设计：评估候选人是否具备良好的代码组织和模块化能力，提高代码的可读性、可拓展性和可维护性。
代码质量：评估候选人能否遵循良好的编程规范和最佳实践，编写清晰、简洁、可理解的代码。
答题效率：评估候选人在解决问题时所花费的时间和资源，反映了候选人的工作效率和应对复杂问题的能力。
第三，该功能还设计了“宽松/严格”两种模式，供企业基于自身不同招聘需求来作调整。具体体现为：
“严格模式”下，一旦候选人测试用例没有通过，则这道题便会判为0分，可适用于企业面临海量候选人时，进行初级的大规模筛选；
“宽松模式”下，不仅只考核测试用例是否通过，系统还会根据解题思路、代码设计与质量等维度进行打分，可适应企业更精细化的针对岗位与实际工作能力的招聘需求，对候选人的技术能力进行多面向，与更深入的考察。
通过这些功能与价值，企业可极大提高评卷效率，提供更为客观、全面、公正的评分依据，减少评卷时主观分歧的影响，助力企业高效精准地甄选人才。
多说无益，不妨再以Arron 为例：
Arron 的企业继续招聘Python 后端开发工程师，并考察该候选人的的字符串处理和正则表达式能力。题目内容为：候选人需要实现一个函数，该函数接收一个字符串作为输入，然后将字符串进行分词，并生成对应的标记列表。
这次Arron 便可登陆ShowMeBug，在“考试大厅”的“考场设置”并中对试卷进行编辑，找到评分规则设置并打开“智能评分”。由于Arron 并非只看重测试用例的完整性，他可以选择宽松模式，除了测试用例以外，他还可对候选人代码的其他维度进行深入考察。
设置好后，Arron 便可邀请候选人进行测评，候选人进入测评界面后编写代码，完成后便可提交试卷。
提交试卷后的数秒钟后内，AI 便能自动完成对代码的评分。之后Arron 便可进入评卷界面，查看AI 所给出的分数。
点击“AI”标志，还能看到AI 会根据设置好的五大维度，对代码进行每个维度的评分，并且依次给出评分理由。可以看到，该候选人的代码全部通过了测试用例，但在“解题思路”、“代码设计与“代码质量”等维度还有进一步优化的空间。
Arron 可以此作为依据，不仅能系统性全面了解该候选人的代码是否能符合实际工作场景的需求，还能深入了解他的解题思路，以及对他的代码设计、质量与解题效率，提供一个客观的参考标准。
当然，Arron 也可根据自己的专业判断和经验，在AI 评分旁作出适当的调整。
评卷完成后，Arron 还能一键生成人才报告，发予其他面试官查看，并就AI 的评分共同进行探讨，进一步减少主观偏差的影响。
通过ShowMeBug 编程题AI智能评分，Arron 便无须再逐行评审代码，而且能以AI自动化方式，帮他节省海量的评卷工作量；也能让他与其他技术面试官拥有了一个全面客观的标准，规避彼此之间主观分歧与偏好所产生的差异，更容易对所评分数达成一致的共识；并最终深入考察候选人实际的工作能力。
