1. 实习内容还在职吗
2. 有独立做过需求吗
3. 做过最难的需求是什么
4. 你处理的数据量有多大
5. 有接过实时的需求吗
6. Flink了解多少
7. 有主动钻研过数据领域的技术吗
8. 保障过SLA基线吗
9. 保障SLA基线要从哪方面着手
10. 生服这么缺人力为什么要跨部门转正呢

场景题

11 如果一周给你定容了三个需求，你会怎么排期呢

12 如果你排期完成后，发现自己判断失误，这个需求在原定排期内做不完，你会怎么办你觉得保障SLA基线最困难的点在哪里

SQL

13 table两个字段 a b   代表了a关注了b写一个SQL找到相互关注的用户（尽量高效）

14 table student_id  course  score1           语文     78找出单个学科成绩第三名的同学的ID，总成绩和总成绩的全班排名

15 tabledate        people2025-08-01  1412025-08-02  35日期是主键，people代表当日人流量找出连续三天人流量>100的date

答案如下

1. 实习内容

考察知识点

• 实习经历的真实性与细节颗粒度
• 项目参与深度（是否独立负责模块 / 环节）
• 技术栈应用能力（如 Hive、Flink、Spark 等工具的落地）
• 问题解决与结果导向思维

参考回答

我在 XX 公司数据部门实习了 6 个月，核心参与「用户行为分析平台」和「实时交易监控」两个项目，分阶段负责不同工作：

• 初期（1-2 月）：协助离线数据清洗，用 Hive SQL 处理用户浏览日志（日均 10TB），过滤无效数据（如爬虫请求），优化 SQL 执行效率（将子查询改为 JOIN，执行时间从 40min 缩短至 15min）；
• 中期（3-5 月）：独立负责「实时交易异常检测」模块，用 Kafka 接入交易流数据，Flink 实时计算单笔订单金额、频次等指标，触发异常阈值（如 1 小时内同一账号下单 > 10 次）时推送告警至业务端，期间解决了 Flink 维表关联冷启动问题（通过预加载小表至本地缓存，延迟从 200ms 降至 50ms）；
• 后期（6 月）：参与项目复盘，输出数据质量报告（准确率 99.98%，告警响应时间 < 1s），并提出「按用户等级调整异常阈值」的优化建议，已被纳入下一版本迭代。

补充注意要点

• 避免泛泛而谈（如 “我做了数据处理”），需明确「做什么、用什么技术、遇到什么问题、怎么解决、有什么结果」；
• 突出 “成长轨迹”（从协助到独立负责），体现学习能力；
• 数据化结果（如数据量、效率提升比例、准确率）更有说服力。

2. 还在职吗

考察知识点

• 求职状态真实性（是否存在离职交接冲突）
• 入职可能性与时间匹配度（避免 offer 发放后无法到岗）

参考回答

我目前仍在职，已和领导提前沟通过 “职业发展方向调整” 的想法，领导表示理解。若能拿到贵司 offer，我会预留 2 周时间完成工作交接（主要是离线报表任务的文档梳理、实时任务的监控权限移交），确保不影响原团队进度，2 周后可正式到岗。

补充注意要点

• 坦诚表述，不隐瞒在职状态（避免后期背调风险）；
• 主动提及 “交接方案”，体现责任心和职业素养；
• 若已离职，直接说明 “已离职，目前可全身心投入新工作，随时能到岗” 即可。

3. 有独立做过需求吗

考察知识点

• 独立负责项目的全流程能力（需求拆解→方案设计→开发→上线→复盘）
• 技术落地与业务结合的能力
• 风险应对与结果交付意识

参考回答

有，去年独立负责「电商大促前用户复购预测」需求：

• 背景：业务方需要提前 3 天预测高复购用户（近 30 天有消费且大促意向强），用于精准发券；
• 全流程负责：从需求拆解（明确 “复购用户定义”“预测维度”）→方案设计（用 Spark MLlib 训练逻辑回归模型，特征包括历史消费频次、浏览时长、加购行为）→开发（用 Hive 预处理特征数据，Spark 训练模型，结果写入 MySQL 供业务调用）→测试（对比历史数据验证模型准确率，从 82% 优化至 88%）→上线（大促前 5 天完成部署，设置每日重跑任务）；
• 结果：大促期间高复购用户券核销率提升 35%，直接带动 GMV 增长 8%，后续该模型被复用至日常营销活动。

补充注意要点

• 选 “小而完整” 的需求（而非 “参与的大项目片段”），体现 “独立闭环” 能力；
• 重点说 “自己做的决策”（如为何选逻辑回归而非 XGBoost，因数据量小、训练速度快），体现思考深度。

4. 做过最难的需求是什么

考察知识点

• 复杂问题拆解能力（是否能将 “难” 转化为可落地的步骤）
• 技术攻坚与抗压能力
• 复盘总结与经验沉淀意识

