面试官问'你怎么带新人、做代码Review'——展示团队影响力是晋升的关键

-- Wood的SQL编码规范（10条核心规则）
 
-- 规则1：禁止SELECT *，必须列出具体字段
-- ❌ SELECT * FROM orders
-- ✅ SELECT order_id, user_id, amount FROM orders
 
-- 规则2：每个JOIN必须有注释说明关联逻辑
-- ✅
SELECT o.order_id, p.product_name
FROM orders o
-- 关联产品维度表，获取商品名称
JOIN dim_product p ON o.product_id = p.product_id
 
-- 规则3：WHERE条件尽量提前过滤，减少JOIN数据量
-- 规则4：字段命名用snake_case，表名有分层前缀(ods_/dwd_/dws_)
-- 规则5：分区字段(dt)必须出现在WHERE中
-- 规则6：超过3个JOIN的SQL必须加CTE拆分
-- 规则7：聚合字段必须有别名
-- 规则8：CASE WHEN超过4个分支必须加注释
-- 规则9：INSERT前必须检查目标表分区是否存在
-- 规则10：新建表必须有表注释和核心字段注释

阶段	时间	安排	目标
熟悉环境	第1-3天	读架构文档、熟悉代码仓库、了解数仓分层、配置开发环境	知道东西在哪里
入门任务	第4-7天	独立完成一个简单的DWD表开发（有模板参考）	能跑通一个完整的ETL流程
进阶任务	第8-14天	独立完成一个DWS表开发，需要JOIN多张表、处理业务逻辑	能处理中等复杂度的SQL
独立项目	第15-30天	承担一个小型报表需求，从需求理解到上线全流程	能独立交付一个完整需求

关键细节：每天下午花15-20分钟和新人对一下进度、解答问题。不要等到新人卡住三天了才来问你——主动Check比被动等更高效。第一周密集一点（每天Check），后面逐渐放手（每周Check两次）。

Onboarding文档：我怎么写的

很多团队没有Onboarding文档，新人来了就'看代码'。这效率极低。我在每家公司都会写一份Onboarding文档：

// Onboarding文档大纲
 
// 一、业务背景（1页）
// 公司做什么业务？数据团队在公司中的角色是什么？
// 核心报表有哪些？谁在看？
 
// 二、技术架构（1页+架构图）
// 数仓分层结构、主要技术栈、调度流程
// 关键：标注出新人最先会接触的模块
 
// 三、开发环境搭建（Step by step）
// 账号申请、工具安装、代码仓库克隆、连接数仓
// 关键：每一步都有截图和命令，不需要额外求助
 
// 四、编码规范（链接到SQL规范文档）
 
// 五、常用SQL模板（3-5个典型的ETL SQL模板）
// 新人的第一个任务可以直接参考模板改
 
// 六、常见问题FAQ（持续更新）
// 每次新人问我的问题，我都加到这个FAQ里
// 这样后面的新人可以自己查
 
// 七、负责人和沟通渠道
// 技术问题找谁、需求问题找谁、权限问题找谁

这份文档的ROI非常高：写一次大约花2天，但每个新人入职时能节省至少3天的口头讲解时间。我在某出海硬件品牌写的Onboarding文档用了2年，带了4个新人，每次都是新人自己先读文档，90%的基础问题文档里都有答案。

面试高频追问

追问一：代码Review时遇到分歧怎么办？

这考的是你的沟通方式。'我遇到过几次分歧。最常见的是关于SQL写法的争论——比如有人觉得子查询比CTE更直观，我坚持用CTE。我的处理方式是：先说理由而不是结论。我会解释'CTE的可读性更好，特别是需求变更时改CTE比改嵌套子查询容易得多'，给出具体的对比例子。如果对方的理由也合理，我会把两种写法都加到规范中作为'推荐'和'可接受'，而不是强制。重点是：Review的目的是提升代码质量，不是证明谁对谁错。'

追问二：带的新人成长慢怎么办？

'我遇到过一个成长比较慢的校招新人。前两周的入门任务完成得还行，但进阶任务就卡住了——不是技术不行，而是不敢动手。他总是想把问题完全想清楚再写代码，但大数据开发很多时候需要先写个初版跑起来看效果。我的调整是：把任务拆得更细——不是给一个完整的DWS表让他做，而是先让他写查询SQL确认逻辑，再让他改成INSERT脚本，再让他配调度。每一步完成后Review，给正向反馈。一个月后他的信心上来了，效率也跟上了。核心是：降低每一步的难度，增加反馈频率。'

追问三：你建立的规范怎么确保团队遵守？

'规范如果只是一份文档放在Wiki里，没人会看。我做了三件事确保执行：第一，代码Review时严格按规范检查，不符合的打回修改。第二，在CI流程中加了自动化检查——比如检测SELECT *、检测没有分区条件的SQL。第三，新人Onboarding时第一天就读规范，第一个任务就必须按规范来。'三管齐下'后遵守率很高。偶尔有紧急需求来不及完全遵守，我允许先上线后补——但必须在下一个迭代补齐，我会跟踪。'

实战踩坑

我在某短剧出海公司做SQL代码质量治理时踩了一个'好心办坏事'的坑。为了推动代码规范化，我一次性列了30条Review规则发给团队，要求所有新提交的SQL都必须遵守。

结果是什么呢？团队的开发效率断崖式下降。每个SQL都要检查30条规则，开发时间翻倍不说，Review沟通的时间也大幅增加。有同事直接跟我说：'这些规则我都理解，但一次推30条太多了，我写个SQL比写论文还累。'

// 推规范的踩坑教训
 
// ❌ 错误做法：一次推30条规则
// 结果：开发效率下降、团队抵触情绪大
 
// ✅ 改进做法：分三批推，每批10条
// 第1批（第1周）：最核心的10条（禁止SELECT *、必须有分区条件等）
// 第2批（第3周）：进阶规则（CTE拆分、命名规范等）
// 第3批（第5周）：优化建议（Broadcast Hint、分区裁剪等）
 
// 每批之间留2周适应期
// 先让团队习惯前一批规则，再引入下一批
 
// 效果：最终30条规则都落地了，但过程平滑得多
// 团队没有抵触情绪，反而觉得规范确实提升了效率

教训：推动任何变革都要渐进式。技术人最容易犯的错是'一步到位'——觉得方案是对的就一次全推完。但人不是机器，需要适应时间。分批推、每批控制量、留适应期，效果远好于一步到位。面试时讲这个教训也是加分的——它展示了你从'个人贡献者'到'团队影响者'的成长过程。

总结

团队影响力从三个维度展示：写Onboarding文档（知识沉淀）、建SQL编码规范（标准化）、带新人有方法论（30天框架）。面试时讲清楚你做了什么规范、怎么确保执行、带新人的具体方法和效果。最关键的是展示'系统性思维'——不是遇到一个问题解决一个问题，而是建立机制防止问题反复出现。代码Review的目的是统一标准而不是找bug，带新人的关键是主动Check而不是被动等问。能做好这些事的人，就是团队里不可替代的那个人。

下一篇是项目经验系列的收官篇：面试官问'你未来的技术规划是什么'——怎么展示你的成长性和技术视野？

你带过新人吗？有什么好的经验或踩过什么坑？评论区聊聊～

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