2019届秋招那会儿我投了帆软软件的研发岗位。笔试通知来得比预期早做之前我按照一般互联网公司的路子准备了一堆算法题结果真打开试卷才发现帆软的笔试题设计和它这家公司的气质一样——不玩虚的重心全在数据、报表和工程落地上。整场笔试做下来我对这家公司到底想要什么样的人有了很直观的感知。这篇文章把当年那套笔试题的题型构成、考察重点、答题思路和踩过的坑完整复盘一遍给准备投帆软研发岗的同学做个参考。先说结论帆软2019届秋招研发岗笔试难度谈不上顶尖但考察面很宽覆盖Java基础、数据结构与算法、数据库SQL、计算机网络、操作系统还有一部分偏业务场景的主观题。算法题不会出到LeetCode hard那种劝退级别但SQL题和业务场景题的比重明显高于一般互联网公司。这就意味着学校里的那套刷题进大厂的思路在这里不一定完全适用得针对性调整复习策略。1. 笔试现场还原题量、时长与最容易被忽视的通过门槛1.1 线上笔试的流程与基本设置2019届秋招的线上笔试平台已经比较成熟了帆软用的是当时主流的在线考试系统全程摄像头监控页面切出去会有记录。时长我记得是120分钟题量大概在40道左右包含单选题、多选题、填空题、两道编程题和两道简答/主观题。120分钟做40道题平均每道题只有3分钟但实际做题的时候不可能均匀分配选择题可能要快一些编程题和SQL题必须留出大块时间。这里有个容易被忽视的点在线笔试系统不同题型的跳转规则不一样。有的平台允许跨题型回看有的平台做完编程题进入主观题后就不能回头改选择题了。当年我身边就有同学因为没搞清楚这个规则编程题提前交卷后想回去检查选择题结果发现已经锁定了。所以正式开考之前一定先花两分钟把答题卡界面、题型排列、剩余时间分布看清楚别急着点开始。1.2 题型构成与分值分布从分值占比来看印象里比较清晰的是选择题单选多选大概占40%编程题占30%SQL和业务场景题占20%简答/主观题占10%。这个比例和很多互联网公司算法题定生死的模式差别很大。选择题考察的知识点覆盖广但深度不夸张。Java集合类源码层面的东西考了不少比如HashMap的扩容机制、ArrayList和LinkedList在指定位置插入元素的时间复杂度对比数据库部分考了索引失效场景、事务隔离级别、两段锁协议操作系统考了进程调度算法、死锁产生的必要条件、虚拟内存页面置换计算机网络考了TCP三次握手、HTTP状态码语义这些基础。多选是重灾区漏选和错选都不给分遇到拿不准的干脆少选求稳比贪多更重要。编程题就两道一道偏链表/数组操作一道偏字符串处理难度在LeetCode easy到medium之间。这里要提醒一下帆软笔试的编程题不是ACM赛制那种只要求输出结果它要求你写完核心逻辑并且能处理边界输入。平台对输入的读取方式有严格要求如果用Java类的命名必须是Main这和老牌的OJ平台保持一致。1.3 通过门槛到底卡在哪帆软研发岗笔试的通过门槛我个人的体感是不要求你每道题都做对但绝对不能有明显短板。如果你算法题全AC但SQL题全空着或者Java基础选择题错一半大概率是进不了面试的。特别是SQL题和业务场景题这几乎就是帆软区别于其他公司的辨识度所在。帆软的核心产品FineReport和FineBI都是围绕企业数据分析和报表可视化展开的研发人员如果连常见的报表取数场景都处理不明白后面工作会非常吃力。所以笔试里那些和报表、数据统计相关的题目答得好不好直接决定了你能不能进入下一轮。我当年考完的最大感受是帆软要的不是纯刷题选手而是那种基础扎实、能理解业务数据、能徒手写SQL的工程型候选人。明白了这一点备考方向的优先级就清晰了。2. 数据结构与算法笔试主战场上的得分纪律2.1 算法题的难度坐标剑指Offer到LeetCode中等帆软的算法题难度大致落在《剑指Offer》和LeetCode中等难度的交叉地带。它不会考那种需要灵光一闪的奇技淫巧更多是考察基本功是否扎实代码是否能一把写对。两道编程题的出题风格我印象挺深。第一道是链表相关的题目要求对链表做某种重组操作核心是考察指针操作的严谨性。第二道是字符串处理给定一组规则要求输出处理后的字符串核心是考察对边界条件的处理和对常用API的熟练度。两道题都不需要复杂的算法思想但都很容易在细节上翻车。2.2 高频考点与典型题目还原虽然不能完整复述原题时间久远而且平台有保密要求但我可以还原几个典型的出题方向帮助大家理解考察逻辑。链表方向大概率会考链表反转的变体。比如给你一个单链表要求每K个节点一组反转不足K个保持原样。这题看起来不难但真正手写的时候很多人会卡在四个指针的维护上。核心思路是先统计链表长度然后分块处理每块内部用头插法反转块与块之间要做指针衔接。我当时是先画了三个块之间的指针关系图再动手写代码最后用长度为5、K2的用例走了一遍确保没有断链。另一个高频方向是数组与滑动窗口。比如寻找数组中和为某个目标值的连续子数组或者找最长无重复字符子串。这类题目用滑动窗口的思想最容易想清楚窗口的左右边界怎么移动、窗口内用什么数据结构维护状态这两个问题想明白了代码框架基本就出来了。帆软的算法题还有一个特点——输入数据量可能给得很大比如10的5次方量级这意味着O(n方)的暴力解法是过不去的。所以哪怕题目看起来简单也要优先考虑O(n)或O(n log n)的解法并在注释里标明时间复杂度阅卷人能看到你的复杂度意识。2.3 刷题之外的细节坑笔试平台的编程题提交方式和LeetCode差别很大。LeetCode只需要你补全函数但帆软的笔试平台要求你处理标准输入输出很多例子里需要用到while (sc.hasNext())这种循环读入。如果你平时只在LeetCode上刷题第一次接触这种模式会很不适应。我强烈建议大家考前用牛客网的在线编程题库练几道题重点练习Java的输入输出写法。比如用BufferedReader读一行、用StringTokenizer或split( )拆字段、输出时用StringBuilder拼接减少IO次数。这些细节看似不起眼但能帮你省下大量调试时间。还有一个需要特别留意的点在线笔试平台没有IDE的自动补全和语法提示所有Java API只能凭记忆写。比如StringBuilder的reverse()、setCharAt()、substring()这些方法如果平时依赖IDE提示考试时可能想不起来方法签名。备考时建议把Java常用类的方法列表过一遍不用背太深但至少要知道哪个类有哪个方法。3. 数据库与SQLBI公司笔试里最贴近业务的硬核题3.1 为什么帆软笔试的重头戏在SQL如果只说一个帆软笔试和其他公司笔试最不一样的地方我绝对选SQL题。帆软是做报表和BI产品的FineReport的报表数据集、FineBI的数据准备本质都是把SQL查出来的数据映射到表格和图表上。研发岗虽然不一定天天写复杂SQL但必须对数据查询有深刻理解否则没法理解业务方的真实需求更没法优化底层的数据查询性能。笔试里的SQL题不是单纯让你背语法而是给你一个业务背景、几张表让你写出满足特定统计需求的查询语句。这种题目最能区分真会和背过。真会的人看到表结构就能条件反射般拆解出需要哪些关联、哪些分组、哪些聚合函数背过的人往往一遇到多表关联去重排序组合就不行了。3.2 三组典型SQL业务场景的推导过程我复盘当年笔试里最典型的SQL场景大概是这样的第一类分组聚合。表结构大概是订单表order_id, user_id, product_id, amount, order_date。业务需求是统计每个用户的总消费金额和下单次数并按消费金额降序排列。这题考的是GROUP BY和SUM/COUNT的组合以及ORDER BY的用法。注意点在于GROUP BY user_id之后SELECT中只能出现分组字段和聚合函数不能直接select非分组字段否则在某些数据库实时模式下会直接报错。第二类多表关联。给一张用户表和一张订单表要求统计每个城市的活跃用户数活跃定义近30天下过单。方法有两种一种是先过滤订单表再去重关联用户表另一种是先关联再分组。看起来结果一样但性能差异很大。正确做法是先缩小数据量再关联也就是先WHERE order_date DATE_SUB(CURDATE(), INTERVAL 30 DAY)过滤订单得到临时结果后去重再和用户表关联。这种先过滤再关联的优化意识是阅卷人希望看到的亮点。第三类窗口函数。例如订单表中每个用户最近一次下单的记录。在2019届时不少同学还不太会用窗口函数直接用子查询比较订单日期写出来又长又难维护。其实用ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_date DESC)就能一行搞定。帆软的笔试允许使用窗口函数因为报表场景里排名、同比环比、累计求和都离不开窗口函数提前掌握ROW_NUMBER()、RANK()、LAG()、LEAD()这几个是稳赚不赔的。3.3 SQL题备考的务实做法备考SQL我不建议只捧着教材背语法更有效的做法是直接在本地装一个MySQL或者用SQLZoo这类在线练习平台把笔试常见的业务场景都亲手写一遍。重点练习这几类场景连续出现N次的问题连续登录天数、连续购买记录分组TopN问题每个部门工资最高的员工累计求和与移动平均月度累计销售额同比环比本月相比上月的增长率行转列/列转行报表场景里特别常见每一类都无需死记硬背核心是理解其业务含义然后用标准SQL一步步翻译成查询条件。特别是连续N天这类问题网上有各种奇技淫巧但笔试现场最好用一个思路清晰、可解释的写法比如用日期减排序序号做分组稳定不容易出错。4. Java基础、框架与设计思想研发岗位的必答项与连带追问4.1 Java基础题的考察重心帆软研发岗的Java基础选择题考察重心和大多数中大型公司是一致的但有几个点反复出现需要引起重视。集合类是必考重点。HashMap的底层结构、put流程、扩容机制、为什么链表长度到8才转红黑树这些几乎是送分题但你得真的理解而不是背结论。我当年备考时把HashMap的源码完整读了两遍把数组链表/红黑树hash扰动函数2的幂次扩容这一套串成了完整的故事笔试里遇到相关选择题基本可以秒杀。多线程也是一个高频考点。synchronized和ReentrantLock的区别、volatile的可见性和禁止重排、线程池的七个参数、拒绝策略的四种类型这些都得能做到给别人讲明白的程度。帆软的日常业务里报表任务经常要并发处理大量数据所以多线程并发编程不只是面试题是有真实业务场景支撑的。JVM部分考了内存区域划分、垃圾回收算法、类加载过程。最常考的是哪些对象可以作为GC Roots这种题需要理解可达性分析的本质而不是死记五个类型。4.2 框架与中间件的出题方式框架题在选择题里占的比例不高但简答/主观题里会出现。2019届笔试的主观题有一道大致是描述一次完整的Spring MVC请求处理流程从浏览器发出请求到返回响应的全过程。这题考察的不是背概念而是能否把前端控制器、处理器映射、控制器适配、视图解析器这些角色之间的协作说清楚。另一个高频考点是Spring IOC和AOP。IOC的核心是容器管理对象的生命周期和依赖关系AOP的核心是动态代理。笔试里往往会给一个具体的场景让你判断能否用AOP解决或者让你说Spring AOP和AspectJ的区别。我的建议是不要只背定义要会举例子。比如每个方法执行前后打印日志用AOP怎么实现事务管理为什么基于AOP实现这样答题就会显得有血有肉。MyBatis的#{}和${}的区别也是数据库方向的高频题。简单说#{}是预编译占位符可以防SQL注入${}是字符串拼接有注入风险。但笔试里更进阶的问法是什么场景下必须用${}比如动态排序的ORDER BY字段如果字段名来自用户输入用#{}会直接被当作字符串字面量导致SQL语法错误。这种实用知识的积累光靠刷题刷不出来得靠实际写项目时踩过坑才能有深刻体会。4.3 简答/主观题怎么答才不丢分帆软笔试的简答题不算多但答得好坏会影响面试官对你的第一印象。我当时遇到的一道题大意是在数据量极大的情况下如何设计一个高效的数据报表查询接口这题没有标准答案但考察的是系统设计思维。我当时的大致思路是分三层回答数据存储层使用索引覆盖、分区表、汇总表等手段减少扫描量对常用的统计指标建立物化视图或预聚合表。查询层利用缓存Redis缓存热点报表数据采用异步查询避免报表请求阻塞主线程分页接口用游标分页而不是offset分页避免大偏移量的性能问题。应用层对报表接口做限流和降级防止大促或高峰时段拖垮数据库导出大报表时改为异步任务生成文件后通知下载。这类主观题的核心是让阅卷人看到你有层次感能区分不同层面的问题。不需要特别高深的架构但思路要完整、逻辑要自洽。5. 考试过程中的节奏控制与心态管理5.1 时间分配策略120分钟我的实际时间分配是选择题和填空题控制在55分钟内完成编程题40分钟SQL和主观题20分钟最后留5分钟检查关键题型的答案有没有写错位置。选择题里最忌讳的是在一道多选上纠结太久。多选的评分规则是少选得部分分还是不得分具体要看平台说明。我通常的做法是第一遍做的时候确定的直接选不确定的做好标记先凭第一印象选一个等全部做完再回头思考。因为大脑在高压状态下第一感觉往往比反复纠结更可靠。编程题建议先做自己更熟悉的那道。笔试现场的编程题往往有一易一难的分布先拿下简单的保住基本盘再啃难的那道。如果一道题想了15分钟还没有完整思路果断切换战场别在一棵树上吊死。5.2 在线笔试系统的那些隐性规则在线笔试系统有一些隐形规则考前最好提前了解否则考场上会手忙脚乱。第一是代码提交方式。不同平台要求不同有的要求写完代码点运行看测试用例通过情况有的则只是把代码保存在编辑器里由阅卷人人工查看。如果是后者那么代码里写清晰注释和思路说明就非常重要因为阅卷人要在短时间内判断你的水平注释能帮你传递信息。第二是切屏检测。在线系统会记录你切出考试页面的行为超过一定次数可能触发警告甚至强制交卷。考试前把所有可能用到的工具计算器、备忘录、草稿纸全部准备好考试过程中不要试图去搜索答案既没必要也不安全。第三是输入法问题。如果编程题里要处理中文输入虽然少见注意在线编辑器对编码的支持。最好提前确认一下平台的编码设置免得提交后出现乱码。5.3 一次慌乱带来的教训最后讲一个我自己的教训。当年笔试到编程题的时候我遇到了一道链表题思路其实很清晰结果在输入读取的代码上卡住了。因为平时刷LeetCode习惯了直接收参数到了标准输入输出模式忘了hasNextLine()判断的用法调试了快十分钟才想起来。那十分钟如果能省下来后面的SQL题还能答得更从容。从那之后我再参加任何线上笔试一定先把输入输出的模板代码提前背熟包括Scanner的几种读取场景、BufferedReader按行读和按分隔符读的写法。这种提前把环境类细节磨到位的准备往往比额外刷十道题更有效。帆软的笔试整体给人的感觉是它不追求用超难题把人考倒而是用覆盖面很广的基础题和多场景的SQL题筛出那些真正想清楚了自己要做什么的人。如果你打算投帆软研发岗我的建议是算法刷题保持手感即可重心放在Java基础、数据库SQL和业务场景分析上多想想如果我是做报表的我会怎么处理这些数据。这套思路不仅对笔试有用对后续面试和真正入职后的工作同样受用。