如何通过 HackerRank 面试？

招聘方看到的分数不只是通过或不通过。一份 HackerRank 测评会同时报告好几项内容，了解哪些指标是独立变化的，会改变你分配计时时间的方式。

• 通过的测试用例数。每道题都会针对可见的示例用例和更大的隐藏用例集运行。空输入、单个元素、重复项和最大规模数据都藏在隐藏用例集里。大多数丢分来自边界情况，而不是算法本身写错了。
• 部分得分。打分通常按每个测试用例计算，所以一个正确但较慢的解法也能拿到实实在在的分数。而一个没有提交的完美解法则一分都拿不到。
• 时间与内存限制。如果题目设定了限制，效率不高的解法会在大规模隐藏用例上超时，即使它通过了每一个示例用例。
• 监考报告。切换标签页、失去焦点、粘贴事件，以及在开启相关功能时的摄像头截图，都会附加在你的提交记录中供招聘方查看。

其他招聘平台在各个环节分别测试什么，可以参见招聘平台专题页。

你明明已经掌握了算法，上次却依然丢了分，这感觉就像练习都白费了。这一节要讲的是环境层面而非能力层面的问题。大部分可以挽回的分数就藏在这里，而且挽回它们的成本很低。

• 在 HackerRank 编辑器里练习。它不是你的 IDE。没有你习惯依赖的自动补全，没有调试器，你的快捷键设置也都不存在了。在真正上场之前，先在里面完整做几道题。
• 了解输入模板。有些题目会给你一个已解析好的函数签名，有些则需要你自己从标准输入读取。读错输入模板是一种常见的失误方式——即便逻辑完全正确，也会导致每一个测试用例都失败。
• 选择你调试速度最快的语言，而不是看起来最厉害的那种。能通过测试才是衡量标准。
• 先写暴力解法并提交，再做优化。在计时器耗尽之前先把部分分数锁定，是性价比最高的一个习惯。
• 手动测试边界情况：空输入、单个元素、全部相同、最大规模。

设想一位后端工程师正在准备一场平台团队的电话面试。他此前解决过类似的底层问题，却在测试的前一段时间一直在和输入解析模板较劲，最终只提交了一份解法而不是三份。他的算法知识从来都不是那个瓶颈。

CodePair 是一个共享编辑器，通话中会有真人在场，这让它更像是一场围绕代码展开的对话，而不是一次测试。打分依据的是面试官的主观判断，沉默在这里会显得很不利。

• 复述题目并在动手写代码之前确认清楚约束条件。
• 先把思路说出来，包括你曾经考虑过但否决掉的方案，以及否决的原因。面试官会为推理过程打分，一个被否决的方案本身就是推理能力的证据。
• 边说边写。长时间的沉默是面试官对这一环节最常提到的抱怨。
• 把你的测试用例讲出来。主动走一遍边界情况，传递出的用心程度与异步环节中隐藏测试所衡量的是同一回事。
• 优化之前先问一句。很多时候面试官想要的是能跑通的版本外加一段复杂度讨论，而不是最优解。

模拟面试模式正是用来练习这种大声表达思路的能力的，因为这里的失败往往出在表达上，而不是算法本身。

在这个问题上说清楚，比给出一个营销式的答案更重要。

• 受监考的 HackerRank 测评不在适用范围内。监考系统会记录切换标签页、失去焦点、粘贴事件和摄像头画面。屏幕共享、屏幕录制、受监考的环境，以及公司管理的电脑，都是任何助手都不适用的场景，SubcueAI 也从不这样宣称。
• 适用的场景是准备阶段。提前进行大声练习的模拟环节，能培养出 CodePair 环节所考察的表达习惯。
• 围绕编程环节展开的行为面试和系统设计对话，都是在普通会议软件上进行的普通面试，而这正是 SubcueAI 所面向的场景。

该平台能看到什么、不能看到什么，在可检测性专题页上有更详细的说明。