招行信用卡中心IT笔试全复盘：行测、技术单选与编程题备考指南-编程实验室

1. 这批笔试的整体结构：行测、技术单选、编程题三段的真实时间分配

招行信用卡中心的IT笔试有个特点：它不是纯粹的算法竞赛，而是按“银行校招综合笔试+专业技术笔试”的复合模式设计。2019秋招开发方向第三批在赛码网平台上进行，整场考试时长约两小时，题量不算小，但真正能拉开差距的其实只有少数几个模块。

我参加的那场，整体分三大段：第一段是行测类题目，包括言语理解、数字推理、图形推理和图表分析，大概40题左右，限时40分钟上下；第二段是技术类单选题，范围覆盖数据结构、操作系统、计算机网络、数据库、Java/C++基础，大约30题；第三段是编程题，两道，分别对应算法和业务场景模拟。最后的性格测试不计入成绩，但也不能乱填，这个后面细说。

这里有一个特别容易被忽视的点：行测部分虽然不计入技术分，但它直接影响你是否能进入面试。银行类笔试普遍是“总分门槛”逻辑，有些技术题做的还可以的同学，反而挂在行测上，因为时间没分配好，导致后面技术题仓促作答。赛码网是倒计时一题一题切换的，不像线下纸质试卷可以来回翻阅，每一段的剩余时间会被独立卡死，这一点和互联网大厂笔试的体验差异很大。

我建议的策略是：行测段不要恋战，数字推理和图形推理每道题控制在60到90秒内，拿不准就蒙一个，把时间留给后面的图表分析。这部分其实更像公务员行测的简化版，难度比真正的国考低，但题干表述很绕，考前如果不熟悉题型，会浪费大量阅读时间。我身边确实有人在这段花了将近25分钟，结果后面技术单选只剩下十几分钟，心态直接崩了。

再说一下平台层面的东西。赛码网笔试要求打开摄像头，中途切屏超过一定次数会被标记，甚至强制交卷。我当时用的是本地IDE写代码再粘回去，但赛码网的编辑器是没有自动缩进和智能提示的，所以平时就得适应“裸写代码”的状态。这事看着小，实际影响很大——很多人习惯了IDE的补全，一到在线编辑器连import都写不利索。

2. 行测与性格测试：银行IT笔试里最容易被低估的“隐形关卡”

很多人会想：我是投开发岗的，为什么要做行测？招行信用卡中心的逻辑其实很简单——银行体系内的IT岗位不只是写代码，未来要跟业务部门、运营部门、风控部门长期协作，逻辑思维、语言理解、数据分析能力是基础素养。所以行测本质上是“通用素质筛选”，不是故意刁难技术岗。

2.1 言语理解与表达：病句、排序、主旨概括

这部分题量在10题左右，难度并不高，但它有一个陷阱：题干全是金融、银行业务背景的语料，比如“信用卡分期业务中，以下哪项表述没有歧义”，这类题目的干扰项往往就差在一两个关联词、指代词上。复习方式不用刻意，做几套银行校招行测真题找找语感就行。我当时在备考阶段刷过几套银行笔试真题合集，发现言语理解和国考言语的考点高度重合，只是材料换成金融场景，所以市面上行测通用教材完全够用。

2.2 数字推理与数学运算：等差数列、递推、组合数字

数字推理是银行笔试的常客，考的规律比较固定。常见的有：多级差数列（相邻两项差构成等差数列）、倍数递推（前一项乘一个系数再加减常数）、幂次数列（底数或指数本身成规律）、三项递推（前两项之和/差等于第三项）、数位拆分（把数字拆成各位再找规律）。

举个例子，考场上出现过一组：

1, 2, 6, 24, 120, (?)

一眼就能看出是阶乘数列：1!、2!、3!、4!、5!，下一项就是6!=720。但银行笔试不会每题都这么直白，更可能的是把它包装成：

2, 3, 8, 27, 112, (?)

这个数列的规律是：2×1+1=3，3×2+2=8，8×3+3=27，27×4+4=112，所以下一项是112×5+5=565。这种“乘递增系数再加递增常数”的题型，在银行行测里出现频率极高，考前建议专门练一轮。

数学运算题则偏向行程问题、工程问题、利润问题、排列组合等。招行这批题里有一道印象比较深：某银行网点有3个窗口，平均每分钟到达1.5人，每个窗口每分钟服务1人，求稳态下的平均排队长度。这实际上是一个M/M/3排队论模型，直接用银行考试常用的排队公式算，不需要深入推导，但你需要知道公式里每个参数代表什么。

