1. 投完简历后收到的笔试链接基础平台研发岗到底要考什么每年秋招一到大家最焦虑的事情往往是简历投出去之后石沉大海而我这次比较幸运投完好未来基础平台研发岗之后大概一周左右就收到了笔试邀请邮件。说实话看到基础平台研发岗这几个字我是有点忐忑的——因为基础平台这个名字听起来很宽泛既不像算法岗那样明确考模型和论文也不像纯业务后端那样简单粗暴地考CRUD和框架八股。我担心的是它会不会考一堆底层源码、内核原理、甚至编译原理这类偏研究的东西。在准备之前我首先做了一件事把岗位JD翻来覆去看了好几遍。好未来这个基础平台研发岗结合我搜集到的公开信息最核心的几个关键词是高并发、分布式、中间件、容器化、DevOps、稳定性建设。再结合好未来本身的业务场景——教育科技公司有大量在线课堂、直播互动、课后练习、内容分发这类业务平台侧核心任务就是支撑这些业务系统的底层基础设施。换句话说这个岗位的笔试不会只考纯算法而是算法计算机基础工程能力三者结合。它希望招到的人既能写明白代码又懂底层原理还能对线上系统稳定性有直觉。这个定位和纯后端开发岗笔试还是有明显区别的具体区别后面我详细拆。我的整体判断是好未来基础平台研发岗的笔试重点考察的是候选人有没有平台视角。什么意思就是你能不能站在基础组件、公共服务的角度思考问题而不是只关注某个业务接口怎么实现。2. 笔试时间分配与题目结构两个小时里最容易被忽略的策略问题好未来秋招笔试通常是限时完成以我看到的公开讨论和往年经验来看一般是90分钟到120分钟这个区间题型结构大致是单选题/多选题、简答题、编程题三个部分。这里我要先说一个很多人容易忽略的问题**笔试并不是从看到题目的那一刻才开始计时的而是从你打开笔试链接、阅读考试说明、调试代码环境的那一刻就已经在消耗时间了。**所以时间分配策略非常重要不要总觉得我写得快没问题。我当时给自己定了一个大致的节奏选择题部分控制在25-30分钟以内。这部分主要是计算机基础包括操作系统、网络、数据库、Linux、分布式基础这些。大部分题是概念题和场景分析题如果一道题超过2分钟还没思路果断标记跳过不要恋战。简答题部分控制在20-25分钟以内。这类题通常考察的是系统设计思路、问题排查思路需要写文字。注意简答题不是写作文不需要长篇大论但必须逻辑清晰、分点明确。我当时给自己定的原则是每道简答控制在10-15行以内核心是让阅卷人一眼看出你的思路框架。编程题部分留下至少40-50分钟。编程题一般是2道左右难度分布通常是一道中等偏易一道中等偏难偶尔会有hard。这部分是区分度最大的地方一定要保证有充足时间读题、思考、编码和自测。有同学可能会问选择题我能不能蒙我的建议是**完全不会的可以蒙但会一半的必须推理。**基础平台岗笔试的选择题很多都是给定一个场景选正确答案这种题用排除法往往比直接背知识点更有效。另外还有一个非常实际的建议**提前把编程环境熟悉好。**好未来笔试用的是牛客网这类在线评测系统你不仅要熟悉代码编辑器的操作还要提前确认自己最顺手的语言。千万别在笔试过程中才发现我本来想用C写但编译器版本不支持某个特性这种低级问题。3. 编程题复盘基础平台视角下的算法考察侧重点编程题永远是笔试的重头戏但基础平台研发岗的编程题和纯算法岗的编程题有本质区别。纯算法岗可能会考一些复杂的动态规划、数学推导、图论高级算法而基础平台岗更偏向于用常见算法解决实际工程场景中的问题。我结合对笔试题目风格的观察和拆解整理了三个高频考察方向3.1 字符串处理和文本解析比想象中更重要在线教育平台有大量文本相关场景课程内容清洗、日志解析、敏感词过滤、用户行为埋点解析等等。所以字符串类题目在笔试中出现频率很高。常见的考察方式包括给定一段日志字符串要求提取特定字段并排序给定两个字符串判断是否为同源异构词或者实现一个简单的模板解析器把{name}这样的占位符替换成对应的值。这类题本身不难但有几个坑要注意边界条件空字符串、超长字符串、特殊字符、Unicode字符。我见过很多人在这类题上栽跟头不是思路不会而是没考虑空串和单字符的情况。时间复杂度如果要求处理超长文本朴素的双重循环大概率超时。比如判断两个字符串是否为变位词用排序是O(nlogn)用哈希表计数是O(n)笔试场景下尽量选O(n)的做法。内存占用不要动辄new一个很大的二维数组尤其在牛客网这种环境下内存超限也是会判失败的。3.2 区间合并与调度类问题对应平台层的资源管理场景基础平台必然会涉及资源调度任务队列、定时任务、容器资源分配、机房容灾切换等等。这些场景映射到算法题上就是区间合并、会议室预定、任务调度、贪心策略这一类。比如给定若干个任务的开始时间和结束时间问至少需要多少台机器才能避免冲突。这个题本质上是最多同时重叠的区间数用扫描线或者最小堆都能解决。再比如给出一组日志的起止时间范围要求合并所有重叠区间输出合并后的区间列表。这个题考察的是排序遍历本身不难但考察你对连续边界的处理——[1,4]和[4,5]算不算重叠通常按题意理解边界相接触也算重叠需要合并但还是要看具体题目的定义。这类题我个人的经验是**拿到题先想清楚边界条件再动手写代码。**区间类题最怕的是边界处理不好导致结果差之毫厘谬以千里。3.3 设计数据结构从LRU到带过期时间的缓存基础平台岗的笔试中设计一个数据结构这类题出现概率极高。原因很简单平台层最核心的工作之一就是缓存、存储和索引而这些底层能力往往需要手写数据结构来验证候选人的功底。最常见的几类LRU缓存要求实现get和put操作时间复杂度O(1)。这几乎是标配题目用哈希表双向链表实现。我建议每个人都在笔试前至少手写两遍这道题不仅要会写还要能解释清楚为什么每次访问节点要移动到链表头部为什么淘汰时要删除尾部节点。LFU缓存相对LRU复杂一些需要维护每个key的使用频率并在容量满时淘汰频率最低的key。实现思路可以用频率到桶的映射或者最小堆哈希表但要注意同频率下的淘汰顺序。带过期时间的缓存这个更贴近业务场景需要额外维护每个key的过期时间在get的时候判断是否已过期并考虑是否需要惰性删除。我在准备阶段把LRU手写了至少五遍每一遍都会刻意不参考模板从零开始推导。因为这类题在笔试里一旦遇到代码量不算大但细节很多任何一个指针操作漏了都可能导致死循环或空指针异常。还有一类值得关注的是前缀树Trie。好未来有大量内容检索、关键词匹配、课程标签场景前缀树用于敏感词匹配、自动补全、搜索建议非常合适。笔试中可能会让你实现一个支持insert、search、startsWith的Trie或者更进一步实现敏感词过滤的核心逻辑。4. 操作系统与网络基础平台岗笔试选择题的高频分水岭选择题部分最大的分水岭通常不在数据结构而在操作系统和网络。这两个科目对于业务后端开发来说很多时候被当成背八股来处理但基础平台岗笔试考得更细更偏向出故障时你能不能定位。4.1 进程、线程与协程的底层差异选择题经常出现的形式是进程和线程的区别、上下文切换的开销来源、协程和线程的关系。这几个概念看似基础但很多人的理解停留在表面。举个例子进程切换为什么比线程切换开销大很多人会回答因为进程有独立地址空间切换需要切换页表。这个说法对但不完整。进程切换不仅涉及页表切换还涉及TLB快表失效、进程上下文寄存器、程序计数器、栈指针的保存与恢复、调度器的调度决策、可能涉及的缓存局部性损失等等。线程切换虽然不需要切换地址空间但用户态线程与内核态线程的切换依然有系统调用开销。我建议大家复习的时候不要只背结论要顺着为什么往下想一层。比如为什么协程被称为用户态线程因为它不需要内核参与调度直接由用户态程序自行控制切换所以切换开销比线程小一个数量级。但协程也有代价——如果一个协程中发生了阻塞式系统调用整个线程都会被阻塞所以引入协程库通常需要同时配合异步IO使用。4.2 网络协议不只看三次握手四次挥手基础平台岗笔试对网络的考察深度往往超过三次握手为什么是三次这类基础题更常见的是这些方向TCP拥塞控制与滑动窗口给定场景问拥塞窗口会怎么变化慢启动阶段如果在某个窗口大小出现丢包会进入拥塞避免还是快速重传。这类题需要理解拥塞控制的状态机而不是死记阈值数值。HTTP/HTTPS与负载均衡一个请求从客户端发出到后端处理完成经过哪些层四层负载均衡和七层负载均衡分别工作在OSI模型的哪一层各自有什么优劣HTTPS握手过程中证书校验发生在哪一步。连接池与超时配置一次完整的请求可能涉及连接超时、读取超时、写入超时。如果服务端处理时间较长但连接已经建立了客户端应该设置哪个超时如果服务端宕机了客户端什么情况下会感知到连接异常这些都是真实的平台开发会遇到的网络场景笔试选择题里会以线上服务出现大量TIME_WAIT连接以下哪个处理方式最合理这类问法出现。4.3 Linux与排查命令笔试中直接被考查的平台工程师基本功基础平台研发岗和纯业务研发岗在笔试上的另一个区别是Linux实操类题目的占比更高。选择题里经常出现这样一些问题某个进程CPU占用率过高要用哪个命令定位到具体线程系统负载很高但CPU使用率不高可能是什么原因磁盘IO出现瓶颈用iostat看哪些指标查看某个端口是否被监听的命令是什么线上出现大量的TIME_WAIT通过哪个内核参数调整复用策略这些题基本没有太多花哨的技巧就是考察你是不是真的在服务器上干过活。如果你平时开发都是在Windows上没怎么接触过Linux这部分会很吃亏。我的建议是**准备秋招前至少在自己的电脑上装一个Linux虚拟机或者用云服务器跑起来把CPU、内存、磁盘、网络这四类的排查命令都用一遍。**不要只背命令要理解输出指标的含义。比如free -h里buff/cache那一列怎么理解top里wa指标高说明什么只有真正在系统上跑过、观察过笔试遇到这类题才不会懵。5. 数据库题从索引原理到事务隔离级别平台岗比业务岗问得更底层数据库是任何后端岗位笔试都绕不开的部分但基础平台研发岗在数据库问题上考察角度会往底层偏一些。业务岗可能问你这个SQL为什么慢怎么优化平台岗更可能问为什么这个索引能加速查询底层数据结构是什么什么情况下索引会失效。5.1 索引底层原理B树考察已经是标配选择题里最常见的是为什么关系型数据库的索引底层用B树而不是红黑树或哈希表。这个题你得能从三个方面答透磁盘IO局部性和磁盘预读的机制决定了树的高度要尽量低而B树的出度分叉数很大三到四层就可以存储千万级数据。B树的数据都存储在叶子节点并且叶子节点通过链表相连所以范围查询非常高效。红黑树虽然也是平衡树但它本质是二叉树高度比B树高很多对于磁盘存储来说IO次数不可接受。哈希表则只能做等值查询无法做范围查询和排序。如果笔试里有一道选择题说以下关于B树描述错误的是常见的错误选项可能是B树的非叶子节点也存储数据——记住非叶子节点只存索引键和子节点指针不存数据。5.2 事务隔离级别与MVCC别只会背四个级别事务这块选择题考察频率极高尤其是四种隔离级别和它们对应的并发问题。很多同学能背出读未提交、读已提交、可重复读、串行化以及对应的脏读、不可重复读、幻读但一旦题目改成在可重复读隔离级别下一个事务中两次查询返回的行数不同可能是什么原因还是会有人答错。这个问题的正确答案很关键**在MySQL InnoDB的可重复读隔离级别下通过MVCC解决了普通快照读的幻读问题但当前读如SELECT ... FOR UPDATE依然可能产生幻读。**所以题目问两次查询返回行数不同如果两次都是普通快照读理论上不应该出现幻读但如果第二次是当前读则可能读到其他事务最新提交的数据导致行数变化。很多平台岗笔试会选择InnoDB默认隔离级别是什么以及可重复读下如何解决幻读这类题。复习时最好把MVCC的版本链、ReadView的生成时机、当前读与快照读的区别都理一遍只背结论很容易在换一个问法时翻车。5.3 缓存与数据库一致性问题笔试简答题的热门方向前面说了好未来基础平台岗笔试有简答题数据库与缓存一致性这类题在简答中出现频率极高。因为它太贴近实际业务了平台提供公共服务上游业务方可能依赖缓存加速访问同时又要保证数据最终一致。我的思路框架是这样的先明确缓存更新策略Cache Aside、Read Through、Write Through、Write Behind Caching各有什么优缺点。笔试中最常讨论的是Cache Aside策略。分析Cache Aside中存在的经典问题先更新数据库再删除缓存。这里有一个并发时序问题线程A先更新数据库线程B读缓存未命中后读库旧数据并回填缓存然后线程A删除缓存最后缓存里又是旧数据。给出解法和权衡延时双删更新后延迟一段时间再删一次缓存、订阅数据库binlog异步删除缓存、设置适当的缓存过期时间来兜底。但每个方案都有代价你要在简答里说清楚为什么选择某个方案。简答题不是让阅卷人看到你背过标准答案而是看到你在实际工程约束下能做出合理取舍。比如延迟双删的延迟多久怎么定这个时间要大于一次读请求回填缓存的最长耗时否则会出现删早了旧数据重新回填的问题。能写出这一层说明你是真的思考过。6. 分布式与中间件基础选择题和简答题里最拉开差距的部分基础平台研发岗笔试和普通后端笔试最大的区别我认为就在分布式和中间件这一块。虽然笔试阶段不会让你写实际系统但选择题和简答题会大量覆盖这些内容主要为了筛选出有平台视角的人。6.1 负载均衡与会话保持考题常见形式四层负载均衡如LVS、F5和七层负载均衡如Nginx、HAProxy的区别是什么某服务做了水平扩展部署了多个实例客户端首次请求落在实例A并登录成功第二次请求落在实例B结果登录态失效如何解决Session共享的常见方案有哪些这类题最该注意的是**不要只背Nginx的配置要能从高可用、可扩展的角度思考。**比如Session共享可以考虑把Session集中存到Redis但需要考虑Redis的可用性和序列化方式也可以用JWT这类无状态token方案把状态放在客户端实现真正的无状态服务但这又引入token失效控制和安全性问题。答简答或做选择时要能权衡这些方案。6.2 消息队列从基础概念到可靠性保障消息队列在基础平台中扮演的角色很重解耦、削峰、异步化。笔试中经常考察消息队列怎么保证消息不丢失要从生产者、Broker、消费者三个环节分别回答。消息队列怎么保证消息不重复消费引入消费幂等性设计。如何实现消息的顺序性比如同一个订单的多个消息必须按顺序处理。最经典的一道简答题是设计一个可靠的消息队列方案需要保证消息不丢失且尽可能不重复。回答思路是生产者端使用带确认机制的发送确认收到后才算发送成功Broker端通过持久化副本机制保证数据不丢消费者端消费完成后才提交offset。对于消息重复问题消费端要做幂等比如数据库唯一索引、Redis setnx、状态机约束等。这个问题考察的不是你用过哪个MQ而是你对分布式系统可靠性的理解。6.3 分布式锁Redis实现与ZooKeeper实现的对比分布式锁是平台岗笔试的高频考点无论是选择题还是简答题都可能出现。最常见的问法用Redis实现分布式锁怎么避免锁超时导致并发问题Redis分布式锁和ZooKeeper分布式锁各自的优劣RedLock算法是什么它解决了什么问题我建议复习的时候重点理解Redis分布式锁的边界问题。比如线程A拿到锁执行时间过长锁自动过期了线程B拿到锁此时线程A执行完手动释放锁把线程B的锁释放了。解决办法是在value中存一个唯一标识释放锁时先比较是否是自己的锁再删除。但这个比较删除要保证原子性必须用Lua脚本。能答到这一层说明你对分布式锁的工程细节是真正有概念的。6.4 容器化与云原生基础平台不能回避的方向从公开信息看好未来的基础平台研发涉及容器化、K8s等方面所以在笔试中出现相关内容是很可能的。常见考点包括Docker镜像分层和容器文件系统的关系K8s中的Pod、Deployment、Service之间的区别容器优雅退出和Pod优雅终止怎么实现HPA水平Pod自动伸缩的触发原理选择题里如果出现容器和虚拟机的区别答案要围绕共享内核和资源隔离的粒度展开而不是简单说容器更快。容器共享宿主机内核隔离性弱于虚拟机但启动速度更快、资源利用率更高。这个共享内核的特性带来了两个问题一是内核漏洞会影响所有容器二是容器内无法运行与宿主机内核不同的操作系统。简答题可能会让你描述一个服务从代码提交到K8s集群上运行经历了哪些关键步骤。这道题考察的是对整个DevOps/CI/CD链路是否有全局认识。我的回答框架是代码提交触发CI流水线编译打包成镜像推送到镜像仓库更新部署清单K8s中的控制器比对期望状态和实际状态调度器分配节点kubelet拉取镜像并启动容器就绪探针检查通过后接入Service负载均衡完成滚动发布。7. 换一个准备方式我从这次笔试中总结的备考重心和方法准备基础平台研发岗不能像准备普通后端岗那样只刷LeetCode和背八股要更有针对性。我根据自己的经历把准备重心分为四个阶段分享出来供大家参考7.1 算法题按题型模块化刷而不是按题号刷我把刷题分成了几个模块字符串处理、区间与调度、数据结构设计、二叉树、动态规划基础、贪心。每个模块刷15-20道就够了关键是每道题做完后要总结思路范式。比如区间类题几乎是先排序再扫描/堆处理两步走数据结构设计类题先考虑需要支持哪些操作和每个操作的时间复杂度要求。每天保持2-3道题的节奏坚持三到四周比考前突击刷300道更有效。7.2 计算机基础以排查问题为主线串联知识点复习操作系统、网络、Linux时我采取的是排查问题场景驱动的方式每复习一个模块就假设自己在线上遇到一个故障需要从头到尾排查。比如服务变慢load average高居不下CPU使用率不高——是不是IO等待结合iostat、vmstat查看。客户端大量请求超时服务端连接数飙升——是连接泄漏还是流量过大用ss、netstat查看连接状态。TIME_WAIT过多怎么办调整net.ipv4.tcp_tw_reuse和tcp_fin_timeout等参数是否合理内存持续增长疑似泄漏——怎么样用jmap或gdb观察堆内存变化要不要做heap dump用这种方式复习知识点不再是孤立的而是串成了一条故障排查链路笔试考任何一环你都能快速定位上下文。7.3 简答题准备框架层次的答题模板简答题最怕答得很散没有层次感。我个人的答题模板是三层结构论点先行第一句话直接给出结论或解决方案的核心思路。分点阐述从2到4个角度展开每个角度控制3到5行。比如从生产者角度……从消费者角度……从整体架构角度……。关键细节在最后补充一两个工程细节比如这里要注意释放锁时必须使用Lua脚本保证原子性。简答题不是写论文不需要面面俱到但要让阅卷人一眼看出你有系统化的思考能力。我把可能考的简答题大概整理了20道左右每道题都按这个模板写了提纲反复背诵并默写笔试时遇到同类问题基本可以快速成文。7.4 好未来业务场景从公开信息反推平台技术方向准备笔试的时候不要只盯着技术本身也花点时间了解一下公司的业务和技术体系。好未来是教育科技公司主营业务覆盖在线直播大班课、小班课、AI互动课、学习工具类产品。这些业务有几个共同特点直播场景有大量实时音视频传输和互动消息对延迟和稳定性要求高高峰时段比如晚间的课程集中时段流量波动大需要很强的弹性扩缩容能力线上线下结合的课程形态意味着需要统一的内容管理、用户体系、订单系统基础平台来支撑有大量数据积累数据平台和数据服务能力也很重要基础平台研发岗要做的就是把这些通用能力——服务框架、配置中心、网关、消息队列、缓存、容器平台、监控系统——搭建好、维护好让上层的业务研发可以专注于业务逻辑。我在笔试前专门花了一些时间思考如果我是这个平台岗的面试官我会期望候选人理解什么答案是**候选人不仅要会用某个中间件还要理解为什么平台层要提供这个中间件以及它在整体架构中扮演什么角色。**带着这个思维去做题很多选择题的最合理答案就变得清晰了。8. 笔试当天的一些细节环境、心态和白板代码的稳定性最后再分享一些笔试当天的注意事项这些看似细枝末节实际上很影响发挥。第一选择一个网络稳定、环境安静的地方。笔试全程在线监控中途断网会非常被动。建议提前一天测试摄像头、麦克风、浏览器兼容性不要用过于小众的浏览器。我在笔试前特意用Chrome做了一次模拟测试确认代码编辑器、自动缩进、补全功能都正常这才放心。第二编程题不管难度如何先读题、再分析、后编码最后自测。很多同学一上来就写代码写到一半发现理解错了题意白白浪费大量时间。我做编程题的习惯是前三分钟纯读题和思考把输入输出样例在草稿纸上推演一遍确认理解了边界条件再动手。如果用时超过20分钟还没有头绪果断先跳过做完其他题目再回来——往往换个脑子之后思路就通了。第三注意控制心态。笔试中遇到不会的题非常正常不要因为一道选择题卡住就慌了。好未来这类大厂校招笔试题量通常不小本来就是设计成大多数人都做不完的目的是看你在有限时间内的优先级判断和得分能力。只要保证会做的都拿到分不会的不恋战结果通常不会差。第四笔试结束前一定要留出三五分钟检查。检查的内容包括选择题是否有未作答的没把握的也可以先填一个不要空着编程题的代码是否有明显编译错误代码里是否有多余的调试输出比如print函数名和输入输出格式是否完全符合题目要求。尤其是在牛客网这类平台上输出格式和题目要求不一致哪怕代码逻辑全对评分也可能是0分。关于笔试通过后进入面试的衔接我个人的体会是笔试更像是门槛型筛选真正决定offer去留的是技术面和HR面。所以笔试结束后如果感觉还可以就要尽快把笔试中没答好的题目复盘一遍把不会的地方补齐——因为这些点很可能就是后续面试官追问的方向。比如笔试里遇到一道不熟的分布式锁题面试前一定要彻底搞懂RedLock的原理和缺陷面试官大概率会顺着简历和笔试来深挖。 基础平台研发岗笔试攻略：从算法到分布式的核心考点解析
1. 投完简历后收到的笔试链接基础平台研发岗到底要考什么每年秋招一到大家最焦虑的事情往往是简历投出去之后石沉大海而我这次比较幸运投完好未来基础平台研发岗之后大概一周左右就收到了笔试邀请邮件。说实话看到基础平台研发岗这几个字我是有点忐忑的——因为基础平台这个名字听起来很宽泛既不像算法岗那样明确考模型和论文也不像纯业务后端那样简单粗暴地考CRUD和框架八股。我担心的是它会不会考一堆底层源码、内核原理、甚至编译原理这类偏研究的东西。在准备之前我首先做了一件事把岗位JD翻来覆去看了好几遍。好未来这个基础平台研发岗结合我搜集到的公开信息最核心的几个关键词是高并发、分布式、中间件、容器化、DevOps、稳定性建设。再结合好未来本身的业务场景——教育科技公司有大量在线课堂、直播互动、课后练习、内容分发这类业务平台侧核心任务就是支撑这些业务系统的底层基础设施。换句话说这个岗位的笔试不会只考纯算法而是算法计算机基础工程能力三者结合。它希望招到的人既能写明白代码又懂底层原理还能对线上系统稳定性有直觉。这个定位和纯后端开发岗笔试还是有明显区别的具体区别后面我详细拆。我的整体判断是好未来基础平台研发岗的笔试重点考察的是候选人有没有平台视角。什么意思就是你能不能站在基础组件、公共服务的角度思考问题而不是只关注某个业务接口怎么实现。2. 笔试时间分配与题目结构两个小时里最容易被忽略的策略问题好未来秋招笔试通常是限时完成以我看到的公开讨论和往年经验来看一般是90分钟到120分钟这个区间题型结构大致是单选题/多选题、简答题、编程题三个部分。这里我要先说一个很多人容易忽略的问题**笔试并不是从看到题目的那一刻才开始计时的而是从你打开笔试链接、阅读考试说明、调试代码环境的那一刻就已经在消耗时间了。**所以时间分配策略非常重要不要总觉得我写得快没问题。我当时给自己定了一个大致的节奏选择题部分控制在25-30分钟以内。这部分主要是计算机基础包括操作系统、网络、数据库、Linux、分布式基础这些。大部分题是概念题和场景分析题如果一道题超过2分钟还没思路果断标记跳过不要恋战。简答题部分控制在20-25分钟以内。这类题通常考察的是系统设计思路、问题排查思路需要写文字。注意简答题不是写作文不需要长篇大论但必须逻辑清晰、分点明确。我当时给自己定的原则是每道简答控制在10-15行以内核心是让阅卷人一眼看出你的思路框架。编程题部分留下至少40-50分钟。编程题一般是2道左右难度分布通常是一道中等偏易一道中等偏难偶尔会有hard。这部分是区分度最大的地方一定要保证有充足时间读题、思考、编码和自测。有同学可能会问选择题我能不能蒙我的建议是**完全不会的可以蒙但会一半的必须推理。**基础平台岗笔试的选择题很多都是给定一个场景选正确答案这种题用排除法往往比直接背知识点更有效。另外还有一个非常实际的建议**提前把编程环境熟悉好。**好未来笔试用的是牛客网这类在线评测系统你不仅要熟悉代码编辑器的操作还要提前确认自己最顺手的语言。千万别在笔试过程中才发现我本来想用C写但编译器版本不支持某个特性这种低级问题。3. 编程题复盘基础平台视角下的算法考察侧重点编程题永远是笔试的重头戏但基础平台研发岗的编程题和纯算法岗的编程题有本质区别。纯算法岗可能会考一些复杂的动态规划、数学推导、图论高级算法而基础平台岗更偏向于用常见算法解决实际工程场景中的问题。我结合对笔试题目风格的观察和拆解整理了三个高频考察方向3.1 字符串处理和文本解析比想象中更重要在线教育平台有大量文本相关场景课程内容清洗、日志解析、敏感词过滤、用户行为埋点解析等等。所以字符串类题目在笔试中出现频率很高。常见的考察方式包括给定一段日志字符串要求提取特定字段并排序给定两个字符串判断是否为同源异构词或者实现一个简单的模板解析器把{name}这样的占位符替换成对应的值。这类题本身不难但有几个坑要注意边界条件空字符串、超长字符串、特殊字符、Unicode字符。我见过很多人在这类题上栽跟头不是思路不会而是没考虑空串和单字符的情况。时间复杂度如果要求处理超长文本朴素的双重循环大概率超时。比如判断两个字符串是否为变位词用排序是O(nlogn)用哈希表计数是O(n)笔试场景下尽量选O(n)的做法。内存占用不要动辄new一个很大的二维数组尤其在牛客网这种环境下内存超限也是会判失败的。3.2 区间合并与调度类问题对应平台层的资源管理场景基础平台必然会涉及资源调度任务队列、定时任务、容器资源分配、机房容灾切换等等。这些场景映射到算法题上就是区间合并、会议室预定、任务调度、贪心策略这一类。比如给定若干个任务的开始时间和结束时间问至少需要多少台机器才能避免冲突。这个题本质上是最多同时重叠的区间数用扫描线或者最小堆都能解决。再比如给出一组日志的起止时间范围要求合并所有重叠区间输出合并后的区间列表。这个题考察的是排序遍历本身不难但考察你对连续边界的处理——[1,4]和[4,5]算不算重叠通常按题意理解边界相接触也算重叠需要合并但还是要看具体题目的定义。这类题我个人的经验是**拿到题先想清楚边界条件再动手写代码。**区间类题最怕的是边界处理不好导致结果差之毫厘谬以千里。3.3 设计数据结构从LRU到带过期时间的缓存基础平台岗的笔试中设计一个数据结构这类题出现概率极高。原因很简单平台层最核心的工作之一就是缓存、存储和索引而这些底层能力往往需要手写数据结构来验证候选人的功底。最常见的几类LRU缓存要求实现get和put操作时间复杂度O(1)。这几乎是标配题目用哈希表双向链表实现。我建议每个人都在笔试前至少手写两遍这道题不仅要会写还要能解释清楚为什么每次访问节点要移动到链表头部为什么淘汰时要删除尾部节点。LFU缓存相对LRU复杂一些需要维护每个key的使用频率并在容量满时淘汰频率最低的key。实现思路可以用频率到桶的映射或者最小堆哈希表但要注意同频率下的淘汰顺序。带过期时间的缓存这个更贴近业务场景需要额外维护每个key的过期时间在get的时候判断是否已过期并考虑是否需要惰性删除。我在准备阶段把LRU手写了至少五遍每一遍都会刻意不参考模板从零开始推导。因为这类题在笔试里一旦遇到代码量不算大但细节很多任何一个指针操作漏了都可能导致死循环或空指针异常。还有一类值得关注的是前缀树Trie。好未来有大量内容检索、关键词匹配、课程标签场景前缀树用于敏感词匹配、自动补全、搜索建议非常合适。笔试中可能会让你实现一个支持insert、search、startsWith的Trie或者更进一步实现敏感词过滤的核心逻辑。4. 操作系统与网络基础平台岗笔试选择题的高频分水岭选择题部分最大的分水岭通常不在数据结构而在操作系统和网络。这两个科目对于业务后端开发来说很多时候被当成背八股来处理但基础平台岗笔试考得更细更偏向出故障时你能不能定位。4.1 进程、线程与协程的底层差异选择题经常出现的形式是进程和线程的区别、上下文切换的开销来源、协程和线程的关系。这几个概念看似基础但很多人的理解停留在表面。举个例子进程切换为什么比线程切换开销大很多人会回答因为进程有独立地址空间切换需要切换页表。这个说法对但不完整。进程切换不仅涉及页表切换还涉及TLB快表失效、进程上下文寄存器、程序计数器、栈指针的保存与恢复、调度器的调度决策、可能涉及的缓存局部性损失等等。线程切换虽然不需要切换地址空间但用户态线程与内核态线程的切换依然有系统调用开销。我建议大家复习的时候不要只背结论要顺着为什么往下想一层。比如为什么协程被称为用户态线程因为它不需要内核参与调度直接由用户态程序自行控制切换所以切换开销比线程小一个数量级。但协程也有代价——如果一个协程中发生了阻塞式系统调用整个线程都会被阻塞所以引入协程库通常需要同时配合异步IO使用。4.2 网络协议不只看三次握手四次挥手基础平台岗笔试对网络的考察深度往往超过三次握手为什么是三次这类基础题更常见的是这些方向TCP拥塞控制与滑动窗口给定场景问拥塞窗口会怎么变化慢启动阶段如果在某个窗口大小出现丢包会进入拥塞避免还是快速重传。这类题需要理解拥塞控制的状态机而不是死记阈值数值。HTTP/HTTPS与负载均衡一个请求从客户端发出到后端处理完成经过哪些层四层负载均衡和七层负载均衡分别工作在OSI模型的哪一层各自有什么优劣HTTPS握手过程中证书校验发生在哪一步。连接池与超时配置一次完整的请求可能涉及连接超时、读取超时、写入超时。如果服务端处理时间较长但连接已经建立了客户端应该设置哪个超时如果服务端宕机了客户端什么情况下会感知到连接异常这些都是真实的平台开发会遇到的网络场景笔试选择题里会以线上服务出现大量TIME_WAIT连接以下哪个处理方式最合理这类问法出现。4.3 Linux与排查命令笔试中直接被考查的平台工程师基本功基础平台研发岗和纯业务研发岗在笔试上的另一个区别是Linux实操类题目的占比更高。选择题里经常出现这样一些问题某个进程CPU占用率过高要用哪个命令定位到具体线程系统负载很高但CPU使用率不高可能是什么原因磁盘IO出现瓶颈用iostat看哪些指标查看某个端口是否被监听的命令是什么线上出现大量的TIME_WAIT通过哪个内核参数调整复用策略这些题基本没有太多花哨的技巧就是考察你是不是真的在服务器上干过活。如果你平时开发都是在Windows上没怎么接触过Linux这部分会很吃亏。我的建议是**准备秋招前至少在自己的电脑上装一个Linux虚拟机或者用云服务器跑起来把CPU、内存、磁盘、网络这四类的排查命令都用一遍。**不要只背命令要理解输出指标的含义。比如free -h里buff/cache那一列怎么理解top里wa指标高说明什么只有真正在系统上跑过、观察过笔试遇到这类题才不会懵。5. 数据库题从索引原理到事务隔离级别平台岗比业务岗问得更底层数据库是任何后端岗位笔试都绕不开的部分但基础平台研发岗在数据库问题上考察角度会往底层偏一些。业务岗可能问你这个SQL为什么慢怎么优化平台岗更可能问为什么这个索引能加速查询底层数据结构是什么什么情况下索引会失效。5.1 索引底层原理B树考察已经是标配选择题里最常见的是为什么关系型数据库的索引底层用B树而不是红黑树或哈希表。这个题你得能从三个方面答透磁盘IO局部性和磁盘预读的机制决定了树的高度要尽量低而B树的出度分叉数很大三到四层就可以存储千万级数据。B树的数据都存储在叶子节点并且叶子节点通过链表相连所以范围查询非常高效。红黑树虽然也是平衡树但它本质是二叉树高度比B树高很多对于磁盘存储来说IO次数不可接受。哈希表则只能做等值查询无法做范围查询和排序。如果笔试里有一道选择题说以下关于B树描述错误的是常见的错误选项可能是B树的非叶子节点也存储数据——记住非叶子节点只存索引键和子节点指针不存数据。5.2 事务隔离级别与MVCC别只会背四个级别事务这块选择题考察频率极高尤其是四种隔离级别和它们对应的并发问题。很多同学能背出读未提交、读已提交、可重复读、串行化以及对应的脏读、不可重复读、幻读但一旦题目改成在可重复读隔离级别下一个事务中两次查询返回的行数不同可能是什么原因还是会有人答错。这个问题的正确答案很关键**在MySQL InnoDB的可重复读隔离级别下通过MVCC解决了普通快照读的幻读问题但当前读如SELECT ... FOR UPDATE依然可能产生幻读。**所以题目问两次查询返回行数不同如果两次都是普通快照读理论上不应该出现幻读但如果第二次是当前读则可能读到其他事务最新提交的数据导致行数变化。很多平台岗笔试会选择InnoDB默认隔离级别是什么以及可重复读下如何解决幻读这类题。复习时最好把MVCC的版本链、ReadView的生成时机、当前读与快照读的区别都理一遍只背结论很容易在换一个问法时翻车。5.3 缓存与数据库一致性问题笔试简答题的热门方向前面说了好未来基础平台岗笔试有简答题数据库与缓存一致性这类题在简答中出现频率极高。因为它太贴近实际业务了平台提供公共服务上游业务方可能依赖缓存加速访问同时又要保证数据最终一致。我的思路框架是这样的先明确缓存更新策略Cache Aside、Read Through、Write Through、Write Behind Caching各有什么优缺点。笔试中最常讨论的是Cache Aside策略。分析Cache Aside中存在的经典问题先更新数据库再删除缓存。这里有一个并发时序问题线程A先更新数据库线程B读缓存未命中后读库旧数据并回填缓存然后线程A删除缓存最后缓存里又是旧数据。给出解法和权衡延时双删更新后延迟一段时间再删一次缓存、订阅数据库binlog异步删除缓存、设置适当的缓存过期时间来兜底。但每个方案都有代价你要在简答里说清楚为什么选择某个方案。简答题不是让阅卷人看到你背过标准答案而是看到你在实际工程约束下能做出合理取舍。比如延迟双删的延迟多久怎么定这个时间要大于一次读请求回填缓存的最长耗时否则会出现删早了旧数据重新回填的问题。能写出这一层说明你是真的思考过。6. 分布式与中间件基础选择题和简答题里最拉开差距的部分基础平台研发岗笔试和普通后端笔试最大的区别我认为就在分布式和中间件这一块。虽然笔试阶段不会让你写实际系统但选择题和简答题会大量覆盖这些内容主要为了筛选出有平台视角的人。6.1 负载均衡与会话保持考题常见形式四层负载均衡如LVS、F5和七层负载均衡如Nginx、HAProxy的区别是什么某服务做了水平扩展部署了多个实例客户端首次请求落在实例A并登录成功第二次请求落在实例B结果登录态失效如何解决Session共享的常见方案有哪些这类题最该注意的是**不要只背Nginx的配置要能从高可用、可扩展的角度思考。**比如Session共享可以考虑把Session集中存到Redis但需要考虑Redis的可用性和序列化方式也可以用JWT这类无状态token方案把状态放在客户端实现真正的无状态服务但这又引入token失效控制和安全性问题。答简答或做选择时要能权衡这些方案。6.2 消息队列从基础概念到可靠性保障消息队列在基础平台中扮演的角色很重解耦、削峰、异步化。笔试中经常考察消息队列怎么保证消息不丢失要从生产者、Broker、消费者三个环节分别回答。消息队列怎么保证消息不重复消费引入消费幂等性设计。如何实现消息的顺序性比如同一个订单的多个消息必须按顺序处理。最经典的一道简答题是设计一个可靠的消息队列方案需要保证消息不丢失且尽可能不重复。回答思路是生产者端使用带确认机制的发送确认收到后才算发送成功Broker端通过持久化副本机制保证数据不丢消费者端消费完成后才提交offset。对于消息重复问题消费端要做幂等比如数据库唯一索引、Redis setnx、状态机约束等。这个问题考察的不是你用过哪个MQ而是你对分布式系统可靠性的理解。6.3 分布式锁Redis实现与ZooKeeper实现的对比分布式锁是平台岗笔试的高频考点无论是选择题还是简答题都可能出现。最常见的问法用Redis实现分布式锁怎么避免锁超时导致并发问题Redis分布式锁和ZooKeeper分布式锁各自的优劣RedLock算法是什么它解决了什么问题我建议复习的时候重点理解Redis分布式锁的边界问题。比如线程A拿到锁执行时间过长锁自动过期了线程B拿到锁此时线程A执行完手动释放锁把线程B的锁释放了。解决办法是在value中存一个唯一标识释放锁时先比较是否是自己的锁再删除。但这个比较删除要保证原子性必须用Lua脚本。能答到这一层说明你对分布式锁的工程细节是真正有概念的。6.4 容器化与云原生基础平台不能回避的方向从公开信息看好未来的基础平台研发涉及容器化、K8s等方面所以在笔试中出现相关内容是很可能的。常见考点包括Docker镜像分层和容器文件系统的关系K8s中的Pod、Deployment、Service之间的区别容器优雅退出和Pod优雅终止怎么实现HPA水平Pod自动伸缩的触发原理选择题里如果出现容器和虚拟机的区别答案要围绕共享内核和资源隔离的粒度展开而不是简单说容器更快。容器共享宿主机内核隔离性弱于虚拟机但启动速度更快、资源利用率更高。这个共享内核的特性带来了两个问题一是内核漏洞会影响所有容器二是容器内无法运行与宿主机内核不同的操作系统。简答题可能会让你描述一个服务从代码提交到K8s集群上运行经历了哪些关键步骤。这道题考察的是对整个DevOps/CI/CD链路是否有全局认识。我的回答框架是代码提交触发CI流水线编译打包成镜像推送到镜像仓库更新部署清单K8s中的控制器比对期望状态和实际状态调度器分配节点kubelet拉取镜像并启动容器就绪探针检查通过后接入Service负载均衡完成滚动发布。7. 换一个准备方式我从这次笔试中总结的备考重心和方法准备基础平台研发岗不能像准备普通后端岗那样只刷LeetCode和背八股要更有针对性。我根据自己的经历把准备重心分为四个阶段分享出来供大家参考7.1 算法题按题型模块化刷而不是按题号刷我把刷题分成了几个模块字符串处理、区间与调度、数据结构设计、二叉树、动态规划基础、贪心。每个模块刷15-20道就够了关键是每道题做完后要总结思路范式。比如区间类题几乎是先排序再扫描/堆处理两步走数据结构设计类题先考虑需要支持哪些操作和每个操作的时间复杂度要求。每天保持2-3道题的节奏坚持三到四周比考前突击刷300道更有效。7.2 计算机基础以排查问题为主线串联知识点复习操作系统、网络、Linux时我采取的是排查问题场景驱动的方式每复习一个模块就假设自己在线上遇到一个故障需要从头到尾排查。比如服务变慢load average高居不下CPU使用率不高——是不是IO等待结合iostat、vmstat查看。客户端大量请求超时服务端连接数飙升——是连接泄漏还是流量过大用ss、netstat查看连接状态。TIME_WAIT过多怎么办调整net.ipv4.tcp_tw_reuse和tcp_fin_timeout等参数是否合理内存持续增长疑似泄漏——怎么样用jmap或gdb观察堆内存变化要不要做heap dump用这种方式复习知识点不再是孤立的而是串成了一条故障排查链路笔试考任何一环你都能快速定位上下文。7.3 简答题准备框架层次的答题模板简答题最怕答得很散没有层次感。我个人的答题模板是三层结构论点先行第一句话直接给出结论或解决方案的核心思路。分点阐述从2到4个角度展开每个角度控制3到5行。比如从生产者角度……从消费者角度……从整体架构角度……。关键细节在最后补充一两个工程细节比如这里要注意释放锁时必须使用Lua脚本保证原子性。简答题不是写论文不需要面面俱到但要让阅卷人一眼看出你有系统化的思考能力。我把可能考的简答题大概整理了20道左右每道题都按这个模板写了提纲反复背诵并默写笔试时遇到同类问题基本可以快速成文。7.4 好未来业务场景从公开信息反推平台技术方向准备笔试的时候不要只盯着技术本身也花点时间了解一下公司的业务和技术体系。好未来是教育科技公司主营业务覆盖在线直播大班课、小班课、AI互动课、学习工具类产品。这些业务有几个共同特点直播场景有大量实时音视频传输和互动消息对延迟和稳定性要求高高峰时段比如晚间的课程集中时段流量波动大需要很强的弹性扩缩容能力线上线下结合的课程形态意味着需要统一的内容管理、用户体系、订单系统基础平台来支撑有大量数据积累数据平台和数据服务能力也很重要基础平台研发岗要做的就是把这些通用能力——服务框架、配置中心、网关、消息队列、缓存、容器平台、监控系统——搭建好、维护好让上层的业务研发可以专注于业务逻辑。我在笔试前专门花了一些时间思考如果我是这个平台岗的面试官我会期望候选人理解什么答案是**候选人不仅要会用某个中间件还要理解为什么平台层要提供这个中间件以及它在整体架构中扮演什么角色。**带着这个思维去做题很多选择题的最合理答案就变得清晰了。8. 笔试当天的一些细节环境、心态和白板代码的稳定性最后再分享一些笔试当天的注意事项这些看似细枝末节实际上很影响发挥。第一选择一个网络稳定、环境安静的地方。笔试全程在线监控中途断网会非常被动。建议提前一天测试摄像头、麦克风、浏览器兼容性不要用过于小众的浏览器。我在笔试前特意用Chrome做了一次模拟测试确认代码编辑器、自动缩进、补全功能都正常这才放心。第二编程题不管难度如何先读题、再分析、后编码最后自测。很多同学一上来就写代码写到一半发现理解错了题意白白浪费大量时间。我做编程题的习惯是前三分钟纯读题和思考把输入输出样例在草稿纸上推演一遍确认理解了边界条件再动手。如果用时超过20分钟还没有头绪果断先跳过做完其他题目再回来——往往换个脑子之后思路就通了。第三注意控制心态。笔试中遇到不会的题非常正常不要因为一道选择题卡住就慌了。好未来这类大厂校招笔试题量通常不小本来就是设计成大多数人都做不完的目的是看你在有限时间内的优先级判断和得分能力。只要保证会做的都拿到分不会的不恋战结果通常不会差。第四笔试结束前一定要留出三五分钟检查。检查的内容包括选择题是否有未作答的没把握的也可以先填一个不要空着编程题的代码是否有明显编译错误代码里是否有多余的调试输出比如print函数名和输入输出格式是否完全符合题目要求。尤其是在牛客网这类平台上输出格式和题目要求不一致哪怕代码逻辑全对评分也可能是0分。关于笔试通过后进入面试的衔接我个人的体会是笔试更像是门槛型筛选真正决定offer去留的是技术面和HR面。所以笔试结束后如果感觉还可以就要尽快把笔试中没答好的题目复盘一遍把不会的地方补齐——因为这些点很可能就是后续面试官追问的方向。比如笔试里遇到一道不熟的分布式锁题面试前一定要彻底搞懂RedLock的原理和缺陷面试官大概率会顺着简历和笔试来深挖。