汇川技术财务IT开发工程师二面面试题（HR + 部门经理）

《面试题目》

项目经历

1. 请快速介绍一下你的简历和项目经历。
2. 详细介绍一下你在 WMS 项目中负责的入库调度功能。
3. 原来的巷道分配策略是什么？
4. 为什么会出现巷道分配不均？
5. 大批量任务下具体会出现什么问题？
6. 你设计的巷道分配方案是怎样的？
7. 这个算法叫什么名字？
8. 这个方案是你自己做的吗，还是团队共同完成的？
9. 你在这个方案中具体负责哪些内容？
10. 你的导师对这个方案提出了哪些建议？
11. 你的业务主管对这个方案提出了哪些问题？
12. 如果某个巷道或设备发生故障，如何保证入库流程不被中断？
13. 如何处理多个请求同时分配巷道时的并发问题？
14. Redis 中具体保存了哪些数据？
15. 你是如何验证这个方案有效的？

业务理解与方案表达

16. 如果让你向非技术人员介绍这个算法，你会怎么讲？
17. 火车进站调度和仓储设备调度有什么相同点和不同点？
18. 你的方案更关注哪些指标？
19. 如何平衡系统性能、算法复杂度和后期维护成本？
20. 锁的粒度应该如何确定？
21. 锁粒度过大或过小分别会有什么问题？

ERP 与 WMS 异常排查

22. 介绍一下你处理过的 ERP 工单拆分异常。
23. 这个异常最初是如何表现出来的？
24. 你是如何定位异常根因的？
25. 如何判断问题出在 ERP、数据同步还是本地系统？
26. 你检查了哪些数据链路？
27. 最终定位到的根因是什么？
28. 你最后是如何解决这个问题的？
29. 这个问题涉及哪些角色共同配合？
30. 如何验证问题已经解决？

Redis 与限流

31. 为什么要对 RCS、WCS 回调接口进行限流？
32. 为什么单机限流不能满足需求？
33. 多实例部署下单机限流有什么问题？
34. 为什么选择 Redis 实现分布式限流？
35. 为什么使用 Redis ZSet？
36. 为什么使用 Lua 脚本？
37. 固定窗口限流有什么缺点？
38. 是否考虑过 Sentinel？为什么没有使用？
39. 如何确定限流阈值？
40. 如何判断限流策略的力度是否合适？
41. 如果限流后仍有大量请求，系统如何降级？
42. 限流误伤核心业务请求时如何处理？

职业规划与稳定性

43. 你的职业规划是什么？
44. 为什么想来汇川？
45. 为什么想从工业软件转向财务领域 IT？
46. 你如何看待企业内部 IT 岗位？
47. 未来更想往技术方向还是业务方向发展？
48. 如何看待 AI 对开发岗位的影响？
49. 如果 AI 能生成大部分代码，开发人员的优势是什么？
50. 在校期间有没有担任学生干部或参加社团？
51. 你的家庭情况如何？
52. 家庭是否支持你从事软件开发？
53. 未来是否能够长期在苏州发展？
54. 是否有对象？
55. 目前还有其他面试吗？
56. 其他公司的面试进展如何？
57. 如果同时拿到多个 offer，你会如何选择？

反问面试官

58. 入职后主要参与哪些项目？
59. 入职后前半年主要负责哪些工作？
60. 入职一年内的主要考核标准是什么？
61. 这个岗位后续更偏技术发展还是业务发展？

《参考解析》

1. 为什么巷道分配会不均：原策略多半是「就近选取」或固定优先级——按任务起点距离排序，或总是优先分配某几个巷道。问题在于它是局部贪心：每个任务单独看都选了最近的巷道，但堆叠到大批量任务上，某些巷道被反复命中、堆垛机排队越来越长，另一些巷道闲置。加上任务到达有突发性、不同巷道设备速度不一致，局部最优会累积成全局失衡。判断依据不是「平均分配」，而是尾延迟——看任务等待时间的 P99 和设备利用率方差。

