跳到主要内容

3 篇博文 含有标签「interviews」

查看所有标签

那些被 AI Agent 悄然终结的编程面试

· 阅读需 11 分钟
Tian Pan
Software Engineer

两个小时的课后作业和 45 分钟的算法面试从来都不是重点。它们只是代标(proxies)。课后作业代表的是“这个人能否交付功能”,而白板面试代表的是“这个人能否在压力下分解问题”。二十年来,这些代标运作得相当不错,以至于大多数团队都停止了对它们的质疑。它们的管理成本低、易于评分,并且与你真正关心的能力大致正相关。

编程 Agent 破坏了这种相关性,但没有破坏形式。面试照常进行。它仍然会产生一个分数。这个分数看起来仍然像是有意义的信号。但面试所衡量的东西与工作所需的能力之间的差距已经拉大到如此地步,以至于一个合格(green)的结果几乎证明不了任何东西——而大多数招聘流程还没有意识到这一点,因为表面上没有任何失败的迹象。

这是一种悄无声息的失效。不是过程崩盘了,而是一个过程在它的假设前提不再成立后仍在继续运行。

AI 工程师面试系统性失灵:停止考实现,开始考评测设计

· 阅读需 11 分钟
Tian Pan
Software Engineer

我上个季度合作的一个团队连续拒绝了三名进入 AI 工程师流程的候选人。三个人都挂在了编程筛选环节 —— 就是那种让你在 35 分钟限时内实现一个滑动窗口去重器的题目。团队随后录用了通过该环节的候选人。四个月后,正是这位工程师交付了一项功能,其 eval(评估集)在 CI(持续集成)中得分高达 92%,但上线后的第二天,支持队列就爆满了。那个 eval 衡量的是与精选测试集的精确匹配。而生产环境的用户提问方式完全不同。招聘小组里没有人问过候选人他们会如何捕捉到这一差距。

这就是 Bug 的轮廓。面试流程筛选的是工作中价值最低的技能,却对最重要的技能视而不见。团队没有“判断力”面试轮次。他们只有编程轮、系统设计轮和行为面试轮,运行的还是 2021 年的那套循环 —— 那套为编写针对稳定库的确定性代码的工程师量身定制的流程。

AI 面试毫无区分度:为什么你的流程无法识别能交付 LLM 产品的人才

· 阅读需 12 分钟
Tian Pan
Software Engineer

我认识的一个团队花了六个月的时间,在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人,录用了 3 名。但这三个人中,没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题,问题出在面试流程。

标准的工程面试是为这样一套技术栈校准的:正确性可验证,性能可通过基准测试衡量,优秀的工程师是那些能将问题分解为确定性组件,并根据已知规范推导边缘情况的人。那套技术栈依然存在,那些技能依然重要,但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。

这是一个结构性问题,而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”,并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集,这是一个极其微小的群体。这导致了长达六个月的失败招聘,而大家还在纳闷 AI 工程师都去哪儿了。