北京Haskell工程师驻场怎么找

先把技术和驻场条件写实

JD 里分别列 Haskell 版本、GHCi、Cabal 或 Stack、数据库、Linux、CI/CD、测试方法，以及是否需要维护既有纯函数模块。不要只写“精通 Haskell”；要说明每天是否到北京现场、是否接受短期驻场、是否有夜间发布或应急响应。驻场岗位还应写清合同主体、服务方、实际办公地点、考勤和费用承担。

面试可以用一段脱敏代码或故障场景看候选人如何定位类型错误、设计测试和解释技术取舍。技术通过后，再核验到岗时间、通勤、项目保密、设备和权限要求。不要让供应商把“相关函数式经验”直接等同于 Haskell 实战。

用人方和供应商各自负责什么

甲方负责项目目标、代码仓库授权、评审标准和现场安全规则；供应商负责候选人真实性、合同关系、替换承诺和服务管理。直属负责人只对工作结果和日常协同负责，不宜在系统里把外部驻场人员误建成甲方正式员工。

在 项目台账系统 中可把项目、驻场周期、服务方、现场负责人和权限范围设为必填或审批字段；技术面结论、背调授权、入场确认、设备交接分开留痕。具体人员建档方式以企业用工模式和产品配置为准。

北京本地候选人的验证清单

至少核对身份证明、简历关键项目、Haskell 实际职责、可到岗日期、现有竞业或保密限制，以及是否有同时服务冲突。要求候选人确认自己能承担的工作范围，不能用一张技术证书替代项目事实。涉及金融、医疗或关键信息基础设施时，背景核验和访问审批要按甲方制度执行。

推荐、面试、定标、入场和替换都要有状态和责任人。这样即使候选人临时放弃，也能知道是技术不匹配、价格、到岗还是权限问题，不会只剩一串聊天记录。

处理建议

北京驻场的 Haskell 人才数量本来就可能小于 Java、Go 等通用岗位，先用真实技术栈缩小范围，再谈候选人数量和到岗速度。 建议把关键事实、责任人、截止日期和证据要求拆成字段，先用小范围样本跑通，再逐步扩展。对无法由系统判断的法律、税务、知识产权、信息安全和劳动关系问题，保留人工复核节点。

进场与离场验收

先用一份脱敏的项目需求单试跑：技能、级别、到场日期、地点、周期、工作时间、汇报对象、设备、代码或数据权限、交付物和替换条件都要写清。验收不能只看人是否到了现场，还要看人员身份与合同关系是否核对、入场培训和保密确认是否完成、权限是否按范围开通、任务是否有人负责、交接材料是否可复用。

建议由甲方项目负责人、供应商项目经理和信息安全或 HR 分别确认。涉及代码、生产数据、客户信息、门禁和自有设备时，离场要回收账号、令牌、门禁、共享链接和本地缓存，确认未完成事项、版本、文档和责任人。计费按合同口径核对人天、工时、里程碑或变更单，不以系统里的单条记录自动替代验收。