大数据架构师面试，面试官到底在问什么？

 

我这几年面试过不少候选人，也被别人面试过一些岗位。今天不站求职者这边了，咱们换一面，站到面试官这边，说说我到底想通过提问摸什么。

---

我参与过的面试大概两类，一类是坐在面试官这一头筛别人，多数时候是数据治理或者大数据架构的岗位。另一类是坐在对面被别人挑，主要是业务方PO要验证数据方是不是真懂业务。

两类都不少。

有一件事挺让我意外的，绝大多数候选人挂掉，不是因为不会答，而是答非所问。问题明明问的是A，他在那边把B、C、D全说了一遍，听着都对，但就是没解决我的疑问。

今天这篇是写给求职的数据朋友的。我想站在面试官这一头，把我每次提问的真正动机说清楚。也顺便聊聊什么样的回答会让面试官眼前亮一下。

这两年我看过不下50份架构师简历，面过不下20个候选人。下文很多案例来自这些真实场景，候选人姓名我都隐掉了。

面试官最想知道的三件事

不管问题怎么变，背后其实是想摸清楚三件事。

第一件事你干过没有。简历上写的项目，候选人是不是真参与过，是负责了核心模块还是跟着打杂，面试官一两个问题就能摸出来。

第二件事你踩过坑没有。架构师最值钱的不是知道多少方案，是知道哪些方案是坑。纸上谈兵的方案谁都能列，遇到具体情况怎么选才是分水岭。

第三件事你有没有体系化思维。架构师不是堆技术，是要能把业务、数据、技术、治理这几件事拼到一起看。能说清楚相互关系的人不多。

三件事问完，我心里基本就有数了。剩下的就是看沟通能力、看稳定性、看薪资预期这些软因素。

第一类问题 架构能力

这类问题最典型。你设计的系统，QPS能扛多少？数据量级到哪个量级？你们数仓分了哪几层，为什么这么分？

很多人听到这种问题就开始背答案。什么QPS几万、什么T+1、什么Lambda架构，噼里啪啦一通背。背完我基本就知道这份简历八成有水分。

我问QPS的真实意图，是想让你说出具体数字背后的故事。QPS背后的故事是什么？是架构选型，是业务峰值，是压测数据，是出过事故之后的调优。一个真实在QPS上万系统上干活的人，讲出来的东西一定带着「当时为什么这么做」「踩了什么坑」。

我之前面过一个候选人，做过某合资品牌的数据治理，简历写得挺漂亮，我问他系统里数据量多大，他张口就来日增十亿级。一听就是背的。十亿级的数据，Kafka分区数至少上百，存储选型肯定不是普通的HDFS，存算分离早就上了。怎么保障查询时效，怎么做冷热分层，怎么控制成本，这一串具体问题他一个都答不上来。

这种问题怎么答？先说一个你亲手做过的真实数字，再说数字背后的架构选择，最后说踩过的坑和反思。三个层次任意两层，面试官都会觉得你真干过。

举个例子。我之前写过的数仓分层文章里提过V企的实际经验，分四层，ODS到DWS到底怎么分，每层多少张表，每个表数据量多大，命名规范什么样。能把这套说清楚的候选人，我一般都会给高分。

不能把抽象框架往自己身上套，得有你自己的细节。

第二类问题 治理能力

数据治理方向的岗位，这类问题问得尤其多。怎么管主数据？数据质量出问题怎么排查？怎么推动业务方改一个数据口径？

这类问题的套路我一般三层。第一层问方法论，看你知不知道DAMA、数据治理六维度这些基本框架。第二层问场景，看你能不能把框架落地到具体业务里。第三层问推动力，看你作为数据方能不能驱动业务方做改变。

大部分人能回答第一层，第二层开始卡壳，第三层完全答不上来。

讲个我审过的真实简历。候选人A做了8年数据治理，项目经历里「客户信息治理」「标签体系管理」「客户360视图」写了一长串，看着经验很丰富。我约他来面试，第一轮就问他哪个项目推动业务方改变数据口径最难，他答不上来。

后来我问得细一点才知道，他这8年基本就是在合资品牌A客户的项目上做信息治理和ETL开发，工作内容是把客户数据从业务系统拉过来按规则清洗入库。清洗规则是项目经理定的，标签体系是产品经理设计的。他就是个高级开发，并没有真正主导过数据治理。

这就是简历套路化最典型的案例。技术栈写了一堆关键词，工作描述写了一堆通用动作，但凡问一句「你怎么推动」就露馅。

这类问题的核心考点就是看你有没有推动力。数据治理的难点从来不是技术，是要让业务方主动改一个用了十年的字段定义。如果你的简历里没有一段经历讲清楚你推动了什么、阻力是什么、最后怎么落地的，那大概率面试官会觉得你只是高级工具人。

第三类问题 技术栈深度

这类问题是候选人最卷的地方，也是水分最大的地方。

Spark任务慢怎么排查？Kafka消息丢了怎么办？Hive小文件问题怎么处理？我经常在面试里问这些问题，因为这些都是日常会遇到的真问题。