2.3 图形推理：位置、旋转、去同存异

图形推理大概8题，规律集中在：旋转方向与角度、翻转、图形叠加去同存异/去异存同、封闭空间数量、对称轴数量与方向、一笔画。其中“一笔画”是近几年的高频考点，判断方法很简单——奇点数量为0或2的连通图就能一笔画。银行笔试图形题不会像公务员考试那么刁钻，但胜在“题量大、时间紧”，如果考前没见过典型规律，现场很容易懵。我的做法是：把常见图形规律列了一张表格贴在自己电脑前，每次模拟测试后对照一次，几轮下来就形成条件反射了。

2.4 性格测试：一致性是硬指标

性格测试不计入总分，但会做“测谎”判断。系统会把意思相近的题目打散分布在多个位置，如果你前后回答矛盾过多，报告会显示“作答可信度低”，这可能直接导致简历进入灰名单。做这块没有技巧，就一条原则：按真实想法作答，不要刻意去“演”一个企业喜欢的人。因为银行性格测试的题量通常有100到200道，伪装完全一致几乎不可能，还不如保持稳定。

3. 计算机基础选择题：数据结构、操作系统、计网、数据库的考点还原

技术单选题是这批笔试里最有含金量的部分。先说整体感受：知识面比字节、腾讯、阿里这类互联网大厂的笔试题更宽，但单题难度略低，不考特别偏门的内核源码，更重基础原理与工程常识。30道题里，数据结构与算法约占10道，操作系统与计算机网络约10道，数据库约6道，Java/C++基础约4道，整体配比相当标准。

3.1 数据结构：树的遍历与哈希是绝对核心

数据结构的选择题，考来考去绕不开几个经典方向：二叉树的前中后序遍历（尤其是非递归实现）、平衡二叉树调整、堆的插入与删除、哈希冲突处理、KMP算法中next数组的计算。我记得有一道题是：给定一个完全二叉树的数组存储，问第7个节点的父节点下标是多少。这个考的就是“堆的父亲节点下标公式”：下标为i的节点，其父节点下标为(i-1)/2。答案是3。如果你在LeetCode上刷过数组建堆相关题目，这种题基本是送分。

哈希冲突的处理方式也是重点。开放定址法和链地址法都会考，命题形式通常是“某哈希表采用除留余数法，表中已有若干元素，问插入新元素时被比较的次数”。这里容易踩的坑是：计算“比较次数”时，不要忽略最初的一次“空位判断”。比如探测序列经过3个位置才找到空位，比较次数往往是5而不是3，因为每个被占用的位置都发生了一次关键字比较。这类细节笔试里最容易失分。

3.2 操作系统：死锁、PV操作、页面置换

操作系统考得不深，但范围广。进程与线程的区别是必考的，围绕“资源共享”“切换开销”“地址空间”三个角度出选项。死锁部分考了四个必要条件：互斥、持有并等待、不可剥夺、循环等待。我记得有一道题是问“破坏死锁哪一个条件可以防止哲学家就餐问题中的死锁”，答案是可以破坏“循环等待”——比如让哲学家按序号顺序拿筷子。

PV操作和生产者消费者问题，银行笔试也考，但考得很“模板”。常见的题型是：生产者进程每次执行V(S)操作后S的值变化，或者给定一组P/V操作求输出顺序。这类题你需要清楚P操作是申请资源、S减一，V操作是释放资源、S加一，当S小于0时其绝对值等于等待队列中的进程数。把这几条性质背下来，再结合一道经典题练手，基本就够应付了。

页面置换算法考了LRU。题目给一个页面访问序列和一个容量为3的物理块，问使用LRU页面置换算法时缺页次数。LRU的核心是“淘汰最久未使用的页面”，所以你只需要维护一个访问顺序队列，每次访问一个页面时把该页面从原位置挪到队尾，缺页时淘汰队首。考前我建议把OPT、FIFO、LRU、Clock这四种算法各手动走一遍流程，笔试如果碰到基本稳拿分。

3.3 计算机网络：三次握手与HTTP状态码

