招行信用卡中心的笔试在银行系IT校招里一直是个比较特别的存在。它不是纯行测也不是纯LeetCode而是把金融业务场景和技术基础揉在一起考。2019秋招开发方向第一批的这套题我印象还挺深——题型结构、考点覆盖、以及几个藏在细节里的坑对后来准备银行科技岗的同学都很有参考价值。这篇文章我就按当时的考场体验把选择题、编程题、SQL场景题这些内容拆开聊一聊重点说说怎么分配时间、怎么避开那些容易丢分的点。1. 银行系IT笔试和互联网大厂的差别比你想的大1.1 为什么专门聊这一场笔试很多准备校招的同学会有个误区觉得笔试就两种一种是刷LeetCode一种是做行测。但招行信用卡中心的开发岗笔试偏偏是第三种——它既有技术基础题又有贴近信用卡业务的场景题还会在编程题里嵌入跟金融业务相关的小逻辑。如果你只按互联网大厂的方式准备会发现在选择题上浪费了大量时间而真正拉分的场景题反而没准备到。我记得2019年秋招这一批整体是线上统一笔试题目分几个大块选择题、编程题、SQL/数据库设计题、以及一部分结合信用卡业务场景的主观题。全部做完大概需要两个半小时到三个小时时间算不上特别充裕尤其编程题如果卡住了后面的场景题就没时间写。所以我对这场考试的评价是它考的不是你会不会写代码而是你在有限时间内能不能把代码和业务理解结合起来输出一份“能干活”而非“能跑通”的答案。1.2 笔试的基本盘形式、时间与题型分布按当时的笔试通知和实际体验大致情况如下表模块题量建议用时考察重心选择题单选多选约30题50-60分钟数据结构、算法、网络、OS、Java基础、数据库理论编程题3题70-80分钟字符串处理、模拟题、动态规划/贪心数据库与场景设计2-3题30-40分钟SQL编写、表结构设计、业务场景处理综合主观题1题左右10-15分钟业务理解、方案设计这里有个小提示不同批次抽到的题型分布可能不完全一样但“开发方向第一批”这套配置基本代表了招行卡中心对开发岗位的技术预期。我当时就是没料到会有业务场景题导致最后一道主观题写得比较仓促这一点后文会细说。提示银行系笔试和互联网大厂笔试最大的区别在于“业务背景”的权重。互联网大厂更多考纯算法和系统设计银行系则喜欢把技术问题放在“账户、交易、风控、对账”这些具体场景里答案不仅要正确还要考虑金融场景的特有约束。2. 选择题不考手撕红黑树但基础考点细得让人出汗2.1 数据结构与算法底层逻辑反复考选择题里数据结构与算法的占比不低但难度确实没到ACM那种级别。考得最多的是栈和队列的性质、二叉树遍历、哈希冲突处理、排序算法的时间复杂度与稳定性。比如有一道题是给一个中缀表达式转后缀表达式问用栈的过程中栈的最大深度是多少还有一道给了一组关键字序列问用快速排序第一趟之后的结果。这些题不难但要求你对基础结论非常熟练不能现场推导。一个容易丢分的点是**“排序稳定性”的判断题**。选择题里可能会同时出现快排、堆排、归并排序、直接插入排序让你选哪些是稳定的、哪些是不稳定的。如果只是背结论很容易混淆。我当时用的是“快选堆希不稳定其余排序都稳定”这个口诀——快排、选择、堆排、希尔是不稳定的归并、插入、冒泡、基数排序是稳定的。这个口诀考试时省了不少时间。2.2 计算机网络与操作系统偏“应用场景”而不是“原理背诵”网络题在这个笔试里不算难但比较偏实际应用。比如问TCP三次握手中第二次握手的标志位是什么HTTP状态码502和504分别代表什么HTTPS握手过程中证书验证发生在哪一步。这些属于“用的时候能想起来”的知识点如果你平时主要靠框架开发没有系统复习过网络基础容易在这些题上丢分。操作系统部分考了进程与线程的区别、死锁产生的四个必要条件、虚拟内存与页面置换。有一道题我记得很清楚给一组页面访问序列问用FIFO和LRU算法分别产生多少次缺页中断。这道题本身不难但需要你按部就班地推演费时间。我当时是先跳过把后面性价比更高的题做完再回头来算的。考场上的时间管理真的很重要一道选择题卡住5分钟以上就说明你分配不合理了。2.3 Java、数据库考点求职者的两大分水岭招行卡中心开发岗以Java技术栈为主所以Java基础考得比较细。考点集中在集合类的底层实现HashMap在JDK 8之后引入了红黑树、JVM内存区域划分、垃圾回收算法、synchronized与ReentrantLock的区别、线程池核心参数。有一道多选题问“哪些情况会导致Full GC”选项涉及老年代空间不足、永久代/元空间不足、CMS GC失败、大对象直接进入老年代等——这道题能筛掉不少只看过八股文但没有深入理解JVM的人。数据库理论部分主要考索引失效场景、事务的ACID、隔离级别与脏读/不可重复读/幻读的对应关系、三范式。有一道题问“RR隔离级别下InnoDB如何解决幻读”答案是MVCC间隙锁。如果你只背了隔离级别定义没接触过InnoDB的锁机制这题就不好猜。这里也能看出银行系统对数据一致性的要求是体现在笔试里的不只是考概念还在考你有没有“金融系统思维”。注意选择题中一般会有2-3道“陌生题”比如偏门Linux命令。遇到完全没见过的题不要恋战按第一直觉选一个然后标记好有时间再回来想。很多同学就是因为在一道Linux题上纠结太久导致后面编程题时间不够。3. 三道编程题看着眼熟AC率却不高3.1 第一题信用卡号Luhn校验——字符串处理不要想复杂编程题第一题通常是热身级别的那道题我印象很深校验一串信用卡号是否合法用的标准是Luhn算法。Luhn算法的规则是从右往左数偶数位上的数字乘以2如果乘积大于9就减9然后把所有数字相加如果结果能被10整除则号码合法。题目的坑不在于Luhn算法本身而在于输入格式。它给的信用卡号可能带空格或短横线要求先过滤掉这些字符再校验。我当时看到题的第一反应是“这不是发卡系统的日常需求吗”然后老老实实写public static boolean isValidCardNumber(String rawCardNumber) { StringBuilder sb new StringBuilder(); for (char c : rawCardNumber.toCharArray()) { if (Character.isDigit(c)) { sb.append(c); } } String cardNumber sb.toString(); if (cardNumber.length() 12 || cardNumber.length() 19) { return false; } int sum 0; boolean doubleDigit false; for (int i cardNumber.length() - 1; i 0; i--) { int digit cardNumber.charAt(i) - 0; if (doubleDigit) { digit * 2; if (digit 9) { digit - 9; } } sum digit; doubleDigit !doubleDigit; } return sum % 10 0; }这道题有几个隐藏的考察点一是你能不能在读题时想到预处理非法字符二是长度校验的边界值。很多同批同学直接按“纯数字串”来做结果有一个测试用例因为带了短横线而失败。所以说编程题不一定多难但一定要仔细看输入描述。3.2 第二题交易流水统计——模拟题考的是边界第二题是一道模拟题大概意思是给一批信用卡交易记录每条记录包含交易时间、交易商户、交易金额、卡号等信息要求按商户统计交易总笔数和总金额并按总金额降序输出如果总金额相同按商户名称字典序升序输出。这道题核心是排序和分组统计用HashMap 自定义排序就能解。但它有三个很现实的坑第一个坑是金额精度。交易金额一般带小数如果用float或double存可能在累加时出现精度丢失导致排序结果错误。正确做法是用BigDecimal或者把金额乘以100转成整数分来存储计算。我在笔试时直接用long存“分”既避开了精度问题又提高了运算速度。第二个坑是Comparator的写法。金额降序、名称升序这个需求在Java 8里可以用lambda实现但要注意Comparator的连写顺序list.sort(Comparator .comparingLong(StatItem::getTotalAmountInCents) .reversed() .thenComparing(StatItem::getMerchantName));第三个坑是日期与时间格式化。题目要求按“yyyy-MM-dd HH:mm:ss”格式输出或解析时间如果直接用String.substring()切分很容易因为空格或前导零导致解析错误。我当时直接用了LocalDateTime.parse配合DateTimeFormatter虽然代码多几行但安全很多。这道题给我的感觉就是银行里很常见的“报表统计需求”没什么算法难度但边界和精度意识决定了你是AC还是WA。如果你平时写代码不注意输入输出格式和数值类型这种题反而最容易翻车。3.3 第三题最优还款计划——DP还是贪心要想清楚第三题开始有区分度了。题目背景是一张信用卡有账单周期账单日之后有一个还款日你手头有一笔钱可以提前还款也可以放在活期账户赚一点点利息问在还款日之前如何安排还款金额使总收益最大。本质上是一个类背包问题但它把业务背景包装得非常“信用卡”。我当时第一反应是贪心利息高的期数先还每期尽量多还。但写着写着发现不对因为题目里每期账单的金额不同、利率也不同而且“多还的部分不会产生额外收益”所以需要按利率从高到低排序逐期决策。这个思路其实是“贪心排序”并不是真正的动态规划。而如果你把它当成完全背包做复杂度会爆炸而且容易写错。更稳妥的思路是这样的先把所有分期按年化利率降序排列然后逐期判断“当前可用资金够不够还这一期”。如果够就还完这一期剩余资金继续处理下一期如果不够就把剩余资金全部还进去结束。这道题的目的不是让你设计多么复杂的金融产品而是考察在业务约束下你能不能识别出正确的算法模型。识别错了代码写得再漂亮也没用。这道题给我的启发是银行系笔试题的算法难度整体低于互联网大厂但它们更看重你“从业务描述中抽象模型”的能力。如果你看到“信用卡”三个字就慌或者看到“最优”就条件反射写DP反而容易掉进陷阱。3.4 编程题真正的坑IO、复杂度和审题编程题的整体难度确实比互联网大厂低一档但AC率不高主要原因集中在三个方面第一输入输出格式。银行笔试的在线OJ通常用标准输入输出但有些同学平时在IDE里写习惯了没有亲自处理过多行输入导致Scanner的nextLine和nextInt混用时出现换行符残留的问题。我当时处理方法是整行读取再解析避免混用。比如BufferedReader reader new BufferedReader(new InputStreamReader(System.in)); int n Integer.parseInt(reader.readLine()); for (int i 0; i n; i) { String[] parts reader.readLine().split( ); // 按需解析 }第二时间复杂度。选择题里考复杂度编程题里也有人中了复杂度陷阱。比如交易流水统计那题如果直接用双重循环比较所有商户数据量大时可能超时。正确做法是先用HashMap聚合再排序复杂度从O(n^2)降到O(n log n)。这个考点很基础但在机考压力下很多人第一反应就是“先暴力写出来再说”结果拿不到满分。第三审题不清。第三题“最优还款计划”里有一个不显眼的约束手头资金不能拆分到某一期的部分还款之外也就是说每一期要么按给出的金额还要么不还。如果不仔细读题很容易把简单问题复杂化。这也是我在考场上差点踩的坑。经验做完编程题后一定要留5分钟检查一下数据类型和算法复杂度。银行笔试OJ的测试用例通常比较全边界情况空字符串、超大数、负金额都是故意埋好的雷。宁可少写一道附加题也要保证已写题目的边界处理正确。4. 数据库与场景设计题贴着信用卡业务出题是最大特色4.1 经典SQL题逾期用户与消费排行这套笔试的数据库题算是整场考试里“银行味”最浓的部分。有一道题是给定用户表、信用卡表、账单表、还款记录表要求统计出最近三个月内逾期次数超过2次的用户并按逾期次数降序输出。这道题考察的是多表关联、分组聚合、子查询/窗口函数。我当时用的是多表JOIN GROUP BY HAVING的方式SELECT u.user_id, u.user_name, COUNT(DISTINCT b.bill_id) AS overdue_count FROM user_info u JOIN credit_card c ON u.user_id c.user_id JOIN bill_info b ON c.card_id b.card_id WHERE b.due_date CURDATE() AND b.paid_flag 0 AND b.bill_date DATE_SUB(CURDATE(), INTERVAL 3 MONTH) GROUP BY u.user_id, u.user_name HAVING overdue_count 2 ORDER BY overdue_count DESC;这里有几个考点需要说明一是逾期次数的计算要去重——同一张卡的一个账单月可能生成多笔逾期记录所以COUNT的是bill_id而不是某张操作表的流水二是不要写错时间函数MySQL和Oracle的日期函数不同题目如果指定了数据库类型要按对应语法来写三是HAVING和WHERE的区别先过滤再分组还是先分组再过滤SQL的执行顺序必须清楚。还有一道SQL题是统计每种卡级别的消费总额Top 10这就涉及到窗口函数ROW_NUMBER()。2019年的时候很多人对窗口函数还不熟但招行这种银行系统笔试已经考了。这也说明银行的数据库笔试越来越贴近真实生产环境而不只是考个SELECT、JOIN就完事。4.2 ER图设计从用户到账单的核心表结构场景设计题里有一道是让设计“信用卡账单系统”的基础表结构要求至少包含用户、卡片、账单、交易流水四张核心表并标明主外键和索引设计。这题没有标准答案但有几个得分点用户表user_id主键、用户名、证件类型、证件号码、手机号、状态。卡片表card_id主键、user_id外键、卡号唯一索引、卡级别、卡状态、激活时间、额度。账单表bill_id主键、card_id外键、账单周期、账单日、应还金额、最低还款额、还款状态、还款日。交易流水表txn_id主键、card_id外键、交易时间、商户号、金额、交易类型、交易状态。金额字段要用DECIMAL(15,2)而不是float或double卡号字段要加唯一索引交易流水的查询要按card_id 交易时间建联合索引。这些细节只要你平时写过业务系统基本都能想到。但如果你只会刷LeetCode没接触过真实业务表设计这种题就可能写得不完整。我当时还额外写了“分表分库”的考虑交易流水表按卡号哈希分表账单表按月分区。后来想想这部分其实是加分项因为银行系统的数据量天然需要这类设计写上去能够体现你的工程视野。4.3 场景设计题批量发卡与对账最后一道场景题考的是“日终对账”——银行侧的交易流水和清算侧的交易流水不一致时如何排查这题非常贴近实际工作答案也有大概的套路第一先确定对账范围。明确按交易日期、交易渠道、卡号或商户号来圈定需要比对的流水范围。第二逐笔比对关键字段。交易金额、交易状态、手续费、结算币种哪个字段不一致就标记哪个。第三分原因定位。常见情况包括交易成功但回调失败、通道重复回调、金额被手续费拆分、时区/日期边界导致归属日不同。第四跑批对账任务。定时任务拉取双方流水生成差异文件再按差异类型自动或人工处理。这种题没有任何标准答案重点在于你有没有一套清晰的排查思路。我当时把步骤写得很结构化先把“对账范围”→“字段比对”→“差异分类”→“处理流程”列出来再写了一段伪代码描述对账任务的逻辑最后提了一下幂等处理和重试机制。这比单纯写几千字废话要好得多因为面试官很容易看出你有没有实际的对账经验。注意场景题这类主观题答题时一定要“先结构、后细节”。先给结论框架再填充具体的表名、字段名、异常场景。不要一上来就写一堆发散的内容那样反而显得没有条理。5. 三个小时怎么分配才够用我的做题节奏复盘5.1 时间分配的整体思路这场笔试的时间看起来不短但实际做起来非常紧凑。我自己是按“60分钟选择题、80分钟三道编程题、30分钟数据库与场景题、10分钟检查”的节奏来走的。最后实际用掉的时间比预想的多一些因为选择题里有些操作系统和网络的题需要推演导致编程题时间被压缩到70分钟左右。如果让我重新做一次我会把选择题压到50分钟以内。原因是选择题单题分值有限编程题和场景题才是拉分的大头。银行笔试往往是按比例算总分一道选择题错了只是少一分但一道编程题只通过部分测试用例可能直接丢掉一大块分值。所以宁可放弃一两道偏门选择题也一定要给编程题留出充足的调试时间。5.2 做题顺序与取舍策略我的建议是拿到试卷先花3分钟通读一遍所有题目把编程题的具体要求、场景题的背景、选择题的难易程度做一个快速判断。然后先做自己有把握的选择题比如数据结构、Java基础把计算机网络和操作系统里需要计算的题放到稍后。编程题从最简单那题开始做按“热身题→模拟题→业务建模题”的顺序推进。如果中途卡壳超过15分钟果断跳到下一题最后有时间再回来补。这里要提醒一个非常实际的点机考环境里代码可以反复提交但如果你在某道题上耗时太久会导致后面时间不够心态崩掉。我在考场上就遇到一个同学第一题Luhn校验写得很完美但第二题在Comparator上卡了20多分钟最后场景题几乎没写完非常可惜。5.3 不会做时的止损方法如果遇到不会的选择题可以先排除明显错误的选项然后从剩下选项里选一个。不要空着不选也不要犹豫太久。如果是编程题完全没有思路可以写一个暴力解法至少通过部分测试用例拿一点分然后在注释里写明“这里是在数据量较小时采用的暴力方案后续可通过XX算法优化”之类的话——虽然OJ不看你注释但面试官后续捞简历时可能会看到你的答题记录这种注释能体现你的思考过程。场景题如果没时间写完整可以把核心步骤用要点形式列出来第一步、第二步、第三步再补几个关键字段名和表名。这种“半成品”答案比我见过的一些“洋洋洒洒但毫无结构”的答案得分反而更高。说到底银行笔试看的不是文采而是你解决问题的思路是否清晰。经验检查阶段先看编程题的输出的边界条件再看SQL题的表名和字段名是否对上最后才看选择题有没有漏选。不要因为纠结一道题而丢掉整个模块。6. 如果让我重新准备一次备考优先级与踩坑建议6.1 刷题优先级不是刷得越多越好银行IT笔试的算法题整体上不用像互联网大厂那样追求难题偏题。核心刷题范围就是LeetCode Hot 100、剑指Offer、SQLZoo或LeetCode Database题库。重点是字符串处理、排序、HashMap应用、基础DP这几个类型。如果时间有限优先刷“剑指Offer”的简单到中等题再刷一些SQL题就足够覆盖大部分考点了。但这里有个非常容易被忽略的点你需要熟悉在线OJ的输入输出模板。很多人平时刷题用的是IDE里写好的方法签名直接在后台跑测试样例没有真正自己写Scanner解析、BufferedReader读入、System.out输出。考试时突然要自己处理标准输入输出会很不适应。所以备考期间至少要拿出5-10套题在真正的OJ环境里模拟一次把输入输出模板练熟。6.2 金融业务知识不要裸奔如果你准备的是互联网大厂完全不看业务知识没问题。但银行系笔试一定会涉及业务术语比如账单日、还款日、最低还款额、分期手续费、Luhn校验、对账、清算、风控。我当时就因为在编程题里看到了“Luhn”这个词愣了一下还好之前写过一个信用卡校验的小工具才没有在审题上耽误太久。怎么准备不需要深入金融工程但至少要搞清楚信用卡的基本业务流程发卡、激活、消费、入账、账单生成、还款、逾期、风控拦截。这些内容可以看看公开的信用卡产品介绍和支付清算的相关材料。如果连“账单日和还款日有什么区别”都说不清遇到“最优还款计划”这种题就很难抓住关键约束。我当时有个很笨但有效的方法把招行信用卡APP里的还款流程、账单展示逻辑研究了一遍对理解题目非常有帮助。6.3 考前三天我具体做了什么考前三天我没有再刷新题而是做三件事第一把排序算法的稳定性、复杂度、适用场景用表格抄了一遍第二把所有SQL的JOIN类型、窗口函数、GROUP BY的执行顺序整理成笔记第三在OJ上做了两套模拟题严格按2.5小时限时完成。这几件事看着不起眼但在考场上的作用非常大。尤其是限时模拟能帮你提前适应“时间不够用”的紧张感避免考场心态崩塌。另外有一点要提醒笔试前一定检查电脑环境、网络、浏览器兼容性。招行的在线笔试用的是第三方平台偶尔会有浏览器兼容问题一旦进不去考场就很被动。我自己考前就吃过没仔细检查环境配置的亏那次差点因为浏览器插件拦截弹窗而耽误时间。说到底招行信用卡中心这套开发方向笔试题难度上限不高但覆盖面广、业务味重。它考的不是“你会不会奇技淫巧”而是“你作为一个开发工程师能不能在真实的金融业务约束下写出正确、稳定、可维护的代码”。如果你现在正在准备银行IT岗的秋招我的建议是别把时间全砸在偏题怪题上把基础数据结构、SQL、Linux命令、Java并发/JVM这些基本功打扎实再花点时间了解信用卡业务和常见支付场景这套题的通过率会比你想象中高很多。 招行信用卡中心IT笔试全解析：题型考点与时间分配
招行信用卡中心的笔试在银行系IT校招里一直是个比较特别的存在。它不是纯行测也不是纯LeetCode而是把金融业务场景和技术基础揉在一起考。2019秋招开发方向第一批的这套题我印象还挺深——题型结构、考点覆盖、以及几个藏在细节里的坑对后来准备银行科技岗的同学都很有参考价值。这篇文章我就按当时的考场体验把选择题、编程题、SQL场景题这些内容拆开聊一聊重点说说怎么分配时间、怎么避开那些容易丢分的点。1. 银行系IT笔试和互联网大厂的差别比你想的大1.1 为什么专门聊这一场笔试很多准备校招的同学会有个误区觉得笔试就两种一种是刷LeetCode一种是做行测。但招行信用卡中心的开发岗笔试偏偏是第三种——它既有技术基础题又有贴近信用卡业务的场景题还会在编程题里嵌入跟金融业务相关的小逻辑。如果你只按互联网大厂的方式准备会发现在选择题上浪费了大量时间而真正拉分的场景题反而没准备到。我记得2019年秋招这一批整体是线上统一笔试题目分几个大块选择题、编程题、SQL/数据库设计题、以及一部分结合信用卡业务场景的主观题。全部做完大概需要两个半小时到三个小时时间算不上特别充裕尤其编程题如果卡住了后面的场景题就没时间写。所以我对这场考试的评价是它考的不是你会不会写代码而是你在有限时间内能不能把代码和业务理解结合起来输出一份“能干活”而非“能跑通”的答案。1.2 笔试的基本盘形式、时间与题型分布按当时的笔试通知和实际体验大致情况如下表模块题量建议用时考察重心选择题单选多选约30题50-60分钟数据结构、算法、网络、OS、Java基础、数据库理论编程题3题70-80分钟字符串处理、模拟题、动态规划/贪心数据库与场景设计2-3题30-40分钟SQL编写、表结构设计、业务场景处理综合主观题1题左右10-15分钟业务理解、方案设计这里有个小提示不同批次抽到的题型分布可能不完全一样但“开发方向第一批”这套配置基本代表了招行卡中心对开发岗位的技术预期。我当时就是没料到会有业务场景题导致最后一道主观题写得比较仓促这一点后文会细说。提示银行系笔试和互联网大厂笔试最大的区别在于“业务背景”的权重。互联网大厂更多考纯算法和系统设计银行系则喜欢把技术问题放在“账户、交易、风控、对账”这些具体场景里答案不仅要正确还要考虑金融场景的特有约束。2. 选择题不考手撕红黑树但基础考点细得让人出汗2.1 数据结构与算法底层逻辑反复考选择题里数据结构与算法的占比不低但难度确实没到ACM那种级别。考得最多的是栈和队列的性质、二叉树遍历、哈希冲突处理、排序算法的时间复杂度与稳定性。比如有一道题是给一个中缀表达式转后缀表达式问用栈的过程中栈的最大深度是多少还有一道给了一组关键字序列问用快速排序第一趟之后的结果。这些题不难但要求你对基础结论非常熟练不能现场推导。一个容易丢分的点是**“排序稳定性”的判断题**。选择题里可能会同时出现快排、堆排、归并排序、直接插入排序让你选哪些是稳定的、哪些是不稳定的。如果只是背结论很容易混淆。我当时用的是“快选堆希不稳定其余排序都稳定”这个口诀——快排、选择、堆排、希尔是不稳定的归并、插入、冒泡、基数排序是稳定的。这个口诀考试时省了不少时间。2.2 计算机网络与操作系统偏“应用场景”而不是“原理背诵”网络题在这个笔试里不算难但比较偏实际应用。比如问TCP三次握手中第二次握手的标志位是什么HTTP状态码502和504分别代表什么HTTPS握手过程中证书验证发生在哪一步。这些属于“用的时候能想起来”的知识点如果你平时主要靠框架开发没有系统复习过网络基础容易在这些题上丢分。操作系统部分考了进程与线程的区别、死锁产生的四个必要条件、虚拟内存与页面置换。有一道题我记得很清楚给一组页面访问序列问用FIFO和LRU算法分别产生多少次缺页中断。这道题本身不难但需要你按部就班地推演费时间。我当时是先跳过把后面性价比更高的题做完再回头来算的。考场上的时间管理真的很重要一道选择题卡住5分钟以上就说明你分配不合理了。2.3 Java、数据库考点求职者的两大分水岭招行卡中心开发岗以Java技术栈为主所以Java基础考得比较细。考点集中在集合类的底层实现HashMap在JDK 8之后引入了红黑树、JVM内存区域划分、垃圾回收算法、synchronized与ReentrantLock的区别、线程池核心参数。有一道多选题问“哪些情况会导致Full GC”选项涉及老年代空间不足、永久代/元空间不足、CMS GC失败、大对象直接进入老年代等——这道题能筛掉不少只看过八股文但没有深入理解JVM的人。数据库理论部分主要考索引失效场景、事务的ACID、隔离级别与脏读/不可重复读/幻读的对应关系、三范式。有一道题问“RR隔离级别下InnoDB如何解决幻读”答案是MVCC间隙锁。如果你只背了隔离级别定义没接触过InnoDB的锁机制这题就不好猜。这里也能看出银行系统对数据一致性的要求是体现在笔试里的不只是考概念还在考你有没有“金融系统思维”。注意选择题中一般会有2-3道“陌生题”比如偏门Linux命令。遇到完全没见过的题不要恋战按第一直觉选一个然后标记好有时间再回来想。很多同学就是因为在一道Linux题上纠结太久导致后面编程题时间不够。3. 三道编程题看着眼熟AC率却不高3.1 第一题信用卡号Luhn校验——字符串处理不要想复杂编程题第一题通常是热身级别的那道题我印象很深校验一串信用卡号是否合法用的标准是Luhn算法。Luhn算法的规则是从右往左数偶数位上的数字乘以2如果乘积大于9就减9然后把所有数字相加如果结果能被10整除则号码合法。题目的坑不在于Luhn算法本身而在于输入格式。它给的信用卡号可能带空格或短横线要求先过滤掉这些字符再校验。我当时看到题的第一反应是“这不是发卡系统的日常需求吗”然后老老实实写public static boolean isValidCardNumber(String rawCardNumber) { StringBuilder sb new StringBuilder(); for (char c : rawCardNumber.toCharArray()) { if (Character.isDigit(c)) { sb.append(c); } } String cardNumber sb.toString(); if (cardNumber.length() 12 || cardNumber.length() 19) { return false; } int sum 0; boolean doubleDigit false; for (int i cardNumber.length() - 1; i 0; i--) { int digit cardNumber.charAt(i) - 0; if (doubleDigit) { digit * 2; if (digit 9) { digit - 9; } } sum digit; doubleDigit !doubleDigit; } return sum % 10 0; }这道题有几个隐藏的考察点一是你能不能在读题时想到预处理非法字符二是长度校验的边界值。很多同批同学直接按“纯数字串”来做结果有一个测试用例因为带了短横线而失败。所以说编程题不一定多难但一定要仔细看输入描述。3.2 第二题交易流水统计——模拟题考的是边界第二题是一道模拟题大概意思是给一批信用卡交易记录每条记录包含交易时间、交易商户、交易金额、卡号等信息要求按商户统计交易总笔数和总金额并按总金额降序输出如果总金额相同按商户名称字典序升序输出。这道题核心是排序和分组统计用HashMap 自定义排序就能解。但它有三个很现实的坑第一个坑是金额精度。交易金额一般带小数如果用float或double存可能在累加时出现精度丢失导致排序结果错误。正确做法是用BigDecimal或者把金额乘以100转成整数分来存储计算。我在笔试时直接用long存“分”既避开了精度问题又提高了运算速度。第二个坑是Comparator的写法。金额降序、名称升序这个需求在Java 8里可以用lambda实现但要注意Comparator的连写顺序list.sort(Comparator .comparingLong(StatItem::getTotalAmountInCents) .reversed() .thenComparing(StatItem::getMerchantName));第三个坑是日期与时间格式化。题目要求按“yyyy-MM-dd HH:mm:ss”格式输出或解析时间如果直接用String.substring()切分很容易因为空格或前导零导致解析错误。我当时直接用了LocalDateTime.parse配合DateTimeFormatter虽然代码多几行但安全很多。这道题给我的感觉就是银行里很常见的“报表统计需求”没什么算法难度但边界和精度意识决定了你是AC还是WA。如果你平时写代码不注意输入输出格式和数值类型这种题反而最容易翻车。3.3 第三题最优还款计划——DP还是贪心要想清楚第三题开始有区分度了。题目背景是一张信用卡有账单周期账单日之后有一个还款日你手头有一笔钱可以提前还款也可以放在活期账户赚一点点利息问在还款日之前如何安排还款金额使总收益最大。本质上是一个类背包问题但它把业务背景包装得非常“信用卡”。我当时第一反应是贪心利息高的期数先还每期尽量多还。但写着写着发现不对因为题目里每期账单的金额不同、利率也不同而且“多还的部分不会产生额外收益”所以需要按利率从高到低排序逐期决策。这个思路其实是“贪心排序”并不是真正的动态规划。而如果你把它当成完全背包做复杂度会爆炸而且容易写错。更稳妥的思路是这样的先把所有分期按年化利率降序排列然后逐期判断“当前可用资金够不够还这一期”。如果够就还完这一期剩余资金继续处理下一期如果不够就把剩余资金全部还进去结束。这道题的目的不是让你设计多么复杂的金融产品而是考察在业务约束下你能不能识别出正确的算法模型。识别错了代码写得再漂亮也没用。这道题给我的启发是银行系笔试题的算法难度整体低于互联网大厂但它们更看重你“从业务描述中抽象模型”的能力。如果你看到“信用卡”三个字就慌或者看到“最优”就条件反射写DP反而容易掉进陷阱。3.4 编程题真正的坑IO、复杂度和审题编程题的整体难度确实比互联网大厂低一档但AC率不高主要原因集中在三个方面第一输入输出格式。银行笔试的在线OJ通常用标准输入输出但有些同学平时在IDE里写习惯了没有亲自处理过多行输入导致Scanner的nextLine和nextInt混用时出现换行符残留的问题。我当时处理方法是整行读取再解析避免混用。比如BufferedReader reader new BufferedReader(new InputStreamReader(System.in)); int n Integer.parseInt(reader.readLine()); for (int i 0; i n; i) { String[] parts reader.readLine().split( ); // 按需解析 }第二时间复杂度。选择题里考复杂度编程题里也有人中了复杂度陷阱。比如交易流水统计那题如果直接用双重循环比较所有商户数据量大时可能超时。正确做法是先用HashMap聚合再排序复杂度从O(n^2)降到O(n log n)。这个考点很基础但在机考压力下很多人第一反应就是“先暴力写出来再说”结果拿不到满分。第三审题不清。第三题“最优还款计划”里有一个不显眼的约束手头资金不能拆分到某一期的部分还款之外也就是说每一期要么按给出的金额还要么不还。如果不仔细读题很容易把简单问题复杂化。这也是我在考场上差点踩的坑。经验做完编程题后一定要留5分钟检查一下数据类型和算法复杂度。银行笔试OJ的测试用例通常比较全边界情况空字符串、超大数、负金额都是故意埋好的雷。宁可少写一道附加题也要保证已写题目的边界处理正确。4. 数据库与场景设计题贴着信用卡业务出题是最大特色4.1 经典SQL题逾期用户与消费排行这套笔试的数据库题算是整场考试里“银行味”最浓的部分。有一道题是给定用户表、信用卡表、账单表、还款记录表要求统计出最近三个月内逾期次数超过2次的用户并按逾期次数降序输出。这道题考察的是多表关联、分组聚合、子查询/窗口函数。我当时用的是多表JOIN GROUP BY HAVING的方式SELECT u.user_id, u.user_name, COUNT(DISTINCT b.bill_id) AS overdue_count FROM user_info u JOIN credit_card c ON u.user_id c.user_id JOIN bill_info b ON c.card_id b.card_id WHERE b.due_date CURDATE() AND b.paid_flag 0 AND b.bill_date DATE_SUB(CURDATE(), INTERVAL 3 MONTH) GROUP BY u.user_id, u.user_name HAVING overdue_count 2 ORDER BY overdue_count DESC;这里有几个考点需要说明一是逾期次数的计算要去重——同一张卡的一个账单月可能生成多笔逾期记录所以COUNT的是bill_id而不是某张操作表的流水二是不要写错时间函数MySQL和Oracle的日期函数不同题目如果指定了数据库类型要按对应语法来写三是HAVING和WHERE的区别先过滤再分组还是先分组再过滤SQL的执行顺序必须清楚。还有一道SQL题是统计每种卡级别的消费总额Top 10这就涉及到窗口函数ROW_NUMBER()。2019年的时候很多人对窗口函数还不熟但招行这种银行系统笔试已经考了。这也说明银行的数据库笔试越来越贴近真实生产环境而不只是考个SELECT、JOIN就完事。4.2 ER图设计从用户到账单的核心表结构场景设计题里有一道是让设计“信用卡账单系统”的基础表结构要求至少包含用户、卡片、账单、交易流水四张核心表并标明主外键和索引设计。这题没有标准答案但有几个得分点用户表user_id主键、用户名、证件类型、证件号码、手机号、状态。卡片表card_id主键、user_id外键、卡号唯一索引、卡级别、卡状态、激活时间、额度。账单表bill_id主键、card_id外键、账单周期、账单日、应还金额、最低还款额、还款状态、还款日。交易流水表txn_id主键、card_id外键、交易时间、商户号、金额、交易类型、交易状态。金额字段要用DECIMAL(15,2)而不是float或double卡号字段要加唯一索引交易流水的查询要按card_id 交易时间建联合索引。这些细节只要你平时写过业务系统基本都能想到。但如果你只会刷LeetCode没接触过真实业务表设计这种题就可能写得不完整。我当时还额外写了“分表分库”的考虑交易流水表按卡号哈希分表账单表按月分区。后来想想这部分其实是加分项因为银行系统的数据量天然需要这类设计写上去能够体现你的工程视野。4.3 场景设计题批量发卡与对账最后一道场景题考的是“日终对账”——银行侧的交易流水和清算侧的交易流水不一致时如何排查这题非常贴近实际工作答案也有大概的套路第一先确定对账范围。明确按交易日期、交易渠道、卡号或商户号来圈定需要比对的流水范围。第二逐笔比对关键字段。交易金额、交易状态、手续费、结算币种哪个字段不一致就标记哪个。第三分原因定位。常见情况包括交易成功但回调失败、通道重复回调、金额被手续费拆分、时区/日期边界导致归属日不同。第四跑批对账任务。定时任务拉取双方流水生成差异文件再按差异类型自动或人工处理。这种题没有任何标准答案重点在于你有没有一套清晰的排查思路。我当时把步骤写得很结构化先把“对账范围”→“字段比对”→“差异分类”→“处理流程”列出来再写了一段伪代码描述对账任务的逻辑最后提了一下幂等处理和重试机制。这比单纯写几千字废话要好得多因为面试官很容易看出你有没有实际的对账经验。注意场景题这类主观题答题时一定要“先结构、后细节”。先给结论框架再填充具体的表名、字段名、异常场景。不要一上来就写一堆发散的内容那样反而显得没有条理。5. 三个小时怎么分配才够用我的做题节奏复盘5.1 时间分配的整体思路这场笔试的时间看起来不短但实际做起来非常紧凑。我自己是按“60分钟选择题、80分钟三道编程题、30分钟数据库与场景题、10分钟检查”的节奏来走的。最后实际用掉的时间比预想的多一些因为选择题里有些操作系统和网络的题需要推演导致编程题时间被压缩到70分钟左右。如果让我重新做一次我会把选择题压到50分钟以内。原因是选择题单题分值有限编程题和场景题才是拉分的大头。银行笔试往往是按比例算总分一道选择题错了只是少一分但一道编程题只通过部分测试用例可能直接丢掉一大块分值。所以宁可放弃一两道偏门选择题也一定要给编程题留出充足的调试时间。5.2 做题顺序与取舍策略我的建议是拿到试卷先花3分钟通读一遍所有题目把编程题的具体要求、场景题的背景、选择题的难易程度做一个快速判断。然后先做自己有把握的选择题比如数据结构、Java基础把计算机网络和操作系统里需要计算的题放到稍后。编程题从最简单那题开始做按“热身题→模拟题→业务建模题”的顺序推进。如果中途卡壳超过15分钟果断跳到下一题最后有时间再回来补。这里要提醒一个非常实际的点机考环境里代码可以反复提交但如果你在某道题上耗时太久会导致后面时间不够心态崩掉。我在考场上就遇到一个同学第一题Luhn校验写得很完美但第二题在Comparator上卡了20多分钟最后场景题几乎没写完非常可惜。5.3 不会做时的止损方法如果遇到不会的选择题可以先排除明显错误的选项然后从剩下选项里选一个。不要空着不选也不要犹豫太久。如果是编程题完全没有思路可以写一个暴力解法至少通过部分测试用例拿一点分然后在注释里写明“这里是在数据量较小时采用的暴力方案后续可通过XX算法优化”之类的话——虽然OJ不看你注释但面试官后续捞简历时可能会看到你的答题记录这种注释能体现你的思考过程。场景题如果没时间写完整可以把核心步骤用要点形式列出来第一步、第二步、第三步再补几个关键字段名和表名。这种“半成品”答案比我见过的一些“洋洋洒洒但毫无结构”的答案得分反而更高。说到底银行笔试看的不是文采而是你解决问题的思路是否清晰。经验检查阶段先看编程题的输出的边界条件再看SQL题的表名和字段名是否对上最后才看选择题有没有漏选。不要因为纠结一道题而丢掉整个模块。6. 如果让我重新准备一次备考优先级与踩坑建议6.1 刷题优先级不是刷得越多越好银行IT笔试的算法题整体上不用像互联网大厂那样追求难题偏题。核心刷题范围就是LeetCode Hot 100、剑指Offer、SQLZoo或LeetCode Database题库。重点是字符串处理、排序、HashMap应用、基础DP这几个类型。如果时间有限优先刷“剑指Offer”的简单到中等题再刷一些SQL题就足够覆盖大部分考点了。但这里有个非常容易被忽略的点你需要熟悉在线OJ的输入输出模板。很多人平时刷题用的是IDE里写好的方法签名直接在后台跑测试样例没有真正自己写Scanner解析、BufferedReader读入、System.out输出。考试时突然要自己处理标准输入输出会很不适应。所以备考期间至少要拿出5-10套题在真正的OJ环境里模拟一次把输入输出模板练熟。6.2 金融业务知识不要裸奔如果你准备的是互联网大厂完全不看业务知识没问题。但银行系笔试一定会涉及业务术语比如账单日、还款日、最低还款额、分期手续费、Luhn校验、对账、清算、风控。我当时就因为在编程题里看到了“Luhn”这个词愣了一下还好之前写过一个信用卡校验的小工具才没有在审题上耽误太久。怎么准备不需要深入金融工程但至少要搞清楚信用卡的基本业务流程发卡、激活、消费、入账、账单生成、还款、逾期、风控拦截。这些内容可以看看公开的信用卡产品介绍和支付清算的相关材料。如果连“账单日和还款日有什么区别”都说不清遇到“最优还款计划”这种题就很难抓住关键约束。我当时有个很笨但有效的方法把招行信用卡APP里的还款流程、账单展示逻辑研究了一遍对理解题目非常有帮助。6.3 考前三天我具体做了什么考前三天我没有再刷新题而是做三件事第一把排序算法的稳定性、复杂度、适用场景用表格抄了一遍第二把所有SQL的JOIN类型、窗口函数、GROUP BY的执行顺序整理成笔记第三在OJ上做了两套模拟题严格按2.5小时限时完成。这几件事看着不起眼但在考场上的作用非常大。尤其是限时模拟能帮你提前适应“时间不够用”的紧张感避免考场心态崩塌。另外有一点要提醒笔试前一定检查电脑环境、网络、浏览器兼容性。招行的在线笔试用的是第三方平台偶尔会有浏览器兼容问题一旦进不去考场就很被动。我自己考前就吃过没仔细检查环境配置的亏那次差点因为浏览器插件拦截弹窗而耽误时间。说到底招行信用卡中心这套开发方向笔试题难度上限不高但覆盖面广、业务味重。它考的不是“你会不会奇技淫巧”而是“你作为一个开发工程师能不能在真实的金融业务约束下写出正确、稳定、可维护的代码”。如果你现在正在准备银行IT岗的秋招我的建议是别把时间全砸在偏题怪题上把基础数据结构、SQL、Linux命令、Java并发/JVM这些基本功打扎实再花点时间了解信用卡业务和常见支付场景这套题的通过率会比你想象中高很多。