参考回答

最难的是「实时物流轨迹异常监控」需求，难点在于 “低延迟 + 高准确性” 双重要求：

• 难在哪：① 物流数据实时产生（日均 5000 万条 GPS 记录），需 10s 内判断是否偏离规划路线；② 异常场景多（如临时绕路、信号丢失），误判率需 < 1%；
• 拆解与攻坚：
  1. 先拆链路：数据接入（Kafka）→实时计算（Flink）→异常判断（自定义算法）→结果输出（Redis + 告警）；
  2. 解决核心问题：① 延迟：将 Flink 并行度从 8 调至 16，State 后端用 RocksDB（减少内存占用），延迟从 20s 降至 8s；② 误判：加入 “历史路线匹配” 逻辑（若偏离路线但属于常用绕路区域，不触发告警），误判率从 3% 降至 0.8%；
• 结果：需求按时上线，大促期间物流异常响应时间缩短 60%，用户投诉率下降 25%，后续整理了《实时轨迹监控技术方案》同步给团队。

补充注意要点

• 先明确 “难的具体原因”（技术瓶颈 / 业务复杂 / 资源不足），再讲 “怎么解决”，避免只说 “难” 不说 “解法”；
• 突出 “主动思考”（如自己查 Flink 官方文档调优 State，而非依赖同事）。

5. 你处理的数据量有多大

考察知识点

• 大数据场景的实战经验（是否接触过 TB/PB 级数据）
• 对数据量级的认知（不同量级对应的技术选型差异）
• 性能优化能力（如何适配大数据量处理）

参考回答

实习期间主要处理两类数据，量级和方案如下：

• 离线数据：每日处理用户行为日志（500TB，包括浏览、点击、下单），用 HDFS 存储（按日期 + 地区分区），Hive 做离线计算（采用 ORC 压缩格式，比 Text 格式节省 60% 存储空间），Spark 做聚合分析（如 “各地区日活用户”），单任务执行时间从 2 小时优化至 40 分钟（主要是分桶 JOIN 解决数据倾斜）；
• 实时数据：处理实时交易流（峰值 QPS 2 万，每条数据 1KB），用 Kafka 接入（3 个副本，20 个分区），Flink 实时计算（窗口大小 5s，并行度 12），结果写入 ClickHouse（按交易时间分区），供业务端实时查询 “实时 GMV”“Top10 商品销量”，延迟稳定在 50ms 内。

补充注意要点

• 分 “离线 / 实时” 说明（符合大数据岗位常见场景），数据量要具体（避免 “很大”“很多”）；
• 结合技术选型和优化手段（如压缩格式、分区策略、并行度调整），体现对 “数据量适配技术” 的理解。

6. 有接过实时的需求吗

考察知识点

• 实时计算技术栈掌握程度（Kafka/Flink/Spark Streaming）
• 实时需求的核心痛点应对（如延迟、 Exactly-Once 语义）
• 业务价值落地（实时数据如何支撑业务）

参考回答

接过「实时商品库存监控」需求，业务方需要实时同步库存变更（如下单减库存、退货加库存），避免超卖：

• 技术栈：Kafka（接收 ERP 系统的库存变更日志）+ Flink（实时计算库存余量）+ Redis（缓存实时库存，供前端查询）；
• 关键处理：
  1. 数据可靠性：用 Flink 的 Checkpoint（间隔 1min）+ Kafka 的 Offset 提交，保障 Exactly-Once 语义（避免库存计算重复或丢失）；
  2. 低延迟：优化 Flink Source 端（批量拉取 Kafka 数据，批次大小 1000 条），Sink 端（Redis 批量写入，减少网络 IO），延迟从 150ms 降至 80ms；
  3. 异常处理：设置库存为 0 时触发告警，同时屏蔽 “负数库存”（因网络延迟导致的重复扣减）；
• 结果：上线后零超卖事故，库存数据同步延迟 < 100ms，支撑了 618 大促期间 10 万 + 商品的实时库存展示。

补充注意要点

• 明确 “实时需求的业务目标”（如避免超卖、实时监控），而非只讲技术；
• 提及实时场景的核心技术点（如 Exactly-Once、Checkpoint、延迟优化），体现专业性。

7. Flink 了解多少

考察知识点

• Flink 核心原理的理解深度（流批一体、State、Watermark 等）
• 实际应用经验（场景 + 问题 + 解法）
• 问题排查与调优能力

参考回答

我对 Flink 的理解分 “理论 + 应用” 两部分：

• 理论层面：掌握核心概念，比如① 流批一体（基于 DataStream API 统一处理流和批数据）；② State（管理计算中间状态，支持 Keyed State 和 Operator State，大状态用 RocksDB 后端）；③ Checkpoint（周期性快照，保障故障恢复不丢数据）；④ Watermark（处理乱序数据，定义数据迟到阈值）；