计算机网络是很多非科班同学的重灾区，但银行笔试考得其实很有规律。三次握手的核心考点是状态变化：客户端从CLOSED进入SYN_SENT，服务器从LISTEN进入SYN_RCVD，最后客户端收到SYN+ACK后进入ESTABLISHED，服务器收到ACK后也进入ESTABLISHED。经常考的一道变体是“如果第二次握手失败，客户端和服务器分别处于什么状态”，答案是客户端SYN_SENT、服务器LISTEN。因为第一次握手后服务器还在等待客户端确认，客户端则继续等待服务器响应。

HTTP状态码也是高频考点。200、301/302、403、404、500、502、503这几个必须分清。其中最容易混淆的是301（永久重定向）和302（临时重定向），以及500（服务器内部错误）和503（服务不可用）。笔试的考法通常是给一个场景，比如“某API接口被永久迁移到新地址，客户端收到什么状态码”，答案是301。计算机网络这块建议不要只看理论，最好配合抓包工具或者浏览器开发者工具实际观察几次，印象会深得多。

3.4 数据库：B+树索引、事务隔离级别、SQL查询

数据库题量约6道，核心集中在三个点：索引结构为什么用B+树、事务隔离级别解决的问题、SQL语句的运行结果。

B+树的部分，考点是“为什么数据库索引不用红黑树或哈希索引”。标准答法是：B+树非叶子节点不存数据，单节点能存储更多键值，树高更低，磁盘IO次数更少；且叶子节点之间通过指针相连，范围查询友好。哈希索引虽然单点查询O(1)，但不支持范围查询和排序，所以不被MySQL InnoDB作为默认索引。

事务隔离级别也是必考，四个级别要记得非常清楚：读未提交（会产生脏读）、读已提交（解决脏读，但可能不可重复读）、可重复读（解决不可重复读，但可能幻读）、串行化（解决所有问题但并发性能最差）。MySQL InnoDB默认是REPEATABLE READ，这点笔试里经常拿来当选项坑。

SQL题一般有两种考法：一种是给你几个表和一段SQL，要求判断查询结果的行数；另一种是给场景选正确的SQL语句。前者比较阴险，因为你要同时考虑JOIN的笛卡尔积和WHERE条件过滤。后者相对简单，掌握GROUP BY与HAVING、LEFT JOIN与INNER JOIN的区别基本就够。我在备考时专门练过LeetCode的数据库板块，题目不多，但每一道都对理解JOIN语义很有帮助。

4. Java/C++与SQL实操题：开发方向考生真正的分水岭

第三批笔试的岗位方向是“开发”，Java和C++语言基础都有涉及，但整体偏向Java。原因是招行信用卡中心的后端技术栈以Java为主，分布式框架用Dubbo、Spring Cloud比较多，所以笔试考Java更符合岗位需要。C++题量不大，一般集中在指针、虚函数、智能指针、STL容器这几个点。

4.1 Java核心考点：HashMap、JVM、多线程

Java部分的单选题，HashMap的底层原理是出场率最高的考点。2019年这个时候考的还是JDK 8的实现：底层是数组加链表加红黑树，链表长度超过8且数组长度大于64时转红黑树。虽然这批笔试题可能不会考那么深，但“HashMap的put流程”属于安全牌，基本每次考试都有一题，建议能完整描述：

通过key的hashCode计算哈希值，进一步扰动处理得到桶下标；
如果桶为空，直接创建新节点；
如果桶非空，判断第一个节点是否与待插入key相同，相同则覆盖；
如果桶是红黑树节点，走红黑树的插入逻辑；
如果是链表节点，遍历链表找相同key，不存在则在尾部插入新节点（JDK 8尾插法）;
插入后判断链表长度是否达到8且数组长度是否达到64，条件满足则树化；
如果节点总数超过阈值（容量×负载因子0.75），触发扩容。

JVM方面，考察点主要是内存区域划分、GC回收机制和类加载过程。“哪些区域是线程共享的”这道题经常出现——堆和方法区线程共享，虚拟机栈、本地方法栈、程序计数器是线程私有的。类加载过程考“双亲委派模型”，问的典型问题是“自定义类加载器的父加载器是谁”，答案是AppClassLoader，因为启动类加载器用null表示。

多线程方面，synchronized与ReentrantLock的区别是几乎年年考的题。synchronized是JVM层面实现，自动释放锁；ReentrantLock是JDK层面实现，需要手动lock和unlock。加上wait/notify与await/signal、可中断、公平锁这些对比点，总共能列出五六组差异。银行笔试不会问特别刁钻的并发问题，但线程池的七大参数是必须背的：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。

