京东2016研发工程师编程题：核心题型与笔试实战策略

京东2016研发工程师编程题，这个名字对经历过校招的同学来说应该不陌生。那几年互联网公司笔试已经普遍采用在线编程题筛选候选人，京东的题目难度中等偏上，但风格非常“工程化”——不会出那种脑筋急转弯式的偏题怪题，反而特别喜欢在字符串、链表、动态规划这些基本功上做文章。如果你正在准备技术岗笔试，或者想检验一下自己的代码功底，这篇内容可以当一份“开卷复习手册”来用，我会结合当年的出题风格，把最常出现的题型、解题思路和考场上的时间分配经验一次讲透。

这份内容不是题目搬运，而是把“遇到某类题怎么下手”的思路拆给你看。我选了几道在当时笔试里非常典型、而且之后几年各个大厂反复翻新的题目来做演示，每道题都会给出完整的思考过程和可运行的代码。除了解题，我还会聊一些考场上的实操细节，比如读题顺序、暴力解兜底策略、调试时间上限，这些都是自己踩过坑之后才明白的。

1. 先弄清楚京东2016研发岗编程题在考什么

备考之前，先得知道敌人长什么样。京东研发岗的在线笔试大概两个小时，前面有一批行测和基础选择题，后面的编程题通常是两到三道，题量不大，但每道题都值得你花半小时以上去抠。和现在笔试动辄“系统设计+算法”的豪华套餐不同，2016年前后的编程题更看重“代码能不能跑通”，边界条件、输入输出格式、超时控制，任何一个点出问题都可能直接导致整道题零分。

1.1 考查范围：看似离散，其实高度集中

从当年的真题回忆和同期备考群的反馈来看，京东的编程题几乎不会跳出这几个范围：

• 字符串处理：反转、去重、子串匹配、按规则格式化，这类题占比最高。因为字符串逻辑直观，又能轻松嵌入各种边界条件，是笔试出题人的心头好。
• 线性数据结构：链表、栈、队列的常规操作，尤其喜欢考链表的指针操作和栈的单调性应用。
• 经典动态规划和贪心：最大子段和、最长上升子序列、最少硬币数，这些是“性价比之王”，刷熟了你就能拿下一半的分数。
• 数值处理：大数相加、进制转换、整数溢出问题，这类题看着简单，实际抓细节。

范围听起来很宽，但本质上都在考察两件事：第一，你能否把现实问题抽象成数据结构；第二，你能否用代码正确处理各种边界情况。

1.2 一个很容易被忽略的事实：样例过了不代表能得分

当时很多人有个错觉，觉得只要把题目的示例输入输出跑通就算做对了。实际上在线判题系统的测试用例远比示例要多，尤其是隐藏用例，专门盯着你没考虑到的细节。比如字符串题的连续空格、数组题的单元素输入、数值题的溢出边界，这些都是隐藏用例的最爱。

我自己第一次参加模拟笔试就栽在这里。题目要求反转一个句子中的单词顺序，示例是“I am a student”转成“student a am I”，我写了个按空格切分再反转的解法，示例过了，结果提交后只得了一半的分。后来才意识到，如果输入连续多个空格，按空格切分就会产生空字符串，输出格式直接错掉。所以后来我养成了一个习惯：写题之前先花两分钟问自己“输入有没有可能为空”“有没有可能包含多余分隔符”“数组有没有可能只有一个元素”。这三连问，能帮你提前排掉七八成的雷。

2. 字符串与数组：看似简单，失分最多的题都在这里

字符串和数组是京东笔试的高频区，也是“看起来谁都会写，一跑全露馅”的重灾区。我当年备考时刷得最多的就是这两类，因为它们是所有算法题的基础载体，字符串题练好了，后面学动态规划都更顺。

2.1 反转类的经典变种：单词顺序反转

题目描述一般是：输入一个英文句子，反转句子中单词的顺序，但单词内字符的顺序不变。比如“I am a student”输出“student a am I”。这道题在当年京东笔试里属于“开胃菜”，难度不高，但正确率并不高，原因就是边界条件太多。

最核心的处理就是先翻转整个字符串，再逐个翻转单词。但如果你没有统一处理空格，就会像我之前那样翻车。我建议用一种更稳的思路：先把字符串按空格切分成列表，过滤掉空字符串，然后反转列表，最后用单个空格重新拼接。用Python写就是：

def reverse_words(s: str) -> str: # 按空白切分，Python的split默认会处理连续空格和首尾空格 words = s.split() return " ".join(words[::-1])

这里Python的split()隐藏了一个非常好的特性：如果不传参数，它会按任意空白字符切分，并且自动忽略首尾空白、合并连续空白。这就帮我省掉了手工过滤空串的麻烦。如果是C++或Java，你需要自己遍历字符串，按连续空格切分，然后处理边界。这也是为什么我一直建议笔试可以使用Python就用Python，不是说C++不好，而是Python的标准库确实能帮你避开很多低级错误，让你把精力花在算法本身。