2. 并发分配怎么做：核心是把「读取可用巷道状态 → 决策 → 占位」变成一个不可分割的操作，否则两个请求会读到同一份快照、选中同一巷道。工程上常用 Redis + Lua：Lua 脚本在 Redis 里原子执行「取候选 + 更新占用计数 + 返回结果」，避免多次往返之间的竞态。锁的粒度按巷道维度而不是全局——全局锁会让所有分配串行，巷道级锁让不同巷道的分配可以并行；但要处理加锁顺序一致，避免死锁。此外要有超时与释放机制，防止某个请求崩了以后巷道被永久占用。

3. 设备故障时怎么不断流：把故障巷道从候选集里摘出来（健康状态由设备心跳/状态字维护），已分配但未执行的任务要能重新调度回队列，并保证重调度是幂等的（同一个任务不能被两个巷道执行）。降级路径要事先定义：单巷道故障走重分配，整片区域故障则限流上游、让 WMS 拒收而不是堆积。

4. 为什么单机限流不够：多实例部署时每个实例只能看到自己收到的请求。假设 5 个实例、阈值都是 200 QPS，真实总流量 1000 QPS 时每个实例都认为自己没超，实际系统承受了 5 倍的量；反过来流量分配不均时，某个实例可能在自己的阈值内被压垮。而且实例扩缩容会让总阈值漂移，运维根本说不清线上到底放了多少。所以限流必须有一个全局共享的计数视图。

5. 为什么选 Redis ZSet + Lua：ZSet 的 score 可以用时间戳，成员用请求标识，这样能实现滑动窗口——每次请求先 ZREMRANGEBYSCORE 清掉窗口外的旧记录、ZCARD 数一下当前窗口内的数量，没超就 ZADD 记一条、再给 key 设过期避免冷 key 常驻。相比固定窗口，滑动窗口不会有「窗口边界前后双倍放量」的问题。用 Lua 的意义在于把「清理 + 计数 + 写入」三步合成一次原子执行，否则并发下计数会失真、还会多几次网络往返。ZSet 的代价是内存——按请求量存的元素数不少，高并发接口通常改用「分桶计数 + 滑动平均」的近似做法来省内存。

6. 为什么不用 Sentinel：Sentinel 是流量治理组件，它的强项是流控、熔断、系统自适应保护这一整套，但引入它等于多一个中间件和一套规则下发链路；如果团队只有「对几个回调接口做限流」这一个诉求，用已有的 Redis 做掉更轻。取舍标准是：需要按调用关系、按热点参数做复杂流控，或者已经有 Sentinel 集群，那用它更合适；只是简单的 QPS 限制，自建更可控。

7. 限流阈值怎么定、怎么判断力度合适：阈值不能拍脑袋，要从容量倒推——压测出下游能稳定处理的最大 QPS（留出安全系数），再看历史峰值流量分布，取一个「能挡住异常尖峰、又不误伤正常峰值」的值。判断力度是否合适看三个信号：被限流的请求比例（长期偏高说明阈值过紧）、下游的错误率和资源水位（没打满说明还能再放）、以及业务侧的核心请求成功率。上线时先设成观察模式（只记录不拦），跑一段时间后再真正生效。

8. 限流后还有大量请求怎么降级：限流只是第一道闸，后面还要有排队（削峰填谷，把请求放进队列异步处理）、降级（非核心功能返回缓存或默认值）、以及熔断（下游已经不行了就别再打）。判据是「保住核心链路」——比如 RCS/WCS 的回调关系到现场设备动作，那它属于必须保的；报表、统计这类可以延后。

9. 限流误伤核心业务怎么办：做分级限流，不同接口/不同业务线给不同的配额，核心链路预留独立额度，不要和普通流量共用一个池子；同时给关键调用方加白名单或单独配额。事后要能复盘——记录被限流的请求标识和场景，才知道误伤了谁。

10. AI 时代开发人员的优势：AI 把「写代码」这件事的单位成本压下来了，值钱的部分前移到判断——知道该做什么（业务理解）、知道做成什么样是对的（验收标准与评测）、知道出了问题该往哪查（系统直觉）。再加上对真实系统的责任：线上出事要有人担、要能做取舍。回答时结合自己的项目讲「我用 AI 做过什么、哪里它做不了我得自己上」，比抽象的行业判断可信。