招商银行信息科技一面：数智化产品与需求判断

《面试题目》

1. 岗位需要向企业或者个人推荐数智化产品，可以接受吗？
2. 如果你作为产品经理，业务方给你一个需求让你安排开发，你怎么判断要不要开发？
3. 如果业务就说你们不懂业务，要求你们迅速开发，怎么办？
4. 实习用的什么技术栈？为什么不转正？

《参考解析》

银行科技岗问「能不能接受推荐数智化产品」，考的是你对岗位定位的理解，别急着答「可以」。 这类岗位通常分成两条线：一条是纯研发，交付内部系统；另一条是既做技术支持又要背业务指标（向分行、对公客户或外部客户推产品）。回答前先弄清对方指的是哪一种，再说自己能接受什么、以什么方式接受：如果确实偏业务侧，可以表明愿意做，同时把关注点放在「技术如何支撑转化」上，比如能做售前方案、能算清客户侧的投入产出，而不是空口推销。含糊地全盘答应，后面被追问考核方式时很容易露怯。

「要不要开发这个需求」是标准的产品判断题，答成一个决策框架就稳了。 第一步识别真实问题而不是接收方案——业务说「要一个导出按钮」，真实诉求可能是月底对账太慢，那可能改报表口径就解决了。第二步看影响面与频次：影响多少用户、多久发生一次、不解决的损失能不能量化。第三步算成本，包括开发成本、后续维护成本和机会成本（做这个就要挤掉另一个）。第四步看有没有非开发的解法：配置化、流程调整、已有功能的组合。第五步看风险与合规，涉及资金与客户数据的要单独评估。最后给结论时明确说清优先级排序依据，而不是给一个「能做/不能做」的二值答案。

「业务说不懂业务、要求迅速开发」考的是冲突处理能力，原则是先对齐问题、再谈排期。 有效做法是：把业务的口头诉求翻译成可验证的目标和指标（要解决什么问题、上线后用什么衡量成功），用原型或最小可行版本换取时间，而不是争论需求合不合理；同时把取舍摆在明面上——插队做这个需求，哪个已排期的需求要往后挪，代价由谁确认。全程留痕（需求确认、排期影响、结论）是保护自己不背锅的关键。姿态上不要站在技术的立场挡业务，用现有数据说话：现状指标是多少、改动影响哪几个链路、上线需要哪些配合。如果对方确实更懂业务，就请他给判断标准，这本身就是协作而非对抗。

这轮面试真正的考察点是「你能不能和业务一起把需求说清楚」。 银行内部系统没有外部竞争压力，需求往往来自监管、风控或分行的一线抱怨，判断标准天然模糊。所以在回答里主动带上「先定义成功指标、再定义范围」的习惯，会让面试官觉得你能独立推进事情。可以准备一个自己经历过的例子：某次需求被评审砍掉或者被砍过范围，你是怎么算账、怎么说服对方的，结论和后续效果是什么。有具体例子，前面那一整套框架才不是背出来的。

实习技术栈和「为什么不转正」这两个问题，答法是给客观约束加主动选择。 技术栈部分说清你实际写的是什么、在哪一层、用到什么中间件或框架，并挑一个能展开的点留作追问钩子。不转正的原因不要说成对前东家的评价，讲客观条件（团队没有转正名额、业务方向调整、岗位与自己方向不匹配）加上自己的判断（希望做更贴近 XX 的方向）。面试官问这个问题，通常是想确认你的离职原因会不会在这家公司重演，所以结论要落到「这里的岗位能满足我什么诉求」。

线上集中候场、每人只排五分钟却远超排期，这类体验值得当成流程成熟度的信号记下来。 面试组织本身也是被考察方：排期是否尊重候选人时间、面试官是否准时、候场是否有明确通知机制，反映的是团队的项目管理习惯。遇到这种场次，可以继续把它当成一次信息采集（问清实际工作内容、汇报关系、考核口径），再结合自己的接受度决定后面怎么投入精力，不必因为场面混乱就否定岗位本身，也不要因为已经等了很久就放弃判断。