蚂蚁面试就是不一样

面试在精，不在多





蚂蚁面试就是不一样。

或者说大厂面试，跟其它面试就是不一样。

我们以往面试是不是1个小时，2个小时，有的甚至4个小时。
可是蚂蚁不一样，10分钟就搞定。
你以为只是蚂蚁这样吗，不。
腾讯，有的面试官也是这样，20分钟就搞定了。
那么短短十几分钟，是不是面试官对应聘者不感兴趣？
今年年初，我大连的朋友，为了准备腾讯面试，可以说是下了苦功夫，各种刷题，以及探讨该如何准备面试。还请教了在腾讯工作的同事，咨询了关于面试准备，以及如何拿到 offer 的相关建议。
可是这一轮，完全意料之外，简单20分钟就完事了，而且进入了下一轮的面试。
蚂蚁面试同样也是，面试不在于时间的长短，而是在于面试官关心的问题，我们是否都给了面试官想要的答案。
咱们又不是面试官肚子的蛔虫，怎么知道他想什么，关心什么。
所以这是最难的！
那怎么办？那么我们就需要借鉴别人的经验，化为自己的知识。
以我身边面试同学的实战经历，总结蚂蚁面试官，关心哪些问题。
这里给我们分享下，蚂蚁面试官关心哪些问题。（非常宝贵，值得收藏）
1.数据规模
比如咱们列举一个具体问题，你们的数据规模，大概有多少？
对于大厂来说，如果我们公司数据量小，是和工作不匹配的，所以数据量一定要跟上，至少TB级别，能达到PB级别更好。
数据增量来说，对于小公司，其实也就万级别的，但是和大厂匹配的话，最好是上亿级别。
这时候很多同学就不自信了，难！其实不止你难，都难，国内又有几个大厂，所以我们这时候就要多学习，多请教。

2.任务数量、任务是否稳定产出
离线任务和实时任务的数量，其实也反映了业务复杂度。所以这个数量，也比较关键。有的公司十几个，比如ETL任务，Flink实时，Spark实时，Hive离线，Spark离线等等。
任务如何保证稳定产出，有的是短信报警，有的是需要人工远程监控，也就是虽然下班了，但是轮班到我们，也需要家里远程监控任务，是否稳定输出。如果有bug，运行出错，要及时解决和重启任务。
像阿里大数据监控系统依托自动化工具和智能化技术，大多数情况下无需人工干预，但在复杂场景或紧急业务中，人工干预仍然是保障系统稳定的必要手段。
保证任务产出流程为，“自动监控 → 智能解决 → 人工介入 → 优化解决”。

3.数据治理
有的公司数据治理并不系统，比如在ETL阶段只是有数据的清洗，或者字段的补充和修复，并没有系统的数据治理。
所以如果我们只有小公司的数仓经验，想面试大厂，数据治理的经验是一定要补充的。
表现出自己的专业化和系统化。
我们要记住，面试并不止是工作经验的展现，而是能力的Show。
很多同学，以为只要有经验就可以，只有经验是不行的，还需要有突出能力的表现，比如突出解决问题能力，突出技术能力。
我们要知道公司不培养能力，需要我们有意识的锻炼自己，才能让自己在面试中脱颖而出。

4.调优
大厂是非常关心，因为他们的数据量确实大。所以被问到的概率是非常大的。
不止大厂关心，小公司也经常作为面试的门槛。
所以如果我们是做开发，必须会调优。
在面试中，如何让面试官觉得我们会调优。
有的朋友，只说几个参数、配置这是不行的。
最起码，我们要说出相关场景。
1.什么场景下遇到问题。
2.这个问题，怎么分析的。
3.分析后，尝试了哪些解决思路。
4.解决后的效果是什么。
这里举例仅供大家参考

1. 背景与问题场景
场景：
淘宝每日运行一份用户行为分析的 Hive SQL 报表，任务处理的主要数据包括：
用户点击日志（约 100 TB/天）。
商品销售数据（约 10 TB/天）。
运行 SQL 脚本用于生成用户购买转化率报表，处理时间原本约为 2 小时。
问题：随着业务增长，数据量快速上升，SQL 脚本运行时间飙升至 6 小时，严重影响后续业务的正常运行。

