摘要：Kapwing 联合创始人 Eric Lu 近期发文讲述了在面试一位应聘 L3 软件工程师职位的面试者时，当场抓包面试者用 AI 造假的经历。他用“我职业生涯中最离奇的视频通”来形容这次面试。

Kapwing 联合创始人 Eric Lu 近期发文讲述了在面试一位应聘 L3 软件工程师职位的面试者时，当场抓包面试者用 AI 造假的经历。他用“我职业生涯中最离奇的视频通”来形容这次面试。

Kapwing 是一家创意软件公司，用户通过一套基于浏览器的工具能够在任何设备上制作视频，获得了 CRV、Shasta Ventures、Sinai Ventures、真格基金等机构投资。自 2017 年 10 月上线以来，已有超过 3000 万个视频在 Kapwing 上制作完成。

面试开始的进展异常顺利，从背景资历来看，这位候选人堪称完美匹配 Kapwing 需求。然而进行到中途，这位面试者突然卡壳，无法继续详细描述自己的技术经历。经过再三追问，他最终承认是借助人工智能准备的面试，Eric 当即终止了面试。本文详细记述了这段经历，并还原了 Eric 通过种种蛛丝马迹发现对方作弊的全过程。

面试准备

Kapwing 的面试流程是先在内部审核收到的简历，如果应聘者看起来确实拥有相关经验，我们会邀请对方与技术团队的一位成员进行 30 分钟的电话面试。Sam（化名）似乎非常适合我们公开的 L3 软件工程师职位。对方是一位来自知名院校的在读硕士研究生，简历中列出了在三家不同初创公司的亮眼从业经历。为了准备面试，我认真阅读了他的简历，并准备就过往经历具体追问一番。

我们收到的 L3 软件工程师职位应聘者简历，从内容上看这位老兄的确拥有丰富的全栈开发经验。

虽然简历似乎针对关键词做过优化，但他列出的确实是真实存在的公司，而且时间序列也与求学经历匹配得上。此外，这位候选人在 LinkedIn 上还放出了公开个人资料，附有真实照片和同样的实习经历。种种迹象表明这位应聘者相当合适，所以我们决定安排一场电话初面。

电话面试流程

在对软件工程师候选人进行电话面试时，我们的主要目标并不是评估其工程能力，而是更多了解这个人——他们的职业目标和专业经验，借此确定双方需求是否契合。电话面试会从相互介绍开始，之后就是关于对方专业经验的问题。最后，我们还会留出时间回答对方关于 Kapwing 公司的各种疑问。

其实，我们之前也遇到过招聘欺诈，所以公司制定了一项政策——电话面试要求对方必须开启摄像头进行实时通话。如果应聘者未打开摄像头，我们会礼貌地提醒，或者在不方便时重新安排面试时间。这样能确保通话另一端的候选人确实能跟我们看中的个人资料对得上，Sam 当然也不例外。他准时上线，并且打开了摄像头。

Sam 的面试表现

我一般会在电话初面中简要介绍自己和 Kapwing 公司的情况，开场白则大多是：“请简单介绍一下你自己，还有你对下一份工作的具体要求。”

Sam 的回答非常贴切。他曾经在跟我们规模相似的初创公司工作过，这肯定是个加分项，因为不同规模的团队间往往存在工作方式的差异、并带来相应的适应过程。他还使用过同样的 Web 技术，例如我们在 Kapwing 这边会频繁用到 React、Node，以及在 GCP 上构建和管理服务器。最后，Sam 在文化上也特别契合我们的需求——他自己有视频创作经验，能够充分展现我们 Kapwing 孜孜不倦努力解决各种视频编辑难题时的积极性。

我很开心地继续进行面试，问道：“请讲讲你在近期职位上遇到过的棘手技术挑战，并介绍你是如何解决的。”

Sam 的回答同样相当有力。他首先讲述了自己之前在一家小型初创公司的工作经历，当时他们在为某日托机构开发一款应用程序，用于管理家长、托管老师和学生之间的关系。他专门负责应用程序中由学生向家长发送通知的功能，提醒家长放学后及时接自己回家。

Sam 提到在一次客户拜访期间，他们进行了应用程序测试和演示，并注意到由于该应用程序触发了大量短信通知，因此导致服务器负载激增。为了解决这个问题，他们实施了“后端速率限制以及前端懒加载的解决方案”。此外，他们还为应用程序添加了“DynamoDB 分页”和“重试机制”。

表面上看，这些经验跟我们在 Kapwing 的工作密切相关。由于视频编辑需求的增长，我们经常会遇到流量高峰，因此需要在高负载期间限制请求速率，并在用户视频库中执行懒加载或者视频分页。这些对于我们网站的性能和稳定性至关重要。到这里我心情大好，开始向 Sam 进一步了解他们的实施情况。

哪里好像不对劲

虽然他描述的项目似乎特别符合需求，但我想弄清楚他知不知道如何把自己的经验融入到 Kapwing 的整体业务当中。于是，我询问了 Sam 关于服务器负载激增的具体情况及可能的原因。

Sam 解释说，托儿所中一个班大约有 30 名学生，但如果老师一次性向所有家长发送短信通知，那么 Twilio API 可能会限制请求速率。为了解决这个问题，他决定“批量发送消息请求”。

到这我觉得似乎有哪里不对劲了。Twilio API 竟然一次性处理 30 条短信就承受不住了？简直不可思议。这明显是个扩展问题，升级容量就能轻松解决。而且哪怕真的出现这种情况，批量发送消息似乎也不是什么好主意——这只会让一次性发送大量消息的情况变得更加普遍。最后，我对这款应用程序本身也有一些疑问：老师在什么情况下会想一次性给全部学生家长发送 30 条短信通知来协调接送？如果是只负责照顾 5 到 10 名学生的小型日托中心来说，也存在这样的问题吗？

Sam 回答说，我对批量处理的批评应该没错，他好像记错了解决方案。但他清楚记得 Twilio 速率限制就是问题的根源，而且是通过后端解决的。

这时我决定回过头来说说之前他提过的另一件事，以防对方因为时间太长和紧张而忘记。我记得 Sam 在简历里写过、在面试中也提到过，他在开发

来源：InfoQ