订阅更新

候选人说「我负责整个数仓建设」——怎么验证他到底干了什么?

面试官手册手册 第 12 题 约 8 分钟读完

本文目录
  1. 先说结论
  2. 第一层:验项目结构
  3. 第二层:验决策权
  4. 第三层:验代码归属
  5. 贡献度的「定级表」
  6. 一个完整案例:三层验证拆穿包装
  7. 面试高频追问
  8. 实战踩坑:被「主导」字样迷惑
  9. 候选人侧反向使用指南
  10. 总结

先说结论

简历上的强动词必须验证。「主导」「负责整个」「从0到1」这种词,不验证就接受等于自己挖坑。

贡献度三层验证:第一层验项目结构(他清不清楚整体)→ 第二层验决策权(他能不能拍板)→ 第三层验代码归属(关键代码是不是他写的)。

不要质问,要「让他讲清楚」。用具体问题逼出细节,不用对抗的姿态。

先把这段讲顺;面试官追问时,再展开下面的原理和细节。

详细讲解

简历上的「主导」「负责整个」「从0到1」是大数据面试里最值得警惕的几个词。我做面试官这些年,听过无数次「我负责整个数仓建设」「我从0搭建了实时数据平台」「我主导了OOM治理」。但真正能担起这些动词的人,不到三成。剩下七成里,要么是参与者把团队成果包装成个人成果,要么是边缘贡献者讲成核心贡献者。这一篇聊怎么用「贡献度三层验证法」把这些大词拆开看。

第一层:验项目结构

「负责整个数仓建设」的人,必须能清晰画出整个数仓的结构。如果连结构都讲不清,「负责整个」就是空话。

-- 第一层验证的标准追问串
 
-- Q1: 你这个数仓分了几层?每层的职责是什么?
-- 真主导的:能讲清楚ODS-DWD-DWS-ADS或自定义分层逻辑
-- 没主导的:含糊,或只能说出一两层
 
-- Q2: 你的数据域是怎么划分的?
-- 真主导的:能说出业务域划分逻辑(如交易/用户/营销)
-- 没主导的:要么说不出域,要么和分层混淆
 
-- Q3: 一张核心宽表大概有多少字段?
-- 真主导的:能给出量级(80字段还是200字段)
-- 没主导的:要么不知道,要么瞎报数
 
-- Q4: 数仓的指标体系是什么标准?
-- 真主导的:能讲指标命名规范、口径定义流程
-- 没主导的:完全没概念
 
-- 这4个问题答下来,第一层基本能筛掉60%假主导

第一层验证的精髓是「整体感」。真主导过的人,对项目有「全图」;只参与过局部的人,只能讲他熟悉的那一小块。问几个跨模块问题,假主导立刻露馅。

第二层:验决策权

「主导」意味着拍板。我会问候选人在项目里做过的「具体决策」,看他到底有没有决策权。

决策点真主导的回答假主导的回答
技术选型为什么选A不选B我们当时POC过B,YY原因放弃了A公司就是用A的
分层粒度为什么这么定我们考虑了XX权衡,最后定了这个粒度我们老板/架构师定的
指标口径有争议时怎么定我组织了几次评审,最终对齐了XX原则业务方说的算
遇到性能问题怎么决定方案我评估了几个方案,选了XX因为YY找架构师/前辈帮忙

假主导的特征是「决策都是别人做的」。如果候选人讲的所有决策都是「老板定的」「架构师定的」「业务方定的」,那他不是主导,是执行。这种情况要把简历上的「主导」直接降级理解。

第三层:验代码归属

最杀的一层来了。问具体的代码归属:「项目里最核心的XX模块,代码是你写的吗?」「最复杂的那个SQL,是不是你优化的?」

代码归属的好处是:装不出来。讲架构、讲决策都还能背,代码细节是装不出来的。一个写过的人能讲出代码风格、踩过的具体坑、当时调试的过程;没写过的人只能讲个大概。

// 第三层验证的追问示例
 
// 候选人说: 我负责整个埋点治理
// 我会问: 那么1000个事件砍到100个,
//        砍掉的判断逻辑你能给我讲一个具体例子吗?
//        比如哪个事件你决定砍掉,依据是什么?
// → 真做过的能讲一个具体事件的故事
// → 没做过的会用泛泛的标准回答
 
// 候选人说: 我主导查询性能优化70%
// 我会问: 这70%是怎么算的?基线是哪个查询?
//        最关键的优化点是哪一个?是你写的代码吗?
// → 真做过的能给出具体查询、具体配置、具体effects
// → 没做过的会含糊或者把整个团队的成果归到自己
 
// 候选人说: 我负责整个实时数仓
// 我会问: 你的Watermark延迟设了多大?
//        Checkpoint间隔多久?State Backend用什么?
//        这些参数是你定的吗?
// → 关键参数装不出来

贡献度的「定级表」

