非技术背景招聘者如何招到靠谱的开发者

意识到自己力不从心的那一刻

你发布了职位，简历纷至沓来，每一份都列满了你从未听过的框架名称。有人自称拥有五年“具备可扩展微服务架构的全栈开发”经验，你完全无法判断这究竟是真本事，还是他们在面试前一小时刚从某个教程网站上现学现卖的。你在电话面试中不停点头附和，却无从反驳或追问。

这很正常。大多数经营着10到200人公司的人并非开发者出身，但他们中的大多数仍然需要招聘开发者。好消息是：你不需要学会写代码也能招到合适的人。你需要做的，是不再试图评判代码本身，转而学会评判代码背后的证据。

不要假装懂技术——这只会适得其反

候选人能察觉到你在虚张声势。如果你问“聊聊你使用Kubernetes的经验”，然后无论对方回答什么都只说“很好，很好”，这只会让一个精明的候选人明白：这场面试根本没有真正的门槛。那些能说会道却交付不出成果的人会轻松过关，而那些默默无闻、真正有实力、以为你在认真考核的人，反而会低估自己表现的重要性，不敢充分展示。

不如坦诚一点。你可以直说：“我不是技术背景出身，所以我会请你用通俗的语言解释你的工作，同时在流程的某个环节我会请教一位懂技术的人。”这不是示弱——任何称职的招聘经理，在招聘自己不熟悉的领域时都会这么做。

借用别人的技术眼光——只需一小时，不必贯穿全程

要招到合适的开发者，你不需要一位全职的技术联合创始人。你只需要一位开发者两次、各一小时的时间：一次帮你撰写职位描述和筛选问题，另一次参与最终轮面试或审阅作品样本。

可以找这样的人：

• 你付费咨询两小时的自由职业开发者
• 有软件开发经验的朋友或顾问
• 你因其他事务已经在合作的承包商

请他们做的事情要具体明确：“看看这位候选人对这个具体问题的回答，告诉我是否站得住脚。”而不是笼统地说“帮我把把关”——这样的要求既模糊，又对别人的帮忙提出了过高的期望。

让候选人解释自己做过的事，而不是假设性问题

一个真正做出过东西的开发者，可以用通俗易懂的语言讲清楚自己的工作，无论你追问到多细的层面。而简历注水的人，通常一深入就露馅。

以下问题按揭示信息量从少到多排列：

1. “聊聊你做过的一个你引以为傲的项目。它是做什么的？你在其中承担了什么角色？”
2. “那个项目里最难的技术问题是什么？你是怎么解决的？”
3. “如果我问那个团队里的其他工程师，和你共事是什么感觉，他们会怎么说？为什么？”
4. “说说有一次你的代码在生产环境中导致了故障。当时发生了什么？你是怎么处理的？”

第四个问题最能说明问题。几乎每一位真正的开发者都经历过生产事故。如果一个人声称有多年经验，却说“这种事从没在我身上发生过”，那他要么在撒谎，要么从未真正上线过什么重要的东西。

用一个小而真实的作品样本来考察

你不需要让候选人免费做出一整个功能。一个耗时60到90分钟、范围明确、且贴近该岗位实际工作内容的小任务，比一小时的对话能告诉你更多。

要保证公平：

• 支付报酬，或者确保任务确实小到无偿完成也合情合理（大多数候选人心里其实分得清哪种情况是哪种）
• 在同一阶段给所有候选人布置相同的任务
• 之后请他们讲解自己的解决方案——这正是你能察觉到对方是否得到了未曾提及的帮助的关键环节

如果你自己没有足够的技术判断力来评审结果，这正是花掉那一小时借来的技术支持的最佳时机。

如果你不想从零开始设计任务，一套经过校准的技术筛选测试可以在这一步之前先做一轮初筛——AssessFit 提供覆盖多种技术技能的自适应测试，让你不必把每位申请者都直接送到你唯一的技术评审人手中。

看他们交付了什么，而不是他们声称懂什么

一份写满技术名词的简历，只能告诉你这个人接触过什么，无法告诉你他擅长什么。不如要求实证：

• GitHub主页、作品集，或他们参与开发的上线项目链接
• 具体的公司和产品名称，方便你自己去查看
• 项目中究竟有多大比例是他本人完成的，而不是团队的功劳

不要被一长串工具名称唬住。真正值得关注的，是他们能在一两件事上讲得足够深入。深度才是真正的信号，堆砌流行词汇往往恰恰说明相反的问题。

背景调查：问交付情况，不问技术水平

除非你的推荐人本身也懂技术，否则你不能问“他代码写得好吗？”并指望得到有用的答案——即便对方懂技术，这也是个笼统、容易被善意糊弄过去、很少有人会认真反驳的问题。

不如这样问：

• “他们是否按照自己承诺的时间完成了工作？”
• “出问题的时候，他们是提前告诉你，还是等你事后才发现？”
• “你会不会放心把一件模糊不清的任务交给他们，相信他们能搞定，还是必须事事都交代清楚？”

这些问题同样不要求推荐人懂技术，只要求推荐人曾与这位候选人共事过——这个门槛低得多，也更容易得到诚实的回答。

诚实地说，这个方法也有极限

这些方法都无法替代——最终——拥有一位你信任的技术人员。如果这是你招聘的第一位工程师，而你的人脉圈里确实没有人能帮你把关，这一点值得坦率地承认，作为一项风险——无论是对自己，还是对可能认识合适人选的早期投资人或顾问。设置一个90天的试用期，配合清晰、非技术性的交付里程碑（东西是否上线、是否能用、用户是否投诉），可以作为万一这次招聘不如面试时表现的那样理想的兜底方案。

你不是要变成一名开发者。你要建立的是一套流程，能够区分出谁真正做出过东西，谁只是背熟了那些说辞。