2.2 子数组最大和：一道题串联起两个算法思想

这道题在京东2016年的笔试里出现过变体，题目原型是“给定一个整数数组，求连续子数组的最大和”。比如输入[-2, 1, -3, 4, -1, 2, 1, -5, 4]，最大和的连续子数组是[4, -1, 2, 1]，和是6。

这道题最大的价值在于，它可以从两个角度切入：动态规划和贪心。动态规划的解法是定义dp[i]表示以第i个元素结尾的连续子数组的最大和，状态转移方程是dp[i] = max(dp[i-1] + nums[i], nums[i])；贪心解法是维护一个当前和cur，只要cur还大于0就继续累加，否则从当前位置重新开始。

def max_subarray_sum(nums): if not nums: return 0 cur_sum = nums[0] max_sum = nums[0] for i in range(1, len(nums)): # 如果cur_sum为负数，带着它只会让和更小，不如从当前元素重新开始 cur_sum = max(nums[i], cur_sum + nums[i]) max_sum = max(max_sum, cur_sum) return max_sum

这个解法的核心在于那句cur_sum = max(nums[i], cur_sum + nums[i])，它同时体现了贪心（负数就丢弃）和动态规划（状态复用）的思想。面试官喜欢考它，不仅因为代码短，更因为它能考察你能否用抽象思维从暴力解法中提炼规律。笔试时如果一时间没想明白，可以先用三层循环写一个暴力解，算出所有子数组的和，拿到部分分数再说。这是一个很实用的策略：笔试不是竞赛，先保底，再追求最优解。

2.3 数组的“数字类”题型：溢出和进位才是核心

还有一种常见数组题是把数字存在数组里，比如用数组表示一个大整数，然后做加一操作。题目看起来简单，实际上是在考察你对进位和溢出边界有没有留下心眼。

def plus_one(digits): n = len(digits) for i in range(n - 1, -1, -1): if digits[i] < 9: digits[i] += 1 return digits digits[i] = 0 # 如果循环结束还没有返回，说明所有位都是9，需要扩展一位 return [1] + digits

这道题的隐藏用例一定是[9]、[9, 9, 9]这类极端输入。如果你只想着末位加一，忘记进位导致整个数字位数变化，就会出错。个人经验是，凡涉及进位、借位、溢出的题目，提交前必须手动测一遍“全9”和“全0”这两种极端用例，能省一次无效提交。

3. 链表操作：指针绕来绕去，画图才能救你

链表题在京东笔试中的出现频率一直不低，而且一旦出现，往往就是选择题和编程题的“双料选手”。链表考察的其实是“对引用和指针的理解”，语言层面的指针、引用如果掌握得不扎实，链表题几乎做不对。笔试时没有IDE调试条件，所以靠空间想象力硬解很容易出错，我的经验是先在草稿纸上画出节点和指针变化，再把思路翻译成代码。

3.1 删除链表倒数第K个节点：双指针是标准答案

题目很经典：给定一个链表，删除链表的倒数第K个节点。直接思路是遍历两遍，第一遍求长度，第二遍定位；优化思路是用双指针，一次遍历完成。

def remove_nth_from_end(head, k): dummy = ListNode(0) dummy.next = head fast = dummy slow = dummy # 快指针先走K+1步，目的是让慢指针停在待删节点的前一个位置 for _ in range(k + 1): fast = fast.next while fast: fast = fast.next slow = slow.next slow.next = slow.next.next return dummy.next

这里dummy哨兵节点非常重要。如果没有它，当删除的是头节点时，你需要单独处理返回的边界情况，稍不留神就会出错。当年笔试时，很多同学因为忘记考虑“删除的是头节点”这个情况，导致整道题没有通过。这题最保险的做法是：写完代码后，在草稿纸上模拟一个只有两个节点的链表，分别删除第一个节点和最后一个节点，看看代码会不会出错。

3.2 链表反转的“递归恐惧症”

反转链表也是高频考点，而且它有两种写法的博弈：迭代法和递归法。迭代法更好理解，递归法代码更短，但理解起来有点绕。我个人推荐笔试时写迭代法，因为不容易踩空指针的坑。

def reverse_list(head): prev = None cur = head while cur: next_node = cur.next cur.next = prev prev = cur cur = next_node return prev

这道题的易错点在于：单链表反转时，如果顺序不对，很容易丢失对下一个节点的引用。很多人写反转链表，写着写着cur.next变成了prev，但忘了先把cur.next暂存起来，结果整个链表直接断裂。我每次写都会在循环体第一行先保存next_node，这个习惯帮我避开了无数空指针错误。笔试时就算时间紧，这个暂存步骤也绝对不能省。