三层验证完,候选人的真实贡献度可以分成几档:

定级三层验证表现实际称谓应该是
⭐⭐⭐ 主导结构清楚+决策有过程+代码是自己的可信「主导」
⭐⭐ 核心结构清楚+部分决策+核心模块代码降为「核心开发」
⭐ 参与只清楚自己模块+无决策+部分代码降为「参与」
☆ 边缘整体不清楚+完全无决策+不知代码评估为「了解项目」

评估时按定级打分,不要被简历上的强动词牵着走。一个简历写「主导」但验证下来只是「参与」的候选人,技术水平按「参与」级别评估。这是面试官的基本职责。

一个完整案例:三层验证拆穿包装

我面过一个3年候选人,简历写「主导XX公司实时数仓建设,从0到1完成全链路设计与开发」。三层验证:

第一层(结构):「你这数仓分几层?」——「ODS、DWD、DWS、ADS」(标准答案)。「数据域怎么分的?」——「按业务分」(含糊)。「核心宽表多大?」——「不太记得了」(不应该不记得)。第一层有点虚。

第二层(决策):「为什么选Flink不选Spark Streaming?」——「公司技术栈是Flink」。「分层粒度怎么定的?」——「参考了业内最佳实践」。决策全是别人定的。

第三层(代码):「你写过的最复杂的一段Flink代码是处理什么的?」——「就是普通的窗口聚合」。「Watermark你设了多大?」——「默认值吧」。代码归属基本不存在。

三层验证下来,他真实角色应该是「实时数仓的SQL开发」,不是「主导」。最终评估按「参与级别」打分,跟他在简历上呈现的等级差了两档。

面试高频追问

追问一:候选人确实在团队里,但不是主导,怎么界定?

不要否定他的参与,但要纠正等级。我会在面试反馈里写:「候选人参与了XX项目的开发工作,但「主导」可能更准确描述为「核心开发」,主要贡献集中在YY模块」。这样既不冤枉他的实际付出,也不被简历包装影响最终评估。HR看到这个反馈,对薪资定级和岗位匹配会更准确。

追问二:候选人在小公司确实是「一个人扛」,怎么验证?

小公司「一个人扛」的人技术广度通常很好,但单点深度可能不够。我会换问题角度:「你这个项目里哪一块你最有把握?哪一块你觉得自己做得不够好?」。能讲出自己做得不够好的,是真做过;说「全都做得很好」的,是吹。坦诚的小公司全栈比假主导的大公司螺丝钉更值钱。

追问三:候选人讲不出代码归属,但讲得出架构思路,给不给过?

看岗位。如果是架构师/技术管理岗位,能讲架构思路就够;如果是开发岗位,必须讲清楚代码归属,否则就是没真做过。同一个候选人在不同岗位里评估结果可能完全相反,这就是面试官的判断力。

实战踩坑:被「主导」字样迷惑

我做面试官第二年,面过一个候选人简历写「主导XX系统改造,性能提升80%」。我当时被80%这个数字吸引,没仔细做三层验证就给过了。入职后发现他实际上只是「在改造小组里的一个开发」,那80%是整个小组的成果。他写代码能力其实很一般,根本担不起改造系统的责任。

教训:简历上的强动词都要做三层验证,强数字都要追问基线和归属。「主导」「从0到1」「性能提升XX%」这些词的可信度不到50%。从那以后我形成了一个原则:候选人简历上每出现一次「主导」,必须做完整三层验证才能采信。从来没让我失望过——经得起三层验证的人,确实是真主导;经不起的人,简历多漂亮都要降级理解。

候选人侧反向使用指南

如果你是求职者:

① 简历写「主导」之前先做自我三层验证:能不能讲清楚整体、能不能讲出关键决策、能不能讲清楚代码归属。三个都能就保留「主导」,有一个不能就改成「核心开发」「参与」。

② 主动划清个人贡献和团队贡献的边界。「项目整体由团队完成,我个人主要负责XX模块和YY决策」——这种主动划界比模糊地说「我主导」要可信10倍。

③ 准备一个「我个人写过的最复杂代码」故事。能讲清楚这个故事的人,自然就证明了主导地位。讲不清楚的,简历上的强动词都是空话。

总结

简历上的「主导」「从0到1」必须用三层验证拆开看:项目结构(整体感)+ 决策权(拍板权)+ 代码归属(亲手做)。三层都过的是真主导,过两层是核心开发,只过一层是参与。按真实贡献度定级评估,不要被简历强动词牵着走。这是面试官的基本判断力。

下一篇聊一个面试官常陷入的纠结:候选人讲的项目和岗位八竿子打不着——还要继续问下去吗?

你做面试官时,遇到过最离谱的「主导」是什么样的?评论区聊聊~

关注「Wood聊大数据」| 9年大数据老兵,聊技术、聊职场、聊成长

刷题进度保存在当前浏览器