这套卷子当年在求职群里传得挺广。度小满金融那会儿刚从百度金融分拆独立没多久顶着前身的技术积累和互联网金融的双重标签研发岗笔试题自然受到不少人关注。我后来帮几届学弟学妹复盘过这套试卷越看越觉得它出得很有代表性——既有大厂通用算法题的影子又明显带着金融科技公司特有的那种“稳”字基因。今天这篇东西我不打算把题目挨个念一遍而是想站在复盘的角度把试卷背后真正想考察的东西拆开讲清楚。对于准备校招的研发岗位尤其是目标金融科技方向的同学这篇应该能帮你少走不少弯路。1. 试卷定位与底层逻辑它在筛选什么样的人1.1 度小满研发岗的背景决定了笔试风格度小满金融的前身是百度金融服务事业群组2018年4月正式独立运营。金融科技公司这四个字意味着什么意味着它的业务场景是资金、账户、信贷、风控、支付这些容不得半点马虎的领域。系统一旦出问题不是页面报错那么简单是实实在在的钱的问题。我在看这套试卷的时候最大的感受就是它不是在考你会不会刷题而是在考你“能不能在金融系统里干活”。同样是考算法电商公司可能更关注你把用户购物车算清楚度小满则更在意你在并发扣款、余额变更这种场景下把逻辑写对。这一点在后面的考点分布上体现得非常明显。2019年秋招是个什么时间点互联网行业校招笔试的淘汰率普遍很高一套卷子要在短时间内从海量简历里筛出值得面试的人。所以试卷既要覆盖足够多的知识点来分层又要有足够体量的编程题来验证动手能力。度小满的这套卷子基本遵循了这个逻辑客观题筛基础、编程题筛能力、场景设计题筛工程素养层层递进。1.2 笔试考察的不是知识量而是稳定输出能力我见过太多同学复习的时候把知识点背得滚瓜烂熟一到笔试就翻车。为什么因为笔试考察的核心其实不是“你知不知道”而是“你在有限时间内能稳定输出多少”。度小满这套试卷给我的感觉就是在刻意制造这种压力。选择题里会埋一些很容易跳进去的坑编程题里会有边界条件非常刁钻的case场景题则要求你在几分钟内组织出有条理的回答。这些都是模拟真实工作中“时间紧张、需求不清、系统复杂”的状态。金融系统尤其如此——需求摆在面前你不能说“这个边界我没考虑过”而是要第一时间想到资金安全、重复请求、数据一致性这些潜在风险。所以准备这套试卷不是去背答案而是要训练自己形成稳定的工程化思维习惯。这个后面我会详细拆。2. 核心考点拆解四块内容决定面试入场券2.1 数据结构与算法区分度的核心战区这套试卷里数据结构与算法占据了绝对的主导地位。客观题部分会涉及时间复杂度分析、常见数据结构的特性比较而编程题部分基本就是算法的天下。我复盘了近几年金融科技公司研发岗的题目趋势发现动态规划、二叉树、字符串处理这三类题型的出现频率最高。以当时试卷中比较典型的动态规划题目为例这类题通常不会直接告诉你“这道题用DP”而是包装成一个看似能贪心解决、但其实需要状态转移的问题。比如经典的零钱兑换变种给定不同面额的硬币和一个总金额求凑成该金额所需的最少硬币数。很多同学第一反应是贪心——每次选最大的硬币。但如果面额是[1, 3, 4]总金额是6贪心算法会给出411共3枚而正确答案是33共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会重试直到成功为止。这个方案的优点是系统解耦、可靠性高缺点是存在一定的时间延迟。第三层是分布式事务框架比如TCCTry-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。
这套卷子当年在求职群里传得挺广。度小满金融那会儿刚从百度金融分拆独立没多久顶着前身的技术积累和互联网金融的双重标签研发岗笔试题自然受到不少人关注。我后来帮几届学弟学妹复盘过这套试卷越看越觉得它出得很有代表性——既有大厂通用算法题的影子又明显带着金融科技公司特有的那种“稳”字基因。今天这篇东西我不打算把题目挨个念一遍而是想站在复盘的角度把试卷背后真正想考察的东西拆开讲清楚。对于准备校招的研发岗位尤其是目标金融科技方向的同学这篇应该能帮你少走不少弯路。1. 试卷定位与底层逻辑它在筛选什么样的人1.1 度小满研发岗的背景决定了笔试风格度小满金融的前身是百度金融服务事业群组2018年4月正式独立运营。金融科技公司这四个字意味着什么意味着它的业务场景是资金、账户、信贷、风控、支付这些容不得半点马虎的领域。系统一旦出问题不是页面报错那么简单是实实在在的钱的问题。我在看这套试卷的时候最大的感受就是它不是在考你会不会刷题而是在考你“能不能在金融系统里干活”。同样是考算法电商公司可能更关注你把用户购物车算清楚度小满则更在意你在并发扣款、余额变更这种场景下把逻辑写对。这一点在后面的考点分布上体现得非常明显。2019年秋招是个什么时间点互联网行业校招笔试的淘汰率普遍很高一套卷子要在短时间内从海量简历里筛出值得面试的人。所以试卷既要覆盖足够多的知识点来分层又要有足够体量的编程题来验证动手能力。度小满的这套卷子基本遵循了这个逻辑客观题筛基础、编程题筛能力、场景设计题筛工程素养层层递进。1.2 笔试考察的不是知识量而是稳定输出能力我见过太多同学复习的时候把知识点背得滚瓜烂熟一到笔试就翻车。为什么因为笔试考察的核心其实不是“你知不知道”而是“你在有限时间内能稳定输出多少”。度小满这套试卷给我的感觉就是在刻意制造这种压力。选择题里会埋一些很容易跳进去的坑编程题里会有边界条件非常刁钻的case场景题则要求你在几分钟内组织出有条理的回答。这些都是模拟真实工作中“时间紧张、需求不清、系统复杂”的状态。金融系统尤其如此——需求摆在面前你不能说“这个边界我没考虑过”而是要第一时间想到资金安全、重复请求、数据一致性这些潜在风险。所以准备这套试卷不是去背答案而是要训练自己形成稳定的工程化思维习惯。这个后面我会详细拆。2. 核心考点拆解四块内容决定面试入场券2.1 数据结构与算法区分度的核心战区这套试卷里数据结构与算法占据了绝对的主导地位。客观题部分会涉及时间复杂度分析、常见数据结构的特性比较而编程题部分基本就是算法的天下。我复盘了近几年金融科技公司研发岗的题目趋势发现动态规划、二叉树、字符串处理这三类题型的出现频率最高。以当时试卷中比较典型的动态规划题目为例这类题通常不会直接告诉你“这道题用DP”而是包装成一个看似能贪心解决、但其实需要状态转移的问题。比如经典的零钱兑换变种给定不同面额的硬币和一个总金额求凑成该金额所需的最少硬币数。很多同学第一反应是贪心——每次选最大的硬币。但如果面额是[1, 3, 4]总金额是6贪心算法会给出411共3枚而正确答案是33共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会重试直到成功为止。这个方案的优点是系统解耦、可靠性高缺点是存在一定的时间延迟。第三层是分布式事务框架比如TCCTry-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。