4. 动态规划和贪心：拿下这一块，笔试就稳了一半

动态规划和贪心在京东研发岗的笔试中占比不小，而且往往是区分度最大的题目。会写的人轻松拿满分，不会写的人只能瞪着眼睛穷举。这两类题靠考前突击背模板或许能应付一部分，但要真正做对，必须理解“状态”这个抽象概念。

4.1 最长上升子序列：从“傻递归”到“动态规划”的进化

题目描述很简单：给定一个无序数组，求最长上升子序列的长度。比如输入[10, 9, 2, 5, 3, 7, 101, 18]，最长上升子序列是[2, 3, 7, 101]，长度是4。

最自然的想法是递归枚举所有子序列，但时间复杂度是O(2^n)，n稍微大一点就超时。动态规划的思路是定义dp[i]表示以第i个元素结尾的最长上升子序列长度，状态转移方程是：

def length_of_lis(nums): if not nums: return 0 dp = [1] * len(nums) for i in range(len(nums)): for j in range(i): if nums[j] < nums[i]: dp[i] = max(dp[i], dp[j] + 1) return max(dp)

这个双重循环的时间复杂度是O(n^2)，对于笔试题的常见规模（n在1000左右）已经足够。如果你想追求O(n log n)的优化版本，用贪心加二分法维护一个“递增序列”，但在笔试中除非题目明确要求大数据量，否则不建议花时间去写，O(n^2)更稳妥。

这道题给我最大的启发是：动态规划的难点不是状态转移方程本身，而是能不能识别出“这是一个可以用动态规划解决的问题”。识别的方法只有一个——多做题，做到看到“最优子结构”和“重叠子问题”就能条件反射。我当年准备笔试时，每天雷打不动刷十道动态规划题，从青蛙跳台阶到背包问题，刷到后面，即便遇到了没见过的题目，也能顺着“定义状态→写出转移方程→初始化→确定遍历顺序”的流程走下来。

4.2 最少硬币问题：动态规划和贪心的分水岭

最少硬币问题是另一个经典：给定不同面值的硬币和一个总金额，求凑出该金额需要的最少硬币数。假设硬币面值是[1, 2, 5]，金额是11，最少需要3枚硬币（5+5+1）。

这道题有意思的地方在于，它既能用贪心做，也能用动态规划做。当硬币面值满足“贪心选择性质”时，贪心的效率更高；但当硬币面值变成[1, 3, 4]，金额是6时，贪心会选4+1+1，一共3枚，而最优解是3+3，只需要2枚。所以笔试中遇到这类题，最安全的做法是根据题目是否说明“硬币面值任意”来决定。没有说明的情况下，默认用动态规划，因为动态规划一定正确，贪心不一定。

def min_coins(coins, amount): # 初始化一个较大的值 dp = [float('inf')] * (amount + 1) dp[0] = 0 for i in range(1, amount + 1): for coin in coins: if i >= coin: dp[i] = min(dp[i], dp[i - coin] + 1) return dp[amount] if dp[amount] != float('inf') else -1

我特别想提一点：笔试时看到“金额较大”的提示，很多人第一反应是把硬币数组排序然后用贪心，理由是“这样更快”。但如果题目没说硬币面值满足条件，这就是一个陷阱，贪心会在隐藏用例中翻车。动态规划代码可能看起来不如贪心简洁，但它胜在“无脑正确”。笔试是求稳的地方，不是炫技的地方。

4.3 记住一个“暴力保底”原则

动态规划和贪心题如果用最优解解不出来，别死磕。先用记忆化搜索或暴力递归写一个答案，至少把部分测试用例的分拿住。很多在线判题系统是按测试点给分的，不是“满分或者零分”，暴力解往往能覆盖最简单的几个用例，拿个三四成分数不成问题。这一点在京东这类题目量不多、单题分值很高的笔试中特别重要，一道题三四成分数可能就决定了你能不能进面试。

5. 模拟题与大数处理：别让“简单题”变成失分重灾区

模拟题看着不涉及高深算法，好像只是“按题目描述写代码”，可实际上它是隐藏的失分大项。原因在于，模拟题通常有繁琐的输入解析和输出格式要求，而在线判题系统对格式的要求极其严格，多一个空格、少一个换行，都可能导致“Presentation Error”被判错。

5.1 大数相加：字符串模拟的核心套路

大数相加是2016年京东笔试中出现过的一个原题原型：输入两个超长正整数，用字符串表示，输出它们的和。如果你直接用int做加法，会因为溢出而崩溃；正确的思路是用字符串模拟竖式加法。