4.2 C++核心考点：指针引用、虚函数、智能指针

如果你用的是C++，考试范围相对收敛。指针和引用的区别是必考题：引用必须初始化、不可更改绑定对象、不能为null；指针可以重新赋值、可以为null。虚函数的考点是“为什么析构函数要声明为虚函数”——因为当基类指针指向派生类对象时，如果析构函数不是虚函数，delete基类指针只会调用基类析构，派生类资源无法释放，造成内存泄漏。智能指针部分，unique_ptr独占所有权、shared_ptr共享所有权、weak_ptr解决循环引用，这三个必须分清。

4.3 SQL实操：一个多表统计的完整还原

第三批笔试里SQL题不是单纯的选择题，而是要求在代码编辑器里手写SQL。题目大致是这样：有三张表——

用户表users：id、name、reg_date
订单表orders：id、user_id、amount、order_date
商品表products：id、order_id、name、price

要求统计“2019年8月注册、且在2019年9月产生过订单、订单总金额大于500元的用户数量”。

我当时写的答案是：

SELECT COUNT(DISTINCT u.id) FROM users u JOIN orders o ON u.id = o.user_id WHERE u.reg_date BETWEEN '2019-08-01' AND '2019-08-31' AND o.order_date BETWEEN '2019-09-01' AND '2019-09-30' GROUP BY u.id HAVING SUM(o.amount) > 500;

但这里有个坑：如果GROUP BY u.id后再COUNT(DISTINCT u.id)，每一组只返回一行，COUNT外面套DISTINCT没有意义。更稳妥的写法是先查出符合条件的用户id集合，再统计数量：

SELECT COUNT(*) FROM ( SELECT u.id FROM users u JOIN orders o ON u.id = o.user_id WHERE u.reg_date BETWEEN '2019-08-01' AND '2019-08-31' AND o.order_date BETWEEN '2019-09-01' AND '2019-09-30' GROUP BY u.id HAVING SUM(o.amount) > 500 ) t;

这类题考察的核心是：多表JOIN的关联条件、时间范围的边界处理、GROUP BY与HAVING的配合、子查询的使用。银行笔试的SQL题一般就是这种程度，不会要求你写窗口函数或复杂递归查询，但基础语法必须非常熟练，因为在线编辑器没有提示。

5. 编程题复盘：账单连续消费天数与积分兑换方案数的完整解法

第三批的编程题一共两道，难度为LeetCode中等偏低，但题干都包了一层银行业务的外衣。它们共同的特点在于：输入输出格式要求严格，边界条件会卡人，且必须自己处理多组输入。这里我把两道题完整复盘一遍，包括读题、思路和最终代码。

5.1 第一题：最长连续消费天数

题目大致描述：给定一个整数数组，数组元素代表某信用卡用户在一个账单周期内每天的消费金额，0表示当天没有消费。要求返回该周期内连续消费（金额大于0）的最长天数。

例如输入：

[1200, 0, 800, 3000, 0, 0, 6500, 200]

连续消费的天数为2（第3到第4天）和2（第7到第8天），所以答案是2。

这道题本质上就是“最大连续非零子数组长度”，是一个一次遍历的贪心问题。思路非常直接：用两个变量current和maxLen，current统计当前连续非零天数，遇到0时清零，遇到非0时加一并更新maxLen。

参考代码（Java实现）：

import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); String line = sc.nextLine(); String[] parts = line.substring(1, line.length() - 1).split(","); int current = 0; int maxLen = 0; for (String part : parts) { int amount = Integer.parseInt(part.trim()); if (amount > 0) { current++; if (current > maxLen) { maxLen = current; } } else { current = 0; } } System.out.println(maxLen); } }

这里要注意几个边界：

数组元素全为0时，结果是0不是1；
输入字符串可能带前后方括号，解析时要去掉；
连续消费的定义是金额大于0，不是金额大于等于0，所以负数如果出现也要当作非消费处理（虽然业务场景里消费金额不会为负，但题目没说不存在异常数据）。

这道题实际得分率并不像看起来那么高，原因就是很多人在输入解析上翻了车。赛码网的和牛客网风格不同，输入样例有方括号和逗号，如果直接按空格分隔读取，第一行就解析失败，后面的代码全废。所以对于这种平台，我养成了一个习惯：先写一个简单的输入打印代码，把输入原样打印出来看格式，再写真正的逻辑。

