度小满金融秋招研发岗笔试题复盘：算法与金融科技考点全解析
这套卷子当年在求职群里传得挺广。度小满金融那会儿刚从百度金融分拆独立没多久，顶着前身的技术积累和互联网金融的双重标签，研发岗笔试题自然受到不少人关注。我后来帮几届学弟学妹复盘过这套试卷，越看越觉得它出得很有代表性——既有大厂通用算法题的影子，又明显带着金融科技公司特有的那种“稳”字基因。今天这篇东西，我不打算把题目挨个念一遍，而是想站在复盘的角度，把试卷背后真正想考察的东西拆开讲清楚。对于准备校招的研发岗位，尤其是目标金融科技方向的同学，这篇应该能帮你少走不少弯路。
1. 试卷定位与底层逻辑：它在筛选什么样的人
1.1 度小满研发岗的背景决定了笔试风格
度小满金融的前身是百度金融服务事业群组，2018年4月正式独立运营。金融科技公司，这四个字意味着什么？意味着它的业务场景是资金、账户、信贷、风控、支付这些容不得半点马虎的领域。系统一旦出问题，不是页面报错那么简单，是实实在在的钱的问题。
我在看这套试卷的时候，最大的感受就是：它不是在考你会不会刷题，而是在考你“能不能在金融系统里干活”。同样是考算法，电商公司可能更关注你把用户购物车算清楚，度小满则更在意你在并发扣款、余额变更这种场景下把逻辑写对。这一点在后面的考点分布上体现得非常明显。
2019年秋招是个什么时间点？互联网行业校招笔试的淘汰率普遍很高，一套卷子要在短时间内从海量简历里筛出值得面试的人。所以试卷既要覆盖足够多的知识点来分层，又要有足够体量的编程题来验证动手能力。度小满的这套卷子基本遵循了这个逻辑：客观题筛基础、编程题筛能力、场景设计题筛工程素养，层层递进。
1.2 笔试考察的不是知识量，而是稳定输出能力
我见过太多同学复习的时候把知识点背得滚瓜烂熟，一到笔试就翻车。为什么？因为笔试考察的核心其实不是“你知不知道”，而是“你在有限时间内能稳定输出多少”。度小满这套试卷给我的感觉，就是在刻意制造这种压力。
选择题里会埋一些很容易跳进去的坑，编程题里会有边界条件非常刁钻的case，场景题则要求你在几分钟内组织出有条理的回答。这些都是模拟真实工作中“时间紧张、需求不清、系统复杂”的状态。金融系统尤其如此——需求摆在面前，你不能说“这个边界我没考虑过”，而是要第一时间想到资金安全、重复请求、数据一致性这些潜在风险。
所以准备这套试卷，不是去背答案，而是要训练自己形成稳定的工程化思维习惯。这个后面我会详细拆。
2. 核心考点拆解：四块内容决定面试入场券
2.1 数据结构与算法：区分度的核心战区
这套试卷里，数据结构与算法占据了绝对的主导地位。客观题部分会涉及时间复杂度分析、常见数据结构的特性比较，而编程题部分基本就是算法的天下。我复盘了近几年金融科技公司研发岗的题目趋势，发现动态规划、二叉树、字符串处理这三类题型的出现频率最高。
以当时试卷中比较典型的动态规划题目为例，这类题通常不会直接告诉你“这道题用DP”，而是包装成一个看似能贪心解决、但其实需要状态转移的问题。比如经典的零钱兑换变种：给定不同面额的硬币和一个总金额，求凑成该金额所需的最少硬币数。很多同学第一反应是贪心——每次选最大的硬币。但如果面额是[1, 3, 4]，总金额是6，贪心算法会给出4+1+1共3枚，而正确答案是3+3共2枚。这就是动态规划题目的典型陷阱。
这类题目的标准解法是自底向上填表。定义一个dp数组，dp[i]表示凑出金额i所需的最少硬币数，初始化为无穷大，dp[0]设为0。然后对于每个金额i，遍历所有面额coin，如果coin小于等于i，就尝试状态转移：dp[i] = min(dp[i], dp[i - coin] + 1)。边界条件是金额为0时不需要任何硬币，金额小于0时直接跳过。最后检查dp[amount]是否仍然是无穷大，如果是就返回-1，表示无法凑成。
我在实际面试别人时，发现一个很有意思的现象：能写出这道题正确代码的人，不见得能解释清楚为什么贪心不行。这就是考察深度的差异。笔试不会给你解释的机会，但你写的代码里能体现出来的思考深度，在后面的面试环节一定会被问到。
二叉树的题目同样如此。常见的层序遍历、最近公共祖先、二叉树的最大深度这类题目，考察的核心不只是遍历本身，而是你对递归和迭代两种方式的熟练程度。层序遍历需要用队列来模拟层级推进，这个思路放到真实业务里，其实就是在处理多级分层的组织结构遍历——比如一家银行的总行、分行、支行、网点。
刷题这件事，量很重要，但更重要的是总结套路。度小满的算法题难度区间跨度比较大，从easy到hard都有，它的目的是把所有候选人按照真实编程能力拉开梯度。如果你只刷过一百道题就上场，前面的简单题可能没问题，但一两道hard级别的动态规划会直接卡住。如果你想稳定通过笔试，建议把LeetCode刷到300题以上，其中动态规划、二叉树、字符串相关的题型要额外重点掌握。
2.2 计算机网络：不问八股，而是问业务怎么落地
计算机网络在大部分校招笔试里都是必考模块，度小满这套卷子也不例外。但它的问法很值得我们玩味——不是单纯让你背TCP三次握手的状态变化，而是会结合实际的业务场景来考察。
举一个当时比较典型的考察点：HTTPS的完整通信过程。度小满是金融科技公司，所有涉及用户资金的操作都要走HTTPS加密通道。笔试里就有一类题目是在问：当用户在浏览器里发起一笔转账请求，从输入URL到资金操作完成，中间的网络通信链路经历了哪些关键节点？这个过程里，DNS解析、TCP连接、TLS握手、HTTP请求、负载均衡、后端处理，每一层都有可考的细节。
金融科技场景对网络知识的考察，有几个高频点是通用互联网公司很少深挖的。
第一个是HTTP协议中的幂等性概念。GET、PUT、DELETE天然是幂等的，而POST不是。在资金操作场景里，如果用户因为网络超时重复提交了多次转账请求，后端如何保证不会重复扣款？这就涉及到了HTTP层的设计考量，也延伸到了后端接口的幂等性设计。这个问题我在后面的场景题部分会重点展开。
第二个是TCP的可靠传输原理。金融交易报文不能丢，不能乱序，不能重复。TCP的序列号、确认应答、超时重传、流量控制、拥塞控制，这些机制单独考起来都是八股文，但放在“如何确保交易指令不丢失不重复”这个语境下，就成了真正的工程问题。
第三个是负载均衡与高可用。金融系统要求7x24小时可用，负载均衡算法里的一致性哈希、加权轮询这些概念，笔试里会以选择题形式出现，考察你对流量分发策略的理解。
我在复习网络这块时给学弟学妹的建议是：不要只是背协议的状态和字段，而是要把网络的每一层都映射到一个具体的业务场景中去理解。你做的是金融系统，就想想一笔支付从发起到底层网络传输最终到账，经历了哪些网络环节；你做的是内容系统，就想想一次网页访问和视频加载有什么区别。这样的复习方式，应付笔试绰绰有余，面试的时候也特别加分。
2.3 操作系统与并发基础：稳定性的起点
操作系统在度小满试卷中的占比虽然不如算法和网络，但出现的题目都相当有区分度。进程与线程的区别、死锁产生的四个必要条件、虚拟内存的页面置换算法、进程间通信方式，这些是选择题的常客。真正拉开差距的，是围绕并发编程展开的考察。
金融科技系统的并发场景极其典型：高峰期大量用户同时发起交易，同一账户的余额可能被多个请求同时读写。如果对并发控制没有深刻理解，很容易写出线程不安全的代码。笔试里经常出现的一类问题是：多个线程同时对同一个变量进行自增操作，最终结果小于期望值，为什么？答案在于自增操作不是原子性的，它包含读取、计算、写回三个步骤，在多线程环境下会发生指令交错。这个问题的本质，就是代码层面数据不一致的根源。
更进一步的考察点是锁机制的运用。Java里的synchronized和ReentrantLock有什么区别？MySQL里的悲观锁和乐观锁分别适用什么场景？Redis分布式锁的正确的实现方式是什么？这些内容在选择题和问答题里都会有涉及。我看过不少同学的答案，能把概念背出来的人很多，但能答出“为什么金融场景推荐使用乐观锁来做余额变更”的人就非常少了。
这里我展开说说余额变更这个经典案例，因为它是度小满这类金融科技公司笔试面试中出现频率最高的场景题之一。
假设用户账户里有100元，现在要扣减3元。如果直接用SQL语句“UPDATE account SET balance = balance - 3 WHERE id = xxx”，在高并发下会不会出问题？如果在读到balance之后、更新balance之前，另一个线程也发起了扣减，是不是会发生金额覆盖？这时候就需要用到乐观锁机制：在更新时加上版本号或者余额条件校验，比如“UPDATE account SET balance = balance - 3, version = version + 1 WHERE id = xxx AND version = oldVersion”。如果影响行数为0，说明版本已经变化，需要重试。
这个小例子，涵盖了并发控制、数据库更新、重试机制三个维度的知识，是典型的“系统设计题浓缩版”。你能把这个逻辑讲清楚，操作系统里的互斥、同步、原子性这些概念才算是真正理解了，而不只是停留在死记硬背层面。
2.4 数据库知识：金融数据的生命线
数据库是金融科技公司笔试的重头戏，没有之一。我在复盘度小满这套试卷时，感觉数据库相关题目的占比甚至可能与算法持平。原因很简单——金融系统的核心是数据，而数据存放在数据库里，数据库设计得好不好，直接决定系统能不能撑住业务量级。
客观题部分通常考察索引的底层原理、事务的ACID特性、隔离级别与并发异常的关系、MVCC机制等基础概念。这类题目只要系统复习过都能答对，区分度中等。真正有区分度的，是围绕数据库设计和SQL优化展开的考察。
先说说索引。金融系统里数据量动辄上亿条，如果索引设计不合理，一条简单的查询就能把数据库拖垮。笔试里经常会出现这样的题目：一张交易流水表包含交易ID、用户ID、交易金额、交易时间、交易状态等字段，写一条SQL查询某用户在最近30天内的交易总金额，问这条SQL如何建索引最合适。很多人的第一反应是给用户ID建索引，但更优的方案是建立联合索引（用户ID，交易时间），这样才能在where条件中同时过滤用户和时间范围，减少索引回表次数。
再说说SQL的书写规范。数量级大的表上做全表扫描是灾难，所以笔试里会给一些慢查询场景，让你分析原因并优化。常见的优化思路包括：避免使用SELECT *、避免在where子句中对字段做函数运算、使用覆盖索引减少回表、拆分大查询为小批量查询等。这些常规优化点都需要能熟练写出来。
事务隔离级别是另一个高频考点。MySQL默认的隔离级别是REPEATABLE READ，通过MVCC机制可以在很大程度上避免不可重复读，同时配合间隙锁避免幻读。笔试里会问：脏读、不可重复读、幻读分别对应哪个隔离级别需要避免？这时候不光要背结论，还要能画出一个并发场景来说明这三种异常的区别。
我个人认为，数据库这块是最好复习、性价比最高的部分。因为它的知识点相对固定，而且非常实用。你把B+树索引原理真正理解了、把事务隔离级别的四个级别能用一个具体场景串讲出来，笔试里的数据库题目基本就稳了。
3. 金融科技场景下的隐性考点：这套卷子为什么不一样
3.1 幂等设计与重复请求处理
前面提到了HTTPS和HTTP里的幂等性概念，现在我想正式展开这个真正的核心考点。普通互联网公司的笔试题可能不太会专门考幂等设计，但度小满这套卷子里，它既是客观题、也会渗透在编程题和场景题里。
什么叫幂等？用一个简单的例子来解释：用户点击了一次转账按钮，但由于网络抖动，前端重试了两次，后端收到了三次内容相同的转账请求。如果你的接口不做幂等处理，用户的账户就被扣了三次钱，这显然是重大事故。所以后端接口必须保证：同一个请求无论被提交多少次，产生的效果都等同于一次。
实现方案通常是在前端生成一个全局唯一的请求ID（比如UUID），后端在收到请求时先查一下这个请求ID是否已经处理过。如果处理过，直接返回上次的处理结果；如果没有，才执行真正的扣款逻辑。这个方案涉及到缓存（存储已处理的请求ID）、分布式锁（防止并发重复处理同一个请求ID）、唯一索引（数据库层面的兜底保障）三方面的知识。
我当时看到这套试卷的题目时，第一反应是：这不是一道题，这是把一个真实的生产事故预防方案拆成了考点。如果你只是背过“幂等”这个概念，而不知道它怎么落地，这道题大概率会很泛泛地答一下。但如果你参与过支付系统或者订单系统的开发，你就能把请求ID的生成、存储、失效时间、重复请求的返回策略完整地讲出来，这种深度上的差异在阅卷时是一眼就能看出来的。
3.2 分布式事务与数据最终一致性
度小满的业务场景天然涉及多个系统之间的数据一致性。用户发起一笔借款，可能要同时更新用户账户、借款系统、风控系统的数据。如果其中一个系统调用失败，是全部回滚还是做补偿？这就涉及分布式事务的知识。
笔试里通常会以场景题形式出现：设计一个跨系统的转账接口，如何保证数据一致性？答案通常要分层次来组织。
第一层是尽可能避免分布式事务。把相关的数据放在同一个数据库实例里，用本地事务解决大部分问题。这种思路叫“单库单事务”，是成本最低、可靠性最高的方案。
第二层是如果必须跨系统，可以采用可靠消息最终一致性方案。本地事务执行成功后，发送一条消息到MQ，由下游系统消费消息来完成自己的业务动作。如果下游处理失败，MQ会重试，直到成功为止。这个方案的优点是系统解耦、可靠性高，缺点是存在一定的时间延迟。
第三层是分布式事务框架，比如TCC（Try-Confirm-Cancel）或者Saga模式。TCC会把一个事务拆成Try（预留资源）、Confirm（确认执行）、Cancel（取消执行）三个阶段，每个阶段都有对应的接口实现。这种方案对业务侵入性较强，但能在很大程度上保证一致性。
能在笔试里写出这几个层次，并能说清楚每个方案的优劣和适用场景，基本就达到了度小满对校招候选人的期望水平。我当时辅导过的一个学生，就是把MQ方案的可靠性投递、消费幂等、重试机制这三个关键点讲透了，笔试直接高分通过，面试时这个话题也被当作亮点来考察。所以这块内容，准备金融科技公司时务必重点吃透。
3.3 数据安全与敏感信息保护
金融科技公司手里握着大量用户的身份信息、银行卡信息、交易记录，数据安全是红线中的红线。度小满试卷里有一部分内容是围绕数据安全展开的，虽然占比不算高，但属于高频考点。
选择题层面会考察对称加密与非对称加密的区别、加盐哈希的实现原理、HTTPS证书的验证流程等。这些基础概念不是难点，但需要你理解背后的原理，而不能只背结论。
更有区分度的是场景设计题，比如“如何设计一个用户密码存储方案”。很多同学第一反应是MD5加密，这其实是踩了坑。MD5存在大量彩虹表，而且碰撞风险高，不能直接用于密码存储。正确的方案是使用加盐的慢哈希算法，比如bcrypt或者PBKDF2，每个用户生成独立的随机盐值，将盐值与密码一起计算哈希值，并存储盐值和最终的哈希结果。这样即使数据库泄露，攻击者也无法通过彩虹表快速破解密码。
再比如“日志脱敏”问题。金融系统会记录大量操作日志，日志里如果包含用户的完整银行卡号或身份证号，一旦日志被泄露，后果不堪设想。所以日志系统里对敏感字段要做脱敏处理，比如银行卡号只显示后四位，身份证号只显示前六位和后四位。这个细节经常被候选人忽略，但在金融科技公司笔试里出现，本身就是一种信号：这家公司对数据安全有着实打实的重视。
4. 实操策略：限时线上笔试的答题顺序与避坑指南
4.1 明确题型分布，制定时间分配方案
度小满2019秋招研发岗笔试采用的是在线笔试形式，通常包含三个部分：客观题（单选、多选、判断）、编程题（两道到四道不等）、主观问答题（一道到两道）。我当时给准备笔试的同学建议的时间分配方案是：客观题控制在35%左右的时间，编程题占50%，主观题占15%。如果客观题遇到卡壳的，不要恋战，先标记跳过，因为后面的编程题分值往往更高。
这里要特别提醒的是在线笔试的输入输出格式问题。很多同学算法题思路完全正确，却因为没搞懂输入输出格式而白白丢分。在线笔试系统的输入输出通常是标准输入输出，需要使用split、map、parseInt这类方法来处理数据，尤其是字符串和整型之间的转换一定要熟练。如果平台要求的是ACM模式，你还需要自己构建数据处理逻辑；如果是核心代码模式，只需要完成函数实现。提前去牛客网或者赛码网熟悉一下历年笔试题的输入输出风格，能避免大量无谓的失误。
4.2 编程题的答题技巧：先暴力后优化，宁可过case不要追求完美
我在复盘这套试卷的时候，发现一个比较普遍的现象：那些通过笔试的人，未必是最快解出最优解的人，但一定是最能保证“提交的代码能通过测试用例”的人。编程题判分靠的是测试用例的通过率，而不是解法是否好看。
所以答题策略上，我推荐“三步走”法。第一步，先花一到两分钟把所有编程题都扫一遍，判断各自难度；第二步，从最简单的题开始做，保证能拿到的分全拿到；第三步，对于难题，如果一眼看不出最优解，先写出暴力解法，确保能通过一部分case，再逐步优化。千万不要在一道题上死磕超过30分钟，那是典型的校招自杀式答题方式。
举个例子，有一道比较典型的题目是“判断一个字符串是否是回文串”，但字符串里混入了空格和符号，需要忽略大小写。暴力解法很直接：去掉多余字符，统一转成小写，双指针判断。但如果你在实现时没考虑到空字符串的边界情况，代码就会出错。这种边界问题考的不是智商，而是平时的编码习惯。我在练习时养成了一个习惯：写完一段代码，先自己列几个边界测试用例，比如空输入、单个元素、所有元素相同、最大值、最小值。这个习惯在笔试中直接帮我规避了好几次翻车。
4.3 需要注意的答题平台和网络问题
在线笔试还有一个容易被忽视的坑：网络和浏览器环境。有些同学的机器上装了某些浏览器插件，会导致代码编辑器的快捷键失灵，或者代码自动保存失败。建议在前一天就把笔试平台的环境测试跑一遍，确认网络稳定、摄像头正常、浏览器兼容，并关闭所有无关的软件弹窗。不要小看这些细节，每年都有人因为电脑弹窗打断了笔试状态而发挥失常。
另外，如果试卷里要求“在本地IDE调试后粘贴到平台”，一定要在平台提供的编辑器里重新跑一遍测试用例。本地编译环境和平台环境的JDK/Python版本可能存在差异，代码在本地跑通了，换到线上直接编译失败的情况我都见过好几次。总而言之，线上笔试是一次系统工程，不是只有写代码这一个环节。
5. 复盘总结：从这套试卷看研发岗校招准备的三个要点
这套试卷做完、复盘完，我最大的感受是：它不仅是一份考题，更是度小满金融作为金融科技公司对研发工程师的能力画像。它希望你数据结构与算法足够扎实，能够应对复杂系统的逻辑建模；希望你计算机网络、操作系统、数据库的知识不是背出来的，而是能与业务场景结合理解；更希望你对金融行业特有的稳定性、安全性、一致性有天然的敏感。这些要求，放到今天依然成立。
如果你正在准备这类公司的研发岗，下面三个要点请务必重视。
第一个要点是基本功优先于刷题量。我在面试中见过不少刷了五六百道题的同学，问他为什么HashMap的扩容为什么是2的幂次，他回答不上来。这种广泛但不深入的状态，笔试也许能过，面试一定会露馅。度小满的考察逻辑是“以用促学”，它希望你理解每个知识点背后的设计动机。
第二个要点是培养工程化的编码习惯。给变量起有意义的名称、提取公共函数、处理边界条件、考虑异常分支，这些看似琐碎的习惯，在笔试评分时能给你带来隐性加分。阅卷人看你的代码，其实就在模拟看你写的生产代码，一个连空数组都处理不好的人，很难让人放心把交易系统交给他。
第三个要点是理解金融业务的核心诉求：稳定、安全、准确、可追溯。这四个词听起来很虚，但落到笔试里就是幂等设计、分布式事务、数据加密、日志记录这些具体题目。你能不能在答题时主动朝着这些方向思考，是区分你只是会写代码还是真的适合金融科技公司的关键标准。
后来带了几年校招生，我越来越确定一件事：笔试是敲门砖，但真正决定你能走多远的，是你在准备笔试时形成的那套思考方式。度小满这套2019年的卷子，到今天仍然值得后来者反复咀嚼。祝各位准备秋招的研发同学都能拿到心仪的offer。