def add_strings(num1: str, num2: str) -> str: i, j = len(num1) - 1, len(num2) - 1 carry = 0 result = [] while i >= 0 or j >= 0 or carry: digit_sum = carry if i >= 0: digit_sum += ord(num1[i]) - ord('0') i -= 1 if j >= 0: digit_sum += ord(num2[j]) - ord('0') j -= 1 result.append(str(digit_sum % 10)) carry = digit_sum // 10 return ''.join(result[::-1])

这道题最大的“坑”是大家对字符串转数字的过度自信：直接用int(num1) + int(num2)转换后相加，等到相加结果溢出才意识到错误。笔试编译器不会告诉你溢出发生在哪一行，你只会看到一个“超出时间限制”或者“答案错误”。所以在笔试前，建议把这类大数题手动实现一遍，用“999…9 + 1”这种全进位用例验证一遍，确保每个边界都正确。这道题本质上也是在考“你愿不愿意把细节处理好”，这一点正是研发工程师日常工作中最需要的素质。

5.2 进制转换和模拟旋转：格式细节决定成败

另一个常见模拟题是进制转换。题目可能要求把十进制数转成十六进制或二进制，也可能反过来。这种题逻辑本身极其简单，就是除K取余法，但很多人没注意到负数和零的边界。比如十进制0转成二进制应该是“0”，但如果你用常规的“不断取余再反转”流程，很容易输出空串。

我也遇到过模拟二维矩阵旋转之类的题，比如顺时针旋转90度。这道题有现成的矩阵转置加水平翻转的套路，但是笔试时最容易出错的是下标计算，一旦索引写错，整道题基本就废了。我的习惯是：把四角顶点的下标在草稿上写清楚，再推其他元素的映射关系，最后拿一个3x3矩阵手算验证一遍，再写代码。这样看起来“多花了两分钟”，实际上是在帮你节省反复调试的十分钟。

6. 考场上怎么分配时间：我的实战体会

题目聊完了，我想重点说说考场上的时间分配。很多同学基础不差，但笔试分数很低，原因不是题不会做，而是时间没安排好。京东这种研发岗笔试，时间是固定的，题量看起来不多，但每道题都值得认真对待。我的策略供你参考，说不定能帮你避开我踩过的坑。

6.1 前10分钟，先“读题”而不是“做题”

拿到题后，不要立刻上手写代码。先把所有题目快速浏览一遍，在草稿纸上记下每道题的类型、大致难度、预估耗时。这个动作看起来浪费时间，实际上能让你对全局有把握。如果后面有一道你完全没头绪的难题，你就知道应该果断放弃，把时间留给前面的简单题，而不是在一道题上死磕到崩溃。我记得有一次模拟笔试，第一题是字符串处理，第二题是动态规划，我死磕第二题，结果第一题明明会做却因为时间不够没写完，事后后悔了很久。

6.2 一道题最多占用45分钟，超过就“暴力保底”

在笔试中，我给自己定了一个铁律：单题用时不超过45分钟。如果45分钟还没想出最优解，立刻切换成暴力解法或者部分用例解法，先拿部分分数。原因很简单，在线笔试的判分是按测试用例算的，暴力解通常能拿三成到五成的分；如果继续死磕，可能浪费掉后面所有题目的得分机会。两相权衡，“拿部分分+保住其他题”是性价比最高的策略。

6.3 代码写完，留5分钟用例自测

每写完一道题，我建议在提交前花五分钟做三件事：

• 用题目给的样例跑一遍，确认基础正确。
• 设计一个边界样例：空输入、单元素输入、全是重复元素的输入、最大数值。
• 检查输出格式：有没有多余的空格、换行，尤其是“输出每个结果占一行”这类要求。

这三步能避免很多无谓的提交错误。以前笔试很多平台是有“错误提交次数惩罚”的，一次次提交失败，不仅扣分，还打击信心。所以与其抢那两分钟快速提交，不如多花五分钟确认代码稳了再交。

7. 最后说几句过来人的心里话

备考京东这类研发笔试，核心就是把基本功练扎实，然后保持心态平稳。我自己当年刷题的时候也经历过“看一道题懵一道题”的阶段，后来是靠每天固定刷题、写题解、复盘错题，才慢慢从“看不懂答案”变成“能写出比标准答案更简洁的解法”。这个过程没有捷径，但也没有想象中那么痛苦，尤其是当你发现曾经看不懂的题目，后来能闭着眼写出来时，那种成就感是挺上头的。

如果你现在时间有限，我建议优先练熟字符串处理、链表操作和经典动态规划这三块，把它们变成你的肌肉记忆，其他冷门题型可以适当放一放。上了考场，记住一个原则：先把能拿的分稳稳拿住，再琢磨那些需要灵光一现的难题。这样即使没有超常发挥，至少不会因为低级失误留下遗憾。