2024年秋招那阵子身边不少同学都在群里吐槽Shopee的笔试有点“怪”——不是怪在难度而是怪在题型分布和实际业务贴得太紧。我当时做完提前批那套BE卷子最大的感受是这不是一场纯粹考算法刷题量的考试更像是一次“用后端工程师的日常思维”做的压力测试。趁着记忆还热乎我把整场笔试从题型、考点到背后的考察意图完整复盘了一遍。这篇文章不提供具体答案搬运题目细节已经模糊了而且直接背题意义不大重点讲清楚Shopee BE提前批笔试在考什么、为什么这样考以及我是怎么从卷面反推这家公司的后端技术偏好和团队风格的。如果你正在准备Shopee的后端岗位笔试或者打算投东南亚互联网公司的技术岗这篇复盘应该能帮你少走不少弯路。1. 从整张卷子的结构聊起Shopee BE笔试到底在筛选什么人1.1 先看整体考察逻辑Shopee的BE笔试通常限时在60到90分钟之间题型并不是单一的纯算法题而是“算法题 后端基础知识题 场景设计/应用题”混着出。我当时那场大概的分布是四道算法题外加若干道选择题和简答最后还有一道偏向系统设计的开放题。这和国内很多大厂“上来就是两道hard算法题”的风格不太一样。Shopee明显更看重候选人在基础扎实的前提下能不能把知识迁移到电商场景里。毕竟作为东南亚头部电商平台它的后端系统要扛住的不是一天的流量而是大促期间瞬时涌进来的订单、支付、库存更新请求。所以卷面里出现缓存、消息队列、库存一致性相关的题目几乎是必然的。从筛选逻辑来看Shopee BE笔试的优先级大致是基础功底算法数据结构 后端通用技术栈MySQL、Redis、消息中间件 业务场景理解电商、订单、秒杀 工程思维异常处理、降级、幂等。1.2 时间分配策略别在算法题上“死磕”如果你看过Shopee的笔试界面就会知道它往往允许在不同题目之间来回切换但整体计时是不停的。这里有一个非常现实的建议先把选择题和简答快速扫完再集中火力做算法题最后留时间给系统设计题。我见过不少同学栽在时间分配上——第一道算法题就卡了三四十分钟结果后面的基础题几乎空白系统设计题随便写了两行。这其实很吃亏。因为对Shopee的面试官来说算法题只代表你“刷过题”而基础题和设计题才能看出你“有没有真做过后端”。本人在考场上的节奏是这样的拿到卷子先花两分钟把全部题目扫一遍记下哪些题是“一眼就会”的哪些是“需要想一想”的哪些是“大概率不会”的。然后从最拿手的开始做把该拿的分先稳稳攥住。这套策略听着简单但真正能在考场上执行到位的人并不算多。2. 算法题部分从考题设置反推后端基本功的分层考察2.1 第一类题BFS/层级遍历类考察“广度优先”的代码手感Shopee笔试题里出现树或图的遍历概率很高尤其是BFS。这个考点选得很聪明因为BFS在后端开发里真的太常用了——比如在订单状态流转、任务队列处理、多级缓存刷新策略里都能看到BFS的思想。我当时遇到的一道题和“二叉树右视图”很接近。这个题本身不难但有个细节坑如果直接用层序遍历取每层最后一个节点需要额外记录当前层的节点数量如果写递归又要纠结先遍历右子树还是先遍历左子树。考场上我用的BFS解法如下Java示例public ListInteger rightSideView(TreeNode root) { ListInteger result new ArrayList(); if (root null) return result; QueueTreeNode queue new LinkedList(); queue.offer(root); while (!queue.isEmpty()) { int size queue.size(); for (int i 0; i size; i) { TreeNode node queue.poll(); if (i size - 1) { result.add(node.val); } if (node.left ! null) queue.offer(node.left); if (node.right ! null) queue.offer(node.right); } } return result; }这道题想通之后会发现它其实在考你对“层”这个概念的处理。很多人在LeetCode上做过原题但一到笔试环境里边界条件的处理就露馅了。我当时的建议是BFS类题目代码写完后一定要自己手动模拟一遍空树、单节点、满二叉树这三种极端情况基本能避开大多数边界问题。2.2 第二类题动态规划题考的是“状态定义”而不是“转移方程”Shopee算法题里的DP题难度一般控制在中等偏下它不会故意出那种需要奇技淫巧才能解的题。但它的DP题有个特点题目背景通常会被包装成“商品组合”“优惠券抵扣”“凑单”之类的电商场景。你剥掉外壳之后其实就是背包问题或者子序列问题。比如有一类常见题“给定若干商品价格和一个满减阈值计算凑单方案的最小超支金额”。这类题典型的解法就是0-1背包的变体。很多人会卡在状态定义上——因为题目里加了“满减”“超支”这些业务词一下子就不知道该怎么抽象了。我的经验是读题后先不要纠结业务场景先把输入输出抽象出来。你问自己三个问题状态是什么决策是什么目标是什么一旦把“价格”对应到“重量”“满减阈值”对应到“背包容量”思路立刻就通了。这里多说一句DP题在笔试里最忌讳的就是“一开始就写代码”。宁可先花三分钟在草稿纸上把dp数组的含义、初始化、递推方向写清楚也别急着敲键盘。代码写得快不如想得清。2.3 第三类题图/连通性问题重点看并查集和DFS染色剩下的算法题里连通性问题出现频率也挺高典型如“岛屿数量”“省份数量”这类。Shopee考这类题往往不只是考DFS/BFS还会顺带考察“你是否知道并查集这种更工程化的解法”。为什么要考并查集因为图连通性问题在后端系统里对应的是“服务依赖关系”“数据分片归属”等场景。比如说A服务依赖B服务B服务依赖C服务如果C挂了最终影响范围怎么算这本质上就是一个传递闭包/连通性分析问题。所以在准备这个考点时除了会写递归DFS我建议把并查集的模板也背熟并且理解路径压缩和按秩合并的作用。笔试时间紧张的时候并查集的代码更短、更不容易出错。并查集模板示例Javaclass UnionFind { int[] parent; int[] rank; public UnionFind(int n) { parent new int[n]; rank new int[n]; for (int i 0; i n; i) parent[i] i; } public int find(int x) { if (parent[x] ! x) { parent[x] find(parent[x]); } return parent[x]; } public void union(int x, int y) { int rootX find(x), rootY find(y); if (rootX rootY) return; if (rank[rootX] rank[rootY]) { parent[rootY] rootX; } else if (rank[rootX] rank[rootY]) { parent[rootX] rootY; } else { parent[rootY] rootX; rank[rootX]; } } }2.4 第四类题字符串/滑动窗口考的是代码实现力和调试速度字符串题基本是笔试标配。Shopee那场出现的字符串题和“最小覆盖子串”“无重复字符的最长子串”是同一路子。这类题难的不是思路而是实现细节——左右指针怎么移动、窗口内计数怎么更新、什么时候更新答案每一步都不能含糊。而且Java写滑动窗口比Python要啰嗦一些下标一旦差一位就是一道题。这个经验比较个人化我在笔试前专门把滑动窗口类的题集中刷了二十道左右练到“不用过度思考、手能跟上脑子”的程度。因为考场上没有调试器给你反复试错写错一个下标基本就浪费了整道题。滑动窗口模板我习惯这样写Javaint left 0; int minLen Integer.MAX_VALUE; int[] need new int[128]; int[] window new int[128]; for (int right 0; right s.length(); right) { char c s.charAt(right); window[c]; // 尝试收缩左边界 while (check(window, need)) { minLen Math.min(minLen, right - left 1); char leftChar s.charAt(left); window[leftChar]--; left; } }这种模板的价值在于你的大脑只需要处理两个问题——什么时候扩大右边界什么时候收缩左边界。剩下的交给模板本身出错概率大大降低。3. 基础选择题与简答题拉开差距的“隐藏分”都在这里3.1 MySQL 数据库索引与事务隔离级别Shopee BE笔试的基础题部分MySQL几乎是必考。考察内容包括但不限于索引失效的场景、聚簇索引与非聚簇索引的区别、事务的隔离级别、MVCC机制、间隙锁与幻读的关系。我印象里有一道题特别典型给了四条SQL语句问哪些会走索引。答案并不是简单的“where条件里带了索引列就一定会走”而是要你综合判断能否使用索引、是否覆盖索引、是否有隐式类型转换、是否对索引列做了函数操作。这里分享一个我后来总结的检查清单面试前背下来很有用对索引列使用函数或计算索引失效隐式类型转换导致索引失效比如字符串列直接和数字比较like查询以“%”开头索引失效联合索引不满足最左前缀原则索引失效用or连接条件时如果其中一个条件字段没有索引索引可能失效覆盖索引在特定场景下即使不符合最左前缀也能通过索引下推优化事务隔离级别这块Shopee喜欢考“RR可重复读怎么解决幻读”。这个问题光答“通过间隙锁”是不够的最好还能解释清楚快照读靠MVCC解决幻读当前读靠Next-Key Lock解决幻读两者是不同的机制。我当时特意把这个点整理成了一个对比表笔试前快速扫一眼复习效率很高。隔离级别脏读不可重复读幻读实现依赖读未提交可能可能可能无特殊机制读已提交不可能可能可能MVCC每次生成新快照可重复读不可能不可能可能/不可能InnoDB下基本不可能MVCC Next-Key Lock串行化不可能不可能不可能加锁串行执行3.2 Redis 缓存与分布式系统的常见问题另一大块基础题是Redis。Shopee作为电商平台Redis用得极其广泛——从商品详情页缓存、用户购物车到库存预热处处都有它的影子。笔试里高频出现的Redis考点包括缓存穿透、缓存击穿、缓存雪崩的区别及应对方案Redis持久化RDB与AOF的对比以及分布式锁的可靠性问题。关于缓存穿透查询一个不存在的数据导致请求直接打到数据库我建议回答时不要只说“布隆过滤器”一个方案而是把“缓存空值”和“布隆过滤器”两种方案都点出来并说明各自的适用场景。面试官想看到的不是你会背方案名字而是你能判断在什么场景下用哪个方案。关于分布式锁网上很多教程上来就推Redisson的RedLock但实际笔试里你更需要理解的是基于Redis的分布式锁SET NX 过期时间哪里不可靠、看门狗机制解决什么问题、为什么大多数业务场景下Redisson已经够用。能把“主从切换导致锁丢失”这个隐患讲清楚这题基本就能拿高分。3.3 消息队列与异步解耦Kafka的高可用和消息顺序问题消息队列在Shopee后端体系里是不可或缺的一环笔试简答题里出现过和“消息顺序性”“消息重复消费”相关的问题。这些题考察的不是你会不会用Kafka而是你有没有真正处理过生产环境的问题。消息顺序性这个点最能体现工程深度。Kafka的Topic内部是按分区保证有序的但如果你没有设置合理的消息键比如不指定key或者key分布不均匀消息的全局顺序是无法保证的。而如果把所有消息都塞到同一个分区里去保证顺序又会导致消费者并行度完全丢失。这是一个典型的“鱼和熊掌”问题需要根据业务场景做取舍。消息重复消费这个问题我建议的答题思路是“无法完全避免重复但可以通过幂等消费来化解。”同时最好能举例说明——比如订单创建消息被消费了两次你通过订单号在数据库做了唯一索引第二次插入直接报错或忽略这样重复消费就没有产生实质影响。3.4 场景应用题从订单状态机到幂等设计场景应用题是Shopee笔试里最有“业务味”的部分通常会给一个电商场景让你设计方案或排查问题。比如当时卷子里有“设计一个购物车系统”“用户下单后如何保证库存不超卖”“支付回调如何保证幂等”这类问题。这类题回答的核心思路其实就六个字定边界抓核心。以“库存不超卖”为例完整的答题链条是这样的先说最朴素的方案数据库更新库存时加条件UPDATE stock SET count count - 1 WHERE sku_id ? AND count 0用数据库行锁保证不超卖。再说高并发场景下数据库扛不住需要引入Redis预扣库存异步同步到数据库。然后抛出问题Redis预扣之后如果订单超时未支付需要回补库存这里面就有分布式事务/最终一致性的问题。最后补充降级方案和兜底逻辑比如库存扣减记录加日志、定时对账脚本、人工补偿接口。这个回答链条层层递进每一层都对应着真实系统中的关键组件。面试官一眼就能看出你是“背过八股文”还是“真正理解过这个场景”。4. 从笔试题目“逆向”Shopee的后端技术栈与团队风格4.1 高频出现的组件其实就是团队的核心技术栈笔试题目往往能反映出团队的技术选型。从Shopee BE提前批的卷面来看MySQL、Redis、Kafka这三样是绝对的核心。除此之外对Go语言和Java的考察都出现过说明团队内部是多语言并存的——老的系统可能用Java/Python新的高并发服务可能用Go重写。如果你在简历上写了熟悉Go建议把Go的GMP调度模型、channel通信机制、内存逃逸分析这些基础概念弄清楚因为笔试简答题里出现过Go语言相关的特性题。如果你主攻Java那JVM内存模型、GC算法、线程池参数设置这些传统考点也需要掌握到位。4.2 “电商 大促”的业务底色决定了出题方向为什么Shopee的笔试题和纯互联网公司不太一样根本原因在于它的业务形态。Shopee的业务高度集中在电商交易链路而电商后端最大的挑战就是大促峰值。2024年秋招这个大环境下Shopee对候选人的考察明显偏向了“如何用有限的资源扛住高吞吐场景”。这就解释了为什么缓存、消息队列、库存一致性、幂等设计这些考点会被反复拿出来考。因为这些都是大促场景下后端工程师每天都要面对的真问题。你在准备笔试时与其去死磕冷门算法不如多花时间看看电商系统的架构设计案例学学别人是怎么做流量削峰、限流降级和缓存策略的。4.3 笔试题里的“坑”它真正想淘汰的两种人复盘完整场笔试后我发现Shopee BE提前批的淘汰逻辑非常清晰它想过滤掉两种人。第一种是“只会刷题不会写工程代码”的人。这类人算法题可以做得很好但遇到“订单场景下Redis和数据库一致性怎么保证”这种问题就完全懵掉。第二种是“只会背八股文不会变通”的人。这类人能答出“缓存穿透的三种解决方案”但要让他针对一个具体场景选方案、说理由他就不知道从何下手了。反过来Shopee想招的人应该是能在“高并发、分布式、海量数据”这些压力词面前保持冷静能够把复杂业务问题拆解成清晰技术方案的人。它的笔试本质上就是在提前筛选这样的人。5. 秋招备考的实操建议复盘之后我给自己列的补强清单5.1 三轮复习法从广覆盖到高频强化再到模拟实战考完Shopee笔试之后我复盘总结了一套更适合后续秋招备考的节奏大概分三轮第一轮广度覆盖把所有主流的后端考点过一遍不要有侥幸心理。MySQL索引与事务、Redis持久化与缓存策略、Kafka/消息队列基础、操作系统进程线程与内存管理、网络TCP与HTTP这些基础领域全部都要覆盖到。这时候不用太深入能做对选择题和简答题即可。第二轮高频强化针对Shopee这类的电商后端公司把复习重心移到高并发场景专题上。包括但不限于缓存一致性方案、分布式锁实战、库存扣减方案、订单状态机设计、幂等方案的实现细节。每周用1到2天专门练习系统设计类题目不要只看不做一定要自己拿笔写方案、画时序、列组件。第三轮模拟实战严格按照90分钟定时做整套模拟题选择题、简答题、算法题、设计题混合训练练出“考试肌肉记忆”。这里我自己试过最有效的方式是找几套往年真题或高质量模拟题用倒计时模拟考场的紧张感。第一次模拟大概率会翻车但这种翻车特别有价值——它会让你提前暴露时间分配问题、代码熟练度问题以及“明明会做但一紧张就写错”的临场问题。5.2 结合“逆向备考法”从题目推导出题官的日常最后说一个我备考后期用得最多的技巧——我把它叫“逆向备考法”。具体操作是每做完一道题不要急着对答案先站在出题人的角度问自己三个问题这道题对应着实际工作中的哪个场景出题人想通过这道题了解我的什么能力如果我在面试中被追问这道题的延伸问题我会怎么答比如你做了一道“设计一个秒杀系统”的设计题那你就要立刻想到面试官可能追问“Redis库存预热后如果服务重启Redis数据丢了怎么办”或者“如果用户疯狂刷接口怎么防止超卖”。用这种方式去备考你的知识体系会从“零散的知识点”逐渐变成“一张业务问题网络”而这种网络恰恰是笔试和后续面试中最有价值的东西。5.3 关于心态一次笔试不通过不等于技术不行秋招这个过程心态管理真的和技术准备同样重要。Shopee的笔试有难度也有一定的运气成分——同一套卷子在不同人手里的年份不同、岗位不同难度波动也不小。如果你做了一家的笔试题感觉很差不用立刻否定自己先复盘一下是“基础不会”还是“临场紧张”还是“时间分配失误”。哪怕这次笔试不幸挂了你从卷面里提炼出来的考点清单、暴露出来的薄弱环节也会成为你下一家笔试的弹药。这一点我是在实际经历中反复体会到的——秋招最怕的不是某一家的败局而是打完一仗之后没有留下任何有用的复盘成果。最后分享一点个人的复盘心得整套Shopee BE提前批笔试做下来我个人觉得它是一份“性价比很高”的试卷。所谓性价比高是说它考察的知识点基本没有偏题怪题每一道题都能在真实的后端开发日常里找到影子。你用这套卷子来检验自己的后端功底比盲目刷很多偏难怪题要有效得多。如果你正在准备这一类的笔试我的核心建议可以浓缩成几句话基础题是基本盘算法题是分水岭设计题是加分项时间分配永远比单题得分更重要复盘永远比刷题量更有价值。尤其是时间分配这一点我在那场笔试里踩过坑后来在多次模拟中反复调整最终才找到一个适合自己的节奏。希望看到这篇文章的你能比我少走这段弯路。