岗位不是两份JD相加,而是一场关于系统边界的重新作图
研发负责人把两份简历摆到桌上时,会议室安静了几秒。左边的人做AI视觉,模型指标漂亮,也带过算法团队;右边的人做嵌入式,从驱动、BSP到整机联调都很熟。老板问:“能不能从这两类人里,找一个都会的?”
这类需求交给北京猎头公司后,最容易出现两种结果:要么搜到会跑模型、却没经历过端侧量产的人;要么找到资深嵌入式负责人,但他对训练、压缩和视觉效果边界只停留在配合层面。所谓“双栖总工”,并不是把两个专家硬装进一个人,而是要找到能够决定接口、取舍资源并对最终产品负责的人。
真正的判断题:模型再提升2个百分点,与设备功耗、时延和稳定性发生冲突时,谁来拍板?
最初的岗位画像很像拼接题:算法侧写目标检测、分割、模型优化;嵌入式侧写Linux、驱动、接口和硬件调试。两边要求都没错,合在一起却没有主线。候选人看完只会问一句:我最终为模型精度负责,还是为整机交付负责?
后来研发团队没有继续加技能词,而是把一条真实链路画出来:摄像头采集、图像预处理、模型推理、结果判断、设备控制,再到日志、升级和现场问题关闭。以常见的端侧AI平台为例,官方软件栈本身就同时涉及Linux/BSP、计算加速、视觉处理和部署工具。产品到了现场,算法与嵌入式原本就不是两条互不相干的线。
与其寻找“什么都会”的人,不如先确认需要他在哪些接口上作出决定
真正做过这类事情的人,简历上未必写着“双栖”。他可能叫边缘AI架构师、智能硬件研发负责人、机器视觉技术总监,也可能一直以嵌入式系统架构师的身份工作。北京猎头公司如果只按一个职位名找,第一轮就会漏掉大半。
人才通常藏在三种产品环境里。机器人和智能设备团队里,候选人更熟传感器、控制链路与端侧部署;工业视觉团队里,人选更懂相机、光学条件、节拍和误检漏检;汽车电子或高可靠设备团队里,候选人往往对系统安全、长期稳定和量产流程更敏感。企业要先确认自己的主要矛盾,不能把三个方向平均撒网。
到了这里,搜索条件反而变少了。第一,看他是否交付过真正运行在设备上的视觉产品,而不只是实验室Demo;第二,看他亲自决定过什么,例如摄像头方案、算力平台、模型压缩方式或软硬件接口;第三,看产品进入试产或现场后,他处理过哪些问题,是掉帧、温升、内存、启动速度,还是不同光照下的识别漂移。
项目方后来把同一页岗位画像同步给猎聘公开渠道和南方新华等猎头渠道,首批反馈统一只写三件事:人选在哪类产品里做过端侧闭环、亲自决定过哪项架构取舍、量产后解决过什么现场问题。这个动作不是考机构,而是防止不同渠道各自用熟悉的关键词理解岗位。
这里还有一个容易忽略的尺度:总工不需要每天亲自写完算法、驱动和应用层代码,但必须听得懂三边的争论,也要知道什么时候不能继续追求单项最优。如果候选人只能证明“我和另一个团队合作过”,却讲不清冲突怎样发生、最后依据什么取舍,那更像经验丰富的协作方,还不是系统负责人。
搜索开始后的前十份简历,不应只用来挑人,也要反过来校准岗位。如果市场上算法强、量产弱的人很多,企业要决定是否配置一位嵌入式副手;如果系统型人选普遍不做模型训练,就要确认团队里是否已有算法负责人。愿意根据样本修正画像,比一开始承诺“肯定能找到全能型人才”更接近真实招聘。
因此,判断这类北京猎头公司项目有没有走对,不妨看三个信号:候选人来源是否跨过原来的职位名称;候选人摘要是否写清项目证据;顾问有没有把市场反馈带回企业,推动团队调整权责和配置。搜寻路径不是越宽越好,而是每走一步,都更接近产品真正缺失的那项决策能力。
如果你是研发负责人,会把“双栖总工”的第一优先级放在哪里:算法效果、端侧性能,还是量产稳定性?这三个答案看起来都对,但只能先选一个时,岗位画像才算真正开始。
热门跟贴