5.2 第二题：积分兑换方案数

第二题是动态规划，题目大意：某信用卡中心提供n种积分兑换礼品，第i种礼品需要cost[i]积分且每种礼品可以兑换任意次（或只能用一次，赛码网这题是任意次），给定用户的总积分total，问有多少种不同的兑换方案（顺序不同算同一种方案）。

输入：

cost = [3, 5, 7] total = 10

兑换方案有：

所以输出2。

这是一个完全背包的组合数问题。如果顺序不同算不同方案，那么递推公式是dp[j] = dp[j] + dp[j - cost[i]]，但遍历顺序必须外层循环礼品、内层循环积分容量；如果顺序不同算同一种方案，才需要用这种外层物品内层容量的写法。如果反过来（外层容量内层物品），得到的是排列数。

参考代码（Java实现）：

import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); String costLine = sc.nextLine(); int total = Integer.parseInt(sc.nextLine()); String[] parts = costLine.split("=")[1].replace("[", "").replace("]", "").split(","); int[] cost = new int[parts.length]; for (int i = 0; i < parts.length; i++) { cost[i] = Integer.parseInt(parts[i].trim()); } int[] dp = new int[total + 1]; dp[0] = 1; for (int c : cost) { for (int j = c; j <= total; j++) { dp[j] += dp[j - c]; } } System.out.println(dp[total]); } }

解释一下动态规划的思路：dp[j]表示消耗j积分时的方案数。dp[0]=1表示什么都不兑换也是一种方案。外层循环“每种礼品”，保证每种礼品只被放入一次组合中，不会出现“先换3后换5”和“先换5后换3”被重复计算的情况。内层循环从c到total，因为完全背包允许每种礼品无限次使用，所以需要正向遍历。

这道题还有一个隐藏的进阶考点：如果total非常大（比如10^9），二维DP会内存溢出，需要用“矩阵快速幂”或“生成函数”优化。但笔试阶段total一般控制在10^4以内，标准DP就能过，大家不用慌。不过考场时间充裕的话，可以在最后加一行注释说明“当total较大时可使用矩阵快速幂优化”，给面试官留个好印象。

两道题的综合难度其实并不高，但有一个共同特点：题干描述非常长，有时候光读题就要花两分钟。我的建议是：遇到长题干的编程题先跳读，看输入输出样例，再回过去确认题目要求。很多同学栽在“读题不仔细”上，比如第一题把“金额大于0”看成“金额大于等于0”，第二题把“任意次”看成“一次”，全是这类低级错误。

6. 金融科技场景题：为什么招行卡中心会考“对账”和“幂等”

第三批笔试还有一道问答题（或称为场景设计题），这类题在互联网大厂笔试里几乎不会出现，但在银行IT笔试里却非常常见，因为它考察的是“你能不能理解银行系统的核心约束”。

还原一下考场上的题目大意：在一个信用卡还款系统中，用户发起还款请求后，系统需要同时更新账户余额和还款流水表。如果在更新余额成功后、写流水表之前进程突然崩溃，下一次查询时用户会看到已经扣款但无流水记录，从而引发争议。请设计一个方案解决该类问题，并说明如何避免重复还款。

这道题其实考了两个金融系统里的核心概念：事务一致性和幂等性。

第一个问题“余额已扣但流水缺失”，标准的解法是引入本地事务，用数据库的ACID来保证“扣余额”和“写流水”要么同时成功，要么同时失败。如果系统是分布式架构，账务系统和流水系统拆分成两个服务，则需要采用分布式事务的方案，常见的有两阶段提交（2PC）、可靠消息最终一致性、TCC（Try-Confirm-Cancel）。银行核心账务系统对强一致性要求极高，通常不会接受“最终一致”，所以2PC或TCC是更可能的答案。

第二个问题“避免重复还款”，核心是设计一个幂等机制。最简单的方案是：在还款请求中增加一个唯一业务流水号（如请求方生成的requestId），在处理请求前先查询该requestId是否已处理过，已处理过的直接返回上一次结果。更稳妥的方式是在数据库中为trans_id建立唯一索引，利用数据库的唯一约束作为最终防线，防止并发场景下两次请求同时插入重复流水。

