1. 从2013年笔试卷看京东研发的选拔逻辑1.1 试卷结构与时长的设计思路京东2013年的研发笔试卷放在今天回看依然是一份很有代表性的互联网公司技术面试试题。那年头的笔试题型比较固定选择题、简答题、编程题三大板块。选择题覆盖基础理论简答题考察理解深度编程题则直接检验动手能力。整场考试大约两个小时题量不算少时间卡的比较紧基本不允许你在某一道题上死磕太久。我手上拿到的这份试卷整体难度在同级别互联网公司里属于中上。对比当时百度、腾讯的笔试题京东这份试卷更偏向实用性和业务落地场景。比如淘宝当时喜欢问海量数据的处理思路百度喜欢考搜索相关的算法细节而京东因为电商业务的特殊性在数据库设计、订单状态流转、高并发访问这些方向上会多花一些笔墨。为什么说两个小时的设计很讲究这个时长其实在模拟真实工作中的一个核心能力优先级判断。你不能把时间均匀分配给每道题得先扫一遍全卷找出自己最有把握的题先做拿稳基础分再回头啃硬骨头。这个策略和日常开发中处理需求排期、线上故障响应是同一个逻辑。我在带新人的时候经常说代码写得好不好是第二位的第一位是你拿到一个任务能不能快速判断哪些是关键路径、哪些可以延后处理。笔试卷的时长设计就是在筛选这种判断力。1.2 这套题真正在考察什么很多人以为研发笔试题就是考算法考刷题量其实不完全对。2013年这份试卷反映出京东在招人时的几个核心诉求。第一个是基础功是否扎实。不是看你背了多少API而是看你对计算机底层原理的理解。比如试卷里会出现让你解释进程和线程区别的题目这在现在看来觉得简单但当年这类题目恰恰能筛掉一批只会调用接口、不懂内部机制的人。第二个是工程意识。研发笔试不只是考算法题还会给你一些实际业务场景问你怎么设计表结构、怎么优化一个慢查询、怎么做缓存。这种题没有标准答案但能看出你有没有真实项目的经验有没有踩过线上的坑。第三个是逻辑表达能力。简答题部分特别看重你能否把思路条理化地写出来。代码写得再好如果分析过程一团乱麻面试官也很难相信你在团队协作中能把方案讲清楚。说到底这套试卷是围绕“一个合格的后端研发工程师应该具备什么素质”来设计的。它不追求偏题怪题而是把日常开发中最常用、最核心的知识点拿出来换着花样考察你的掌握深度。对准备面试的人来说这份试卷最大的价值不在于里面的题目本身而在于它帮你圈定了一个复习范围数据结构与算法、操作系统与网络、数据库、Java基础、分布式与高并发。把这几个方向吃透无论去哪家大厂面试心里都有底。2. 核心考点拆解数据结构与算法2.1 链表与二叉树不只是会写就行2013年的笔试卷里数据结构相关的题占了相当比例。链表反转、链表判环、二叉树的前中后序遍历、求二叉树深度这类属于保底题基本是送分题但你会发现很多人在这上面丢分。原因不是不会写而是边界条件处理不到位。以链表反转为例看似三行代码就能搞定但你是否考虑过空链表的情况是否考虑过只有一个节点的链表是否考虑过反转之后头节点指针是否正确指向这些细节才是拉开差距的地方。我当时带过的实习生里十个有八个第一次写链表反转都要在边界条件上栽跟头这是普遍现象。二叉树的题目更考验递归思维的成熟度。求二叉树深度这道题就是典型的递归写法左子树的深度和右子树的深度取最大值加一。代码量很少但它考察的是你有没有真正理解递归的调用栈变化。如果只是背模板换个题目形式比如求二叉树的最小深度或者判断一棵树是不是平衡二叉树就很容易卡壳。这里给一个实用的复习建议不要只看模板代码要动手画递归过程的调用栈。比如算二叉树深度的时候自己拿张纸模拟一下从根节点出发递归到叶子节点再一层层返回的过程。把这一步做扎实了二叉树相关的题目基本就稳了。2.2 排序与查找从原理到最优解排序算法是笔试中的常青树。2013年的试卷里出现了快速排序的时间复杂度分析也问了稳定排序有哪些、不稳定排序有哪些。这些题看起来是死记硬背的东西实际上考察的是你是否理解每种排序算法底层的交换和移动逻辑。快速排序为什么平均时间复杂度是O(n log n)因为每一轮划分都能把数组分成大致相等的两半递归深度是log n每层处理n个元素。但是最坏情况呢如果每次划分都选到最大或最小的元素作为基准退化成O(n²)。这就能顺带考察你对递归树的理解深度。查找方面二分查找是必考内容。但2013年的卷子更狠一点会给你一个循环有序数组让你在里面找目标值。这就是二分查找的变体题核心思路是先判断mid落在左半有序区还是右半有序区再决定搜索方向。这类变体题的训练价值很高因为它在告诉你考点永远不变但出题形式可以千变万化。你需要掌握的是底层原理而不是背一道题的解法。2.3 字符串处理与场景化算法题字符串相关的题目在试卷里出现的频率很高因为它在业务开发中也是绝对的高频操作。2013年的卷子里有一道比较有代表性的题判断一个字符串是不是回文串要求忽略空格和标点并且不区分大小写。这道题正常思路是先把字符串清洗一遍去掉无关字符然后双指针从两端向中间扫描。但如果你只想到先复制一份字符串再reverse来比较那就说明你还停留在调API的阶段。笔试题看重的是你有没有原地处理的意识有没有考虑时间和空间复杂度的优化空间。更值得一提的是一道场景化题目大意是有一个日志文件每行记录一个用户ID和访问时间要求统计出一天中访问次数最多的前10个用户。这个问题考察的知识点包括Hash表统计、TopK问题、堆排序等。实际工作中这种需求太常见了比如统计热销商品、统计搜索热词背后的逻辑是一样的。我当时和同事聊过这道题一致认为它出得很有水平。它不直接问“什么是堆排序”而是把它包装成一个业务场景考察你能不能把生活中的问题抽象成数据结构问题。这个能力在真实开发中非常重要因为业务方不会告诉你“这里要用堆排序”只会告诉你“我要看今天卖得最好的十件商品”剩下的需要你自己匹配技术方案。3. 操作系统、网络与数据库被低估的隐形门槛3.1 进程线程与内存管理答不全的送分题在很多人的复习计划里操作系统是最容易被忽略的一门课。原因很简单平时写业务代码很少直接接触进程调度和内存管理。但2013年的笔试卷证明京东对这部分知识是有明确要求的。试卷里有一道很经典的题进程和线程的区别。看起来简单但想拿满分不容易。至少要说出四点进程是资源分配的基本单位线程是CPU调度的基本单位进程有独立的地址空间同一进程的线程共享地址空间进程切换开销大线程切换开销小进程间通信需要IPC机制线程间通信可以直接读写共享变量。光这四点还不够最好能举一个实际例子比如Chrome浏览器每个标签页是一个进程每个页面里的多个子功能可以用线程实现。这样答题就立体了不是背教科书而是展示你真正理解了这个概念。内存管理方面试卷考察了栈和堆的区别。这个知识点连很多工作两三年的工程师都说不清楚。栈是由编译器自动分配和释放的存放函数的参数值、局部变量等堆是由程序员手动申请和释放的。搞清楚这个区别在排查线上问题的时候特别有用。比如你在代码里创建一个很大的局部变量数组会导致栈溢出如果你用new关键字创建对象忘记释放就会造成内存泄漏。这些面试题本质上是工作场景的提前演练。3.2 TCP/UDP与HTTP必考的协议题网络协议是互联网公司笔试的标配考点。2013年的试卷里涉及了TCP三次握手的过程、TCP和UDP的区别、HTTP协议的几种请求方法等。三次握手这个知识点很多人的理解停留在“客户端发SYN服务端回SYNACK客户端再回ACK”这个背诵层面。稍微问深一点就卡壳了为什么是三次而不是两次答案是防止失效的连接请求突然传到服务端导致资源浪费。这个例子在教科书里是经典的它考察的不只是记忆而是你是否理解了握手设计背后的动机。TCP和UDP的区别就更需要结合实际场景来理解了。TCP提供可靠传输、有连接、面向字节流UDP提供不可靠传输无连接、面向数据报。笔试卷里可能会问视频通话应该用TCP还是UDP答案是UDP因为视频通话对实时性要求高允许偶发的丢包而TCP的重传机制会造成延迟和卡顿。这就是把协议知识和工程场景结合起来的典型考法。HTTP部分2013年问的还是比较基础的内容比如GET和POST的区别。但要注意这类题目在面试中容易踩坑。因为随着技术演进很多教科书上的答案是过时的。比如“GET请求的参数放在URL里POST请求放在body里”这个说法就不完全准确GET请求也可以有bodyPOST请求也可以把参数放在URL里。真正的区别在于语义GET是幂等的用于获取资源POST是非幂等的用于创建资源。回答这类题目如果能体现出你对协议语义的理解而不是只会念教科书答案就会给面试官留下很深的印象。3.3 数据库索引和SQL优化电商业务的重头戏电商公司的笔试题数据库一定不会缺席。2013年的试卷里大量出现了SQL查写的题目比如多表关联查询、分组统计、子查询等。这些题目在LeetCode上刷不到纯靠平时业务积累。有一道题让我印象很深给定订单表和商品表查询每个商品被购买的次数并按次数从高到低排序。这道题考察的是GROUP BY和ORDER BY的组合使用。基础写法是SELECT product_id, COUNT() FROM orders GROUP BY product_id ORDER BY COUNT() DESC。但更深一层的问题是如果订单表有上千万行数据这条SQL能跑得动吗如果不能应该怎么优化这就引出了索引的知识点。大多数情况下你应该在orders表的product_id字段上建立索引这样可以加速分组操作。但问题是如果这个查询是实时统计需求数据量大到索引都快撑不住的时候又该怎么办此时就需要考虑用缓存或者离线计算来支撑。2013年的时候很多互联网公司已经开始用Redis做缓存了所以笔试卷里出现类似的题就是在考察你有没有这方面的意识。数据库这块我还想多说一句SQL能力是很多人的短板。业务代码写得多但真正让你手写一条复杂SQL的时候却经常卡住。这是因为ORM框架用惯了手写SQL的能力退化了。我的建议是无论平时用不用ORM每周至少手写几条SQL保持对表结构和JOIN逻辑的敏感度。面试的时候熟练的手写SQL能力会让你在众多候选人里显得突出。4. 京东特色电商场景下的系统设计题4.1 从一道库存扣减题看高并发设计2013年的京东笔试卷里有这么一类题和其他公司的笔试题风格明显不同它会直接给你一个电商业务场景让你设计方案。我印象比较深的一道题是关于库存扣减的大致是秒杀场景下大量用户同时抢购一个商品如何保证库存不会被超卖这个问题放在今天已经是面试必考题了但在2013年能把库存扣减的并发问题想清楚的人还不多。首先你要知道超卖是怎么产生的。假设库存是10两个用户同时下单都先查询库存发现都大于0然后都执行扣减结果库存变成-1。这就是经典的并发问题。解决方案有几种思路。最简单的思路是给库存行加锁用数据库的行锁保证同一时刻只有一个请求能扣减库存。但加锁意味着其他请求都要等待秒杀场景下等待会积累大量请求响应时间会变得不可接受。更优的思路是把库存放到Redis里用Redis的原子操作来扣减。Redis的DECR命令是原子性的能够在单线程模型下保证不会出现并发扣减问题。这就是为什么后来的高并发系统里Redis成了标配。但Redis方案也有自己的问题比如Redis挂了怎么办库存数据怎么和数据库保持一致。2013年大部分公司还在探索这条路现在回头看这道题出得很有前瞻性。4.2 缓存与分库分表的初步思考另一类特色题是针对订单系统的。订单数据量增长极快单表存储迟早会成为瓶颈。笔试卷里会问如果订单表数据量超过一亿条查询速度变得很慢你有什么优化方案回答这个问题至少要有两个层次。第一层是加缓存把热点数据放到缓存里减轻数据库的压力。比如用户查询自己的近期订单这种高频查询就可以做缓存。但缓存有一个缓存穿透、缓存击穿、缓存雪崩的经典问题需要解决能说出这三点再加一些解决方案这道题就答得很深了。第二层是分库分表。一亿条数据放在一张表里即使加了索引查询性能也不会理想。此时需要根据某个维度比如用户ID把数据分散到多张表或者多个数据库实例里。分表之后又会引入新问题跨表的复杂查询怎么办分布式事务怎么处理全局唯一ID怎么生成这些延伸问题面试官一问就能探出你的真实水平。我当时在准备面试的时候把这类电商场景题单独整理了一个笔记。不是因为它们比算法题难度高多少而是因为它们考察的维度很全面既要你有扎实的数据库功底又要有架构思维还要能快速理解电商业务的特殊性。做电商和做社交、做搜索的后端研发技术栈可能差不多但业务场景决定了你要重点掌握不同的技术方案。京东的笔试出这种题就是在筛选有电商业务思维的人。5. 考后复盘那些年我们一起踩过的坑5.1 五种最常见的失分原因我接触过不少准备笔试的候选人也复盘过很多人的考试情况。结合2013年这份试卷的特点聊几个典型的失分原因。第一种是前面的选择题用时太多导致后面编程题没时间写。选择题看着简单但有些题目有迷惑性容易钻牛角尖。我的建议是选择题给自己设一个硬性时间上限比如30分钟到点就交卷心态不再纠结。第二种是简答题答得太简略。很多候选人以为写对关键词就行但笔试阅卷通常看的是你思路的完整度。比如问“线程和进程的区别”只写“进程有独立内存线程共享内存”不够还要把调度单位、系统开销、通信方式都写清楚。在简答题上宁可多写也不要少写同时注意逻辑顺序别想到哪写到哪。第三种是编程题只写核心逻辑不写边界处理。这是个致命的习惯。阅卷人看代码首先看的就是边界条件。你没有处理空指针、没有处理输入为空的情况即便核心逻辑对了也很难拿满分。养成习惯写代码的第一步永远是考虑边界。第四种是对自己的答案没有信心反复修改。笔试的时间是固定的你在这里多花一分钟在另一道题上就少一分钟。除非你明确发现了错误否则不要轻易改动已经写完的答案。在考场上果断是一种能力。第五种是技术以外的准备不足比如没有提前了解试卷的题型结构。很多人参加笔试前连试卷分几个部分都不知道。如果提前在网上搜一下历年笔试经验帖心里有底考场上的紧张感会少很多。5.2 如何把一份笔试卷变成知识图谱考完试之后的复盘比考试本身更重要。我自己的习惯是每做完一份笔试卷都要把题目按照知识点进行分类然后整理成一张知识图谱。比如一份试卷涉及了链表、二叉树、哈希表、排序、进程线程、TCP/IP、SQL优化就把这些关键词写下来看看自己的薄弱项在哪里。我当年做这份2013年试卷复盘的时候发现自己网络协议部分答得最差。于是接下来两周集中看TCP/IP协议相关的内容把三次握手为什么需要三次、四次挥手为什么需要四次这些经典问题彻底吃透。带着问题去学习效率比漫无目的地翻书高得多。更重要的是你要学会从一个题目延伸出一串题目。比如试卷考了二叉树的前序遍历你就可以继续问自己中序遍历怎么写后序遍历怎么写层序遍历用什么数据结构实现能不能用非递归的方式实现前序遍历这样一题变五题复习的深度和广度就都有了。知识图谱不是一次就能建好的它是一个不断迭代的过程。每做一份新试卷就往图谱里补充新节点久而久之你会对整个面试知识体系有一个全局的把握。6. 如何把2013年的题目用到2025年的面试准备里6.1 题目会更新考察的内核没变有朋友可能会问2013年的试题过了这么多年技术都迭代好几轮了还有参考价值吗我的回答是题目本身可能过时了但出题人想考察的内核并没有变。2013年可能考察的是HashMap的基本原理2025年的面试可能会问ConcurrentHashMap在Java 8里的实现优化。两个问题看起来差别很大但底层都在考一件事你对哈希碰撞和并发控制的理解。同样地2013年问的是进程和线程的区别现在可能会让你画一下Java内存模型或者分析一段并发代码的执行结果。考点在演进但核心依然是操作系统对并发的支持机制。所以我的建议是拿2013年的试卷当骨架把每个考点映射到2025年的最新技术上。做一个表格左边是当年的考点右边是对应现在应该掌握的新内容。比如当年考单机缓存那对应的新内容就是Redis集群、缓存一致性问题。当年考SQL优化那对应的是分库分表、ClickHouse这类分析型数据库。这样做下来你会发现复习方向清晰了很多不至于被网上铺天盖地的面试资料搞得晕头转向。6.2 一套实用的三周复习计划如果你正在准备互联网公司的研发岗位面试这里分享一套基于这份试卷复盘总结出来的三周复习计划你可以根据自己的情况调整。第一周重点攻克数据结构和算法。围绕数组、链表、栈、队列、哈希表、二叉树、排序、查找这几个核心主题每天坚持刷三到五道题。不用追求难题偏题重点是把基础题写熟练尤其是那些经常被当作“热身的送分题”更要确保不丢分。第二周集中复习操作系统、网络和数据库。这三个方向不需要你从头到尾读一遍大学教材而是直接找高频面试题围绕问题去查资料。进程线程、内存管理、TCP三次握手、HTTP状态码、SQL索引、事务隔离级别这些都是常青考点必须做到能脱稿讲解。数据库部分一定要多动手写SQL特别是那些涉及多表关联和分组统计的题目。第三周是综合冲刺阶段。拿历年的笔试卷做限时模拟按照考试的时间要求两个小时内完整做一份卷子。做完之后不急着对答案先把能回忆起来的题目标记出来找出自己的薄弱环节。然后再对照参考答案把每道题考察的知识点记到知识图谱里。这周的重点是适应考试的节奏和压力同时查缺补漏。6.3 我个人对这套试卷的最终评价做了多年的技术面试官也陪不少人准备过笔试回过头来看京东这套2013年的研发笔试卷我的评价是它是一份质量很高的选拔工具放在今天仍有很强的参考意义。说质量高是因为它没有一味追求出偏题怪题来难倒候选人而是把研发工程师日常工作中最核心的知识点用多种题型和真实业务场景结合的方式呈现出来。整份试卷做下来一个基本功扎实、有一定实战经验、逻辑表达清晰的候选人大概率能拿到不错的分数。反之如果只靠背题目、刷题库很难在这套试卷里蒙混过关。技术这个行业变化很快框架和工具层出不穷今天流行的技术过几年可能就成了历史。但计算机基础知识和工程思维是跨越时间的沉淀不管行业发展成什么样它们都会是技术面试的重心。如果你想在面试中掌握主动权把基础打牢是最稳妥的做法。最后再分享一个小技巧回答系统设计题的时候尽量画图辅助表述。哪怕是手绘的简陋示意图也能让面试官更快速地理解你的方案。笔试卷上能清晰画出系统架构图的考生往往更容易在众多候选人中脱颖而出。