简历套路化在这种问题上最严重。候选人B的简历我印象很深，技术栈写了一屏的框架名字，Spring Cloud、Spring Boot、MyBatis、Hibernate、Vue、Redis、MQ、WebService，我数了一下超过十个。他工作12年，看着像全栈。简历项目经验呢，某合资OSM系统做了3年，某合资DMS系统做了2年。

我面试他的时候问Spark优化，他张口就背那几个官方建议，调参、并行度、shuffle、广播变量。我问他在OSM系统里具体怎么调的，他愣了。OSM是订单仓储类系统，根本不跑Spark。

这种就是典型的简历堆技术栈。技术栈写了一堆，真实用过的就那么几个。

怎么回答这类问题？我自己的经验是先把场景说清楚。你说Spark任务慢，先告诉面试官你这是一个什么样的任务，业务背景是什么，数据量多大，跑在什么集群上，再说排查思路。排查思路本身倒是其次，能不能结合真实场景讲出来是真功夫。

不要说「Spark是分布式计算框架，支持内存计算，比MapReduce快」，面试官想听的不是这个。面试官想听的是你具体遇到了什么慢，怎么定位的，最后怎么解决的。

加分项是讲你做过的具体调优。比如有个任务从单次跑45分钟优化到8分钟，你可以告诉面试官原因是数据倾斜，定位的SQL是哪个广播变量没生效，最后怎么改的。这种细节一出来，对方立刻知道你是真干活的。

第四类问题 项目复盘

这类问题是我最看重的。

问你在这个项目里最难的事是什么。问你在项目里最想重构的一段代码是什么。问你在项目里和同事最大的分歧是什么，怎么解决的。

三个问题问完，候选人的担当、反思、沟通能力基本就摸出来了。

最难的问题怎么答呢？我的建议是用STAR法则，但又不是简单的STAR。STAR是个框架，面试官听得多了会觉得你有套话嫌疑。真正打动面试官的是STAR后面那段反思。

我之前写过的OneID文章里提过，C企项目里我们一开始做了个简单的规则匹配，三层四级，手机号匹配证件号匹配车架号。这种方案当时听着挺合理，真跑起来发现匹配率只有60%多。后来才改成图算法，走Spark GraphX，连通图加最短路径。这个改动是项目里最有价值的部分。

如果我是候选人，我会在面试里讲这个故事。先讲当时的方案为什么合理，再讲跑起来发现了什么问题，再讲怎么定位到问题，再讲换成图算法的决定是怎么做出来的，再讲最终效果。最后一定要加一句反思，当时如果早做压测就不会花那么长时间走弯路了。

有反思的项目复盘和没有反思的复盘，是完全两个档次的候选人。

面试官最想听到的回答 长什么样

讲完了四类问题，最后讲讲我作为面试官，最喜欢什么样的回答。

第一类是有数字的回答。你说一个项目，别讲「很多」，讲具体数字。日增数据量多少，表数量多少，节省了多少人力，提升了多少时效。数字让人觉得踏实。

第二类是有决策痕迹的回答。架构师的能力体现在选型上，不是体现在会用多少工具。你做A方案而不是B方案，你的理由是什么，你的取舍逻辑是什么，这种回答让人知道你是有判断力的。

第三类是有反思的回答。再漂亮的项目，讲起来全是顺利的，面试官反而不信。讲一个你踩过的坑，讲一个你后来想明白了的教训，反而让人觉得真实。我之前写的云原生化迁移文章里那五个坑，没有一个是我提前预料到的，全是干出来之后才知道的。这种回答打动人。

第四类是有边界的回答。架构师最怕的就是什么都拍胸脯说我会。一个靠谱的候选人应该知道自己会什么不会什么，能诚实地讲我现在没做过这个，但我知道大致思路，我可以学。这种回答反而让人觉得放心，因为他在你团队里大概率是个不会乱承诺的人。

加分句 几个让你加印象的细节

面试最后一般会有几分钟反问环节。反问环节问什么最能加分？

别问薪资。薪资下次聊。

最加分的问题是你对这个岗位有什么期待？这个角色在前三个月应该重点做什么？我能从这个回答里听出来你有没有认真研究这个岗位。

第二个加分动作是面试结束时主动加面试官微信。这不是套近乎，是给你一个后续感谢和追踪的机会。很多候选人这一关都忘了，结果面试官在系统里走流程你这边完全失联。

第三个加分动作是面试完当天发一封简短的感谢邮件。一百字就够。表达感谢，回顾一个让你印象深刻的点，再补一句你后续可以提供哪些补充材料。这种小动作在面试官眼里非常加分。

写在最后

面试是双向选择，不只是面试官挑你，也是你挑这个团队、这个岗位。

不要把面试当考试，要当一次坦诚的沟通。会的就说会，不会就说不会但愿意学。架构师岗位上，最值钱的从来不是你知道多少答案，是你敢不敢承认自己不知道。

---

作者 凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

完整系列目录和资料包在公众号「凌波微数」，微信搜一搜就能找到。

下一篇预告 W11 SAP BO到QuickBI，BI工具十年变迁。