这类题目没有标准答案，但采分点非常明确：必须提到“事务”“唯一索引”“幂等”“分布式一致性”这些关键词，且能讲清楚自己的设计流程。我当时是用三段式回答的：先分析问题根因，再给出方案设计，最后说明方案的优缺点。面试官更看重的是你面对银行这类极端重视数据一致性的业务场景时，能不能建立起“不允许出错”的工程意识。

要备考这类题目，不建议刷LeetCode，更有效的方式是了解常见的金融系统设计问题，包括：支付系统如何保证幂等、积分系统如何防止超发、账务系统如何日终对账、风控系统如何做实时拦截。每个问题能说清楚“是什么、为什么、怎么做”就足够应付笔试了。

7. 复盘后的备考建议：按基础分层准备与赛码网实操避坑

考完之后我花了几天时间做了一次系统复盘，也问了几个一起参加笔试的同学。综合来看，招行信用卡中心的IT笔试（开发方向）难度处于“银行类中上、互联网类中下”的位置，但它的考察结构决定了备考方式不能照搬互联网大厂。

7.1 分层备考策略

基础偏薄的同学（数据结构课刚学完、刷题量低于50道）：

主攻方向：数据结构（二叉树、哈希表、堆）、Java集合框架（HashMap、ArrayList）、SQL基础语法。
每日计划：LeetCode简单题2道+中等题1道，优先做数组、字符串、链表、二叉树这四个专题；SQL每天练习3道题，重点是JOIN和GROUP BY；行测不需要专门买书，考前一周每天刷一套银行行测真题即可。
目标设定：编程题至少AC一题，另一题写出核心思路并尽量通过部分测试用例。银行笔试是按用例给分的，不是“非AC即零分”，所以即使不能完全跑通，也要把框架写对。

有一定基础的同学（刷题量100道以上，熟悉Java/Spring）：

主攻方向：JVM内存模型、多线程并发、B+树索引原理、事务隔离级别、分布式事务与幂等方案。
每日计划：LeetCode中等题2道，兼顾动态规划和模拟题；每个周末做一套银行IT笔试真题并认真复盘错题；重点练习赛码网/牛客网的在线编程输入输出解析。
目标设定：编程题两题AC，技术单选正确率80%以上，行测控制在“不拉分”的水平。

7.2 赛码网实操避坑清单

赛码网是银行类笔试常用的平台，和牛客网有些差异，操作层面的坑我整理一下：

每道编程题只有一个输入输出测试页，不会自动保存代码，中途断网可能导致已写代码丢失，所以有时间就点一下保存草稿；
输入可能包含多组样例，有些题要求一直读到EOF，有些则是第一行给组数，注意区分；
赛码网对Java的时间限制更紧（有时候同样复杂度C++能过Java过不了），所以尽量避免使用Scanner逐行读大量数据，改用BufferedReader；
代码高亮和括号匹配功能很弱，甚至没有，平时就要养成正确缩进的写码习惯；
部分题目实测环境是JDK 8，不支持var等JDK 10+语法，写代码时尽量用兼容性更好的写法；
行测段切到技术段时，有一个确认弹窗，不要误点“放弃本段”，每年都有人在这里翻车。

7.3 关于“第三批”这个时间节点

2019秋招的“第三批”对应的时间大致是10月下旬到11月中旬，很多同学的互联网大厂秋招已经结束或接近尾声，心态上会有一点“最后的机会”的紧迫感。从实际结果看，这种多批次考试的银行反而给了大家更多调整机会——第一批笔试结束后，网上会出现零星的题型回忆帖，你可以结合这些信息查漏补缺，但这不代表第二三批的题目会更简单，我甚至感觉第三批的技术题比前两批略难，尤其是SQL部分增加了一道手写统计题。

所以如果你准备参加后续批次的银行IT笔试，不要把希望寄托在“捡漏”上，老老实实把数据结构和数据库基础打牢，比任何押题都有效。招行信用卡中心的面试环节还会围绕笔试内容深入追问，笔试里出现的HashMap、事务隔离级别、幂等设计，面试时很可能会让你展开细讲，所以笔试结束后不要立刻把知识“清零”，带着复盘笔记去面试会有奇效。

最后分享一个我自己的小技巧：笔试前把HashMap put流程、线程池参数、SQL多表统计模板题、完全背包DP模板这四个点的代码各写一遍，敲完就去考试。这几个知识点在招行卡中心的笔试里几乎每年都会以某种形式出现，准备它们投入产出比最高。祝准备银行IT方向的各位都能拿到心仪的offer。