开头先交代一个背景我是把这份A卷当作一个“体检项目”来做复盘的不是简单地背答案而是想把每道题背后的考察点翻出来。当时拿到这套帆软2019届春招研发岗位A卷第一感觉是卷面风格很务实不故意挖坑但基础知识不扎实的话很容易在看似普通的题上栽跟头。帆软做的是报表和商业智能工具研发岗位笔试天然就带“数据基因”。这意味着除了常规的语言、数据结构和算法数据库和场景设计题占了相当大的比重。如果你准备的是互联网大厂那种偏重算法竞赛的题库没必要照搬到这里这份卷子更看重“能不能用工程化思维解决数据展示与分析问题”。这篇复盘面向两类人一类是正在准备校招、尤其是瞄准国内软件或BI厂商研发岗的同学另一类是工作几年想跳槽、但很久没碰笔试的人。我会按卷面结构逐块拆解每道有代表性的题都会讲清楚“考点是什么、我当时怎么想、标准做法长什么样、还有哪些坑”。1. 这份A卷在考什么整体卷面结构与考察意图1.1 卷面模块与常见分值分布从试卷结构来看A卷基本沿用了“基础选择题/填空题 算法编程题 SQL题 场景设计题”的组合整体时长一般在90到120分钟。具体模块大致可以分成这样几块模块常见题型大概分值比重核心考察方向语言与数据结构基础单选、多选、判断、简答25% - 35%Java/C语法、集合框架、内存模型、链表栈队列算法与编程在线编程题25% - 35%字符串处理、数组遍历、动态规划、贪心数据库SQL编写、查询优化问答20% - 30%多表关联、分组聚合、子查询、索引综合设计开放问答、场景设计15% - 20%报表取数、权限控制、性能优化这个配比很能说明问题帆软不是靠刷题海选人的公司它希望你具备完整的逻辑链条——看懂数据结构、会写程序、能查数据库、最后还能把业务抽象成可落地的方案。我后来和几个同学交流大家普遍觉得算法题难度中等偏上但SQL和设计题才是真正拉开差距的地方。1.2 “帆软系”出题风格的三个共性这里说的“帆软系”泛指做报表、BI、数据可视化这一类ToB软件的厂商。他们的笔试和互联网C端产品有个明显区别题目背景很落地往往直接来自真实的客户需求。总结下来有三个共性第一不追求偏题怪题。你很少看到那种需要冷门数学技巧或脑筋急转弯式的算法题更多是“给定一个字符串按规则输出”这种平铺直叙的题目。但平铺直叙不等于送分边界条件处理不好照样过不了全部测试用例。第二数据库相关题目占比高。要知道报表工具的核心工作之一就是从各种数据库里取数、聚合、格式化输出所以SQL能力几乎是研发岗的生存技能。笔试里的SQL题通常不会只考单表查询多表关联、分组统计、行列转换都是高频考点。第三场景设计题占一席之地而且基本绕不开权限、性能、大数据量这三个话题。帆软的FineReport和FineBI都涉及多用户协同、多数据源接入所以“怎么让成千上万人同时打开一张报表还不卡”这类问题几乎每年都会出现。2. 基础题里的那些“送命题”语言与数据结构易错点2.1 语言基础Java内存、字符串与finally的经典组合基础题不是白送分的它筛掉的是“基础不牢靠”的人。我记得A卷里有一道典型的Java题给出一个方法try块里return一个intfinally块里修改这个int问最终返回值是多少。初看似乎简单实际上考察的是对Java返回值和finally执行机制的理解。正确结论是try块中的return先计算并保存返回值然后才执行finally块finally块对局部变量的修改不会影响已保存的返回值。但如果finally块里也有return则会覆盖try里的返回值这个变体也经常考。类似的还有String不可变性、StringBuilder和StringBuffer的区别、ArrayList与LinkedList的适用场景。这些题目本身不超纲但恰恰是平时写代码时最容易忽略的地方。我的建议是不要只背结论要去看JVM字节码或直接写代码验证。自己跑一遍比看十篇面经都管用。2.2 数据结构与C/C考点内存对齐与链表操作A卷中还有一部分C语言或C相关的题目即使是投Java岗也偶尔会碰到几道。这里最经典的就是内存对齐计算。比如struct Test { char a; int b; char c; };问sizeof(struct Test)是多少如果你按字段大小相加会得到1416但正确答案是12在32位和64位默认对齐规则下。原因是编译器会在char a之后填充3个字节让int b对齐到4字节边界结构体整体大小再对齐到最大成员对齐数的整数倍即4的倍数所以char c之后还要再填充3个字节。这个考点考察的是对计算机内存布局的理解而不是单纯的语法记忆。链表相关的题也很常见比如判断单链表是否有环、找环的入口、反转链表。这类题在笔试里通常以代码补全或简答形式出现算法本身不复杂但手写时容易在指针边界上出错。我的经验是链表题一定要画图画出每一步指针指向再动笔写代码这样基本不会写乱。2.3 基础题复习建议别只看不练基础题想拿高分没有捷径就是反复练。但“练”不是盲目刷题而是针对自己的薄弱点定向突破。如果你对JVM内存模型搞不清楚就把运行时数据区、GC流程、类加载机制串一遍如果对C语言指针发怵就专门做指针和数组的对比练习。建议自制一份错题清单把每次笔试或模拟中做错的题归类标出考点和错因。比如“String不可变性”是一个考点“finally执行顺序”是另一个考点。等到考前只看清单效率会比重新翻书高很多。3. 算法编程题从题意到AC的完整推演3.1 高频题型字符串处理、模拟实现和贪心A卷的编程题一般有两到三道核心是考察“把思路转成代码”的能力。我在多个版本的题目里都见到过这些类型字符串去重、字符串排序、数组最大连续子段和、根据规则模拟某个过程。不要小看字符串处理这类题最容易出现“逻辑没想清楚就动手写”的问题。比如要求统计字符串中每个字符出现的次数并按次数从大到小输出次数相同的按字符ASCII码升序输出。很多人在排序规则上栽跟头——写成了先按字符排、再按次数排和题目要求的优先级正好反了。给一个可复现的解法用Python写会非常直观from collections import Counter def sort_by_count(s: str) - str: counter Counter(s) sorted_chars sorted(counter.items(), keylambda x: (-x[1], x[0])) return .join([c * cnt for c, cnt in sorted_chars])这段代码里关键是sorted的key函数同时指定了两个维度次数降序、字符升序。Python的tuple比较会先比较第一个维度再比较第二个维度所以(-x[1], x[0])就能一次搞定。如果笔试环境允许用Python这样写最省时间如果只允许C或Java思路一样只是需要自己实现排序比较器。3.2 贪心与动态规划的典型例题推演另一道我在A卷里印象很深的题是“跳跃游戏”变种给定一个非负整数数组初始位置在第一个下标每个元素代表你在该位置可以跳跃的最大长度判断能否到达最后一个下标。如果只是判断能否到达用贪心就够了维护一个最远可达位置max_reach 遍历每个位置i 如果i max_reach说明到不了当前位置返回false 更新max_reach max(max_reach, i nums[i]) 如果最后max_reach 数组长度-1返回true这种题考察的核心不是算法本身有多难而是你是否能想到用“动态更新最远可达距离”替代DFS或BFS。很多同学一开始会想用递归最后超时了才意识到该用贪心。笔试时间有限遇到这种“找最值、判断可达性”的题第一时间就该往贪心或动态规划上靠。写代码时还要注意输入输出格式。在线笔试平台牛客、赛码之类通常要求自己处理输入不同题目可能是单行输入也可能是多行测试用例。我的习惯是先写一个处理单组输入的版本再考虑是否要用while循环读入多组。很多同学不是不会算法而是卡在readline的处理上白白丢了分。3.3 手写代码与IDE环境的差异提前适应笔试环境一般没有自动补全甚至有的平台连本地编译都不让这就很考验“裸写代码”的功底。我在准备阶段做了个训练不用IDE直接用纯文本编辑器或者在线笔试平台的模拟环境写代码写完再复制到本地编译跑测试用例。这个过程一定要做不然上考场会发现连string头文件都忘记include。另外笔试时看清楚平台对“函数式提交”和“ACM式提交”的要求。函数式提交只需要你补全核心函数ACM式则要求你自己定义输入输出。两者的编码方式差别很大建议提前上牛客或LeetCode的“笔试模式”里练几道题。4. SQL与数据库报表公司笔试的隐藏重头戏4.1 必考SQL类型分组统计、多表关联与子查询我之前说过报表工具厂商的笔试里SQL是重头戏。A卷的SQL题通常会给出若干张表要求你写出某个查询结果。高频考点包括GROUP BY和HAVING组合使用多表JOIN内连接、左连接和子查询的取舍WHERE和HAVING的执行顺序聚合函数SUM、COUNT、MAX、MIN配合CASE WHEN做条件统计这些考点如果只看语法书会觉得简单但一旦结合具体表结构很多人就会忽略“去重”“NULL值”这些细节。比如统计每个部门的员工数如果员工表的dept_id存在NULLCOUNT(*)和COUNT(dept_id)的结果就会不一样这在实际报表中非常关键。4.2 典型题目查询每个部门工资最高的员工A卷里出现过一道非常经典的表结构题大意是员工表employee包含员工ID、姓名、部门ID、工资部门表department包含部门ID、部门名称要求查询每个部门中工资最高的员工姓名和工资。第一种写法是用相关子查询SELECT d.dept_name, e.emp_name, e.salary FROM employee e JOIN department d ON e.dept_id d.dept_id WHERE e.salary ( SELECT MAX(salary) FROM employee e2 WHERE e2.dept_id e.dept_id );第二种写法是用窗口函数逻辑更清晰性能也往往更好SELECT dept_name, emp_name, salary FROM ( SELECT d.dept_name, e.emp_name, e.salary, ROW_NUMBER() OVER(PARTITION BY e.dept_id ORDER BY e.salary DESC) AS rn FROM employee e JOIN department d ON e.dept_id d.dept_id ) t WHERE rn 1;这里有两个要点一是如果同一个部门里有多个员工工资并列第一用ROW_NUMBER()会只保留一个用RANK()或DENSE_RANK()才能保留多个笔试时要看清题目问的是“一个”还是“所有”二是很多在线笔试平台默认的MySQL版本较低可能不支持窗口函数这时候就写相关子查询版本更稳妥。4.3 报表场景SQL行列转换与同比环比帆软的业务核心是报表所以笔试里还有一类贴近业务的SQL题给定订单表包含订单日期、地区、销售金额要求按月统计销售总额并输出每个月的同比或环比数据。这种题的关键是日期函数的使用。比如按“年-月”格式化字段SELECT DATE_FORMAT(order_date, %Y-%m) AS month, SUM(amount) AS total_amount FROM orders GROUP BY DATE_FORMAT(order_date, %Y-%m) ORDER BY month;如果要算环比可以和上一期的数据做自关联或者用LAG窗口函数。在MySQL 8.0中LAG(SUM(amount)) OVER (ORDER BY month)就能拿到上个月的值。这类题不仅考SQL语法更考“能不能理解业务指标的计算逻辑”和报表研发的日常工作非常贴近。4.4 SQL优化索引失效与慢查询排查除了写SQLA卷里还有简答题比如“某条查询很慢你会怎么排查”。回答这类问题要分几步走先用EXPLAIN查看执行计划确认是否走了索引还是全表扫描。检查WHERE条件里的字段是否有索引函数操作、隐式类型转换、前导通配符都是导致索引失效的常见原因。看看是否返回了过多字段有时候SELECT *会把不需要的大字段也捞出来。数据量级大时考虑分页、缓存或汇总表。我的经验是回答优化问题时不要只背“索引失效”那几条最好能结合场景说明排查过程。比如“先看慢查询日志定位SQL再用EXPLAIN看扫描行数然后看有没有没必要的大字段返回”这样会让面试官觉得你真的处理过线上问题。5. 场景设计题报表工具研发眼中的“业务题”5.1 高频场景权限控制、大报表加载慢、多部门共用模板场景设计题是A卷里最“活”的部分通常没有标准答案但回答得有没有逻辑一眼就能看出来。我梳理几个高频方向。权限控制题目常描述成“一个企业有多个部门不同部门的人只能看自己部门的数据部门经理能看整个部门的数据公司领导能看到所有数据怎么设计权限体系”。这其实是典型的行级权限问题。可以设计“用户表 角色表 数据权限规则表”用户关联角色角色关联数据规则规则里用SQL片段或部门ID集合限制可见行。报表在取数时动态拼接权限条件底层是“权限过滤下推”而不是查完再过滤。大报表加载慢有一类问题是“一张报表关联了5张表数据量千万级每次打开要几十秒怎么优化”。我会从四个层面回答数据源层面看能不能在数据库里先做好聚合或者建中间汇总表报表层面开启分批取数、按需加载首屏只渲染前100行缓存层面对很少变化的数据做定时缓存架构层面如果并发高考虑读写分离和查询集群。这种“分层优化”的回答方式最能体现工程思维。多部门共用模板这种情况在帆软这种报表工具的使用场景中非常常见。同一个模板不同部门填不同的数据最终汇总。这就要考虑模板参数化设计、填报权限和提交校验逻辑。笔试题目往往会简化成“你怎么设计一张支持多部门填报的报表”回答时需要先明确填报流程再设计表和报表参数最后考虑并发提交时的数据一致性。5.2 开放题应答框架需求理解、约束识别、方案落地、风险评估很多同学看到设计题就发怵觉得无从下手。其实可以用一个相对固定的框架来组织回答需求理解用自己的话复述一遍题目确认要解决的核心问题是什么。约束识别指出数据量、并发量、实时性要求、可维护性等约束条件。方案设计给出分层、分模块的解决方案尽量具体到表结构、接口或机制。风险评估主动说出方案的不足以及后续如何演进。比如回答权限设计题时说完用户-角色-数据规则后可以补一句“这种方案在规则数量特别多时拼接SQL会产生较长的WHERE条件需要测试对查询性能的影响后续可以考虑把规则缓存到Redis”。这样做并不是画蛇添足而是展示你有全局观和风险意识。6. 时间分配与备考策略来自过来人的实操建议6.1 笔试现场的时间分配参考A卷题的总体量不算大但不代表写得完。我建议按“先易后难、分值优先”的策略来分配时间拿到卷子先花1到2分钟扫一遍全部题目标记出明显会做的、需要思考的、基本没思路的。先把基础选择题和填空题快速做完遇到犹豫的题做个标记不要死磕控制在20分钟以内。算法编程题每道给15到20分钟。如果10分钟还没思路先写下暴力解法的代码至少能通过一部分用例然后再想优化。SQL题看起来不难但手写容易漏条件建议每题留10分钟左右写完检查一遍GROUP BY和JOIN条件。场景设计题放最后用前面说的应答框架组织语言写清楚要点即可不需要长篇大论。这个时间分配不是死规则但核心思想是不要在单题上恋战笔试是通过性考试多拿一分是一分。6.2 知识盲点自查清单结合这份A卷的特点我整理了一份考前自查清单你可以对照着打勾[ ] Java/C的语法基础字符串、集合、异常处理、内存模型[ ] 数据结构数组、链表、栈、队列、二叉树、哈希表[ ] 高频算法排序、二分查找、快慢指针、滑动窗口、贪心、简单DP[ ] SQL语法JOIN、GROUP BY、HAVING、子查询、窗口函数[ ] SQL优化索引失效场景、EXPLAIN执行计划、慢查询排查[ ] 场景设计权限设计、报表性能优化、多部门填报、缓存机制[ ] 笔试环境输入输出处理、函数式提交与ACM式提交的切换如果你能把这七项都过一遍本身就是一个完整的知识梳理过程。没必要追求每个知识点都精通但至少要做到“看到题知道在考什么”。6.3 笔试之外同样重要的细节简历与投递时机笔试只是校招的一环最终能不能拿到Offer还取决于简历筛选、面试表现和沟通能力。就春招而言时间窗口比较短很多时候是补录所以投递时机很关键。建议早投、多投不要等所有题刷完再投边投边刷反而效率更高。简历上如果写了熟悉报表工具或参与了数据可视化项目面试官大概率会在笔试后追问相关细节所以简历里的每一句话都要能展开讲。尤其注意帆软是国产报表龙头之一如果你在简历里提过FineReport或FineBI至少要把“用它们做过什么、遇到什么问题、怎么解决”说清楚。在写代码和SQL时我也建议养成写注释和格式化输出的习惯笔试平台虽然只看结果但面试官回看代码时清晰的变量命名和简洁的逻辑结构会留下好印象。最后说一点个人体会笔试复盘比刷题更重要。每次做完一套题把错题和犹豫题整理成考点清单两周后再翻一遍效果远好于漫无目的地刷下去。这份A卷复盘最大的价值不在一道题的解法而在于帮你摸清“研发岗笔试题到底在测什么”。弄明白了这一点不管下次面对的是哪家的卷子都能从容不少。