2. 问题分析
在问题发生后，采用以下方法逐步分析原因：
（1）监控任务执行阶段
通过 Hive 的 EXPLAIN 命令和 Yarn 资源监控平台，分析 SQL 的各阶段执行耗时：
Map 阶段耗时过长：数据量过大，导致 Map 阶段执行时间明显增加。
Join 阶段 Spill 到磁盘：部分 Join 操作中间结果溢出内存，频繁写入磁盘。
Reduce 阶段数据倾斜：某些 Key 数据量过大，导致 Reduce 任务时间延长。
（2）确认性能瓶颈
结合日志与性能监控工具，发现主要性能瓶颈：
数据分区未充分利用：日志表为分区表，但查询未过滤日期，导致全表扫描。
Join 数据量过大：直接 Join 两张大表，未提前过滤无关数据。
Reduce 阶段数据倾斜：某些用户 ID（热门用户）产生了超大数据量。

3. 解决思路与尝试
针对上述问题，逐步尝试以下调优策略：
（1）优化数据扫描范围
问题：未过滤分区，导致全表扫描。
解决：在 SQL 中加入分区过滤条件（如 WHERE log_date = '2024-11-25'）。
确保分区字段已被 Hive 元数据正确识别。
（2）优化 Join 操作
问题：直接 Join 两张大表，导致数据量过大。
解决：
1.使用 Map Join：对一张小表（商品销售表）提前 Broadcast 到内存。
set hive.auto.convert.join=true;
对大表提前过滤无关数据后再 Join。
WITH filtered_logs AS (
SELECT * FROM user_logs WHERE log_date = '2024-11-25'
)
SELECT ...
FROM filtered_logs
JOIN sales_data
ON ...

（3）解决数据倾斜
问题：Reduce 阶段由于部分 Key（热门用户）导致数据倾斜。
解决：
1.随机打散热点 Key：通过新增随机数字段，打散热点 Key。
SELECT CONCAT(user_id, '_', RAND()) AS user_id_rand, ...
2. 使用 Hive 的 skewjoin 参数：
set hive.optimize.skewjoin=true;
（4）合理设置资源参数
问题：资源不足导致性能瓶颈。
解决：1.调整 Hive 执行参数：
set hive.exec.parallel=true;      -- 开启并行执行
set hive.exec.reducers.bytes.per.reducer=256000000; -- 合理设置 Reducer 数
2.增加任务运行的内存和 CPU 配置。

4. 调优后的效果
经过上述优化，SQL 性能有显著提升：
执行时间从 6 小时缩短至 1.5 小时，满足业务需求。
资源消耗降低：减少了磁盘 I/O 和内存使用。

当然这些问题，不止蚂蚁关心，对于大厂来说，几乎是通用的，调优几乎是必问的。
我们可以换位思考，如果你是公司的领导，那么肯定想招聘一个，可以直接上手工作的员工，特别是社招。
对于大厂来说，由于数据量很大，所以需要理论上精通大数据调优，比如Hive调优，Flink调优等。
这里需要强调的是，有的同学为了让自己简历好看，获取更多的机会，所以就把各种组件调优，全部写上。
这是另外一种极端，是非常不可信的。我们在实际的工作中，能遇到一两个调优就不错了。简历上布满了调优，这是非常不切实际的。
所以我们不要以为调优写的越多越好，面试在精，不在多。多了，反而不可信。
另外2024年，受ChatGPT影响，面试发生了巨大的变化。
对于社招来说，不再是传统的先笔试后面试，而是先面试，然后现场再给一道编程题。所谓现场，就是面试官监考，需要屏幕共享。
所以我们想跳槽的话，一定要做好这方面的准备。
当然面试还有其它的变化，比如面试的难度，面试招人的规则等等，都发生了变化。
如果小伙伴比较关心的话，咱们下次再详细说。

最新经典文章，欢迎关注公众号

社区创作者介绍

2013年创办About云社区，成为大数据垂直领域NO1。2017年最早提出并发起系统帮助IT人面试和就业，帮助1万+Learner拿到offer，积累了大量的行业经验和资料。
2020年成立北京梭伦科技有限公司。2023年上线中文本Chat GPT智能星。通过智能星+面试提高我们面试、职场竞争力。

个人微信：w3aboutyun