简历写「精通Spark」，第一个问题该怎么问才不掉档次？
先说结论
第一个问题不要问定义题。「请讲讲Spark的架构」「什么是RDD」——这种题谁都能背，区分度为零。
第一个问题要问「使用频率题」。「你最近一次写Spark代码是什么时候？解决什么问题？」——这一问下去能筛掉一半水分。
用三层漏斗：使用场景 → 技术选择 → 踩坑细节。一层一层往下问，从大到小，逼出真实细节。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
我面过几百个候选人，简历上写「精通Spark」的至少占80%。但真正精通的，10个里面挑不出1个。问题不出在候选人，出在面试官的第一个问题——大部分面试官的第一问太老套，反而让真正会的人和会背的人没法区分。我自己摸索出一套「三层漏斗式」开场问法，今天分享给你。
第一层漏斗：先问「使用场景」
我的开场固定句式：「你最近一个跟Spark相关的工作是什么？大概什么时候做的，处理多大数据量？」。这一问的目的是建立「事实坐标」。
不要小看这一问。「精通」是个形容词，「上周提交了一个PR」是个事实。形容词可以编，事实编不出来，编了一追就漏。
-- 第一层漏斗的标准追问串
-- Q1: 你最近一次写Spark是什么时候？
-- （筛掉那种「3年前用过」还写「精通」的）
-- Q2: 那次解决的什么业务问题？
-- （看候选人能不能用业务语言描述技术工作）
-- Q3: 数据量大概多大？跑多久？
-- （量级感是重要的，10GB和10TB是两个时代）
-- Q4: 你这个作业现在还在生产跑吗？
-- （在跑的→可以追细节；不跑了→可以追为什么下线）
-- Q5: 这个作业的owner是你吗？还是别人？
-- （区分主导/参与/打杂）我面过一个候选人，写「精通Spark + Scala开发」。我问他最近一次写Scala是什么时候，他犹豫了10秒，说「工作里都用SQL，Scala是自己学的」。整个简历的可信度立刻下降一档。这就是「使用频率题」的威力。
第二层漏斗：问「技术选择」
候选人讲完使用场景后，我会切到技术选择问题。这一层是为了考察候选人的「技术品味」。
举个真实例子，我面一个候选人，他说「我用Spark SQL处理用户行为日志做聚合」。我立刻追三个问题：
// 第二层漏斗的核心追问
// 追问1: 为什么用Spark SQL不用Flink？
// → 考察对批/流的边界感
// → 优秀回答: 我们这是T+1批处理，没有低延迟需求，用Flink浪费资源
// → 普通回答: 公司技术栈是Spark （也ok，至少诚实）
// → 烂回答: Spark就是比Flink快 （错误认知，直接扣分）
// 追问2: 你这个聚合是用groupBy还是reduceByKey？为什么？
// → 考察RDD vs DataFrame边界
// → 优秀回答: DataFrame Catalyst会自动优化，我直接groupBy
// → 烂回答: reduceByKey比groupByKey快 （背书但用错场景）
// 追问3: 你的shuffle.partitions设了多少？为什么是这个值？
// → 考察是否真的调过参数
// → 真用过的人会说出具体数字和测试过程这三个追问下去，我能把「会用Spark」和「用过Spark一两次」区分开。注意：不是追问一定要答对，而是看候选人的回答里有没有「思考过」的痕迹。
第三层漏斗：问「踩坑细节」
最后一层，也是含金量最高的一层：「你这个作业有没有跑挂过？跑挂的时候你怎么排查的？」
写Spark真用过的人，没有不被OOM、Shuffle慢、数据倾斜、小文件这些坑教育过的。一个写「精通Spark」但说「作业从来没跑挂过」的人，要么撒谎要么没真用过。
| 典型踩坑话题 | 面试官追问 | 及格回答关键词 |
|---|---|---|
| OOM | Driver OOM还是Executor OOM？怎么定位？ | Spark UI、堆栈日志、collect/广播变量 |
| Shuffle慢 | 怎么发现的？怎么调？ | Spark UI看Shuffle Read/Write、调partitions、AQE |
| 数据倾斜 | 你怎么看出是倾斜不是慢？ | 看Task耗时分布、单Task特别慢 |
| 小文件 | 你的小文件是怎么治理的？ | coalesce、合并任务、动态分区调整 |
面试高频追问
追问一：候选人说「我没踩过那种坑」，怎么办？
两种可能：要么没真用过，要么用得特别浅。我会换个角度：「那你们的作业资源怎么配的？driver内存多大？executor几个？每个多少G？」。这种「配置感」是装不出来的，长期跑生产的人会脱口而出。
追问二：怎么判断候选人是「会用」还是「会调优」？
看他能不能给出「参数 + 数字 + 业务背景」的组合。比如「我把spark.sql.adaptive.enabled设成true，autoBroadcastJoinThreshold从10MB调到200MB，因为我们的维度表大都在100MB以内」——这种回答说明真的调过。光会说「开AQE就行」的，只是知道存在这个东西。
追问三：怎么应对那种「硬背了八股的人」？
八股党的弱点是「线性回答」——你按八股顺序问他都能背，但你打乱顺序+给具体场景，他就会卡住。比如他刚背完Shuffle原理，你立刻问：「那如果我给你一个10亿条订单表，按用户ID去重，你会怎么写代码？」。从原理跳到代码，八股党会断片。
实战踩坑：我曾被一个候选人骗过
某次面试，候选人说他在前公司主导Spark集群从1.6升级到2.4，简历写得专业。我当时刚做面试官没多久，听他讲技术原理头头是道，给了通过。
二面同事问了一个细节：「升级过程中你做了哪些回归测试？测试集多大？发现了几个不兼容点？」。候选人哑了。继续追：「升级期间你们怎么处理双写？切换那一晚谁值班？」，候选人答得驴唇不对马嘴。最后判定：他参与过这个项目，但绝对不是主导。
教训：技术原理是地图，项目细节才是脚印。新手面试官容易被「地图说得清楚」的候选人迷惑，老手面试官只看脚印。从那以后，我的开场提问改成了「使用频率 + 技术选择 + 踩坑细节」三层漏斗，再没被骗过。
候选人侧反向使用指南
如果你是求职者，针对这种「三层漏斗」，准备策略是——
① 简历里写「精通」之前，自己先写一遍「精通的证据」：最近写代码的时间、解决过的具体问题、调过的具体参数。如果写不出证据，把「精通」改成「熟悉」。
② 准备一两个「完整的踩坑故事」，包含：症状-定位过程-解决方案-效果-反思。一个能讲5分钟的故事，比10个一句话能力点更值钱。
③ 主动暴露弱点。「我Spark Streaming用得不多，主要用Structured Streaming和Flink」——这种主动划界让面试官信任度立刻拉满。
总结
第一个问题不要问「什么是XX」，要问「你最近一次用XX是什么时候，解决什么问题」。三层漏斗：使用场景→技术选择→踩坑细节，从大到小逼出真实水位。简历上的「精通」是钩子，面试官的活就是把钩子撬开看里面有没有货。
下一篇聊一个新人面试官最容易被打蒙的场景：候选人一上来就紧张得说不出话，怎么用3分钟让他打开？
你做面试官时，第一个技术问题一般是什么？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长