2019年PayPal实习生招聘的编程卷在当年那一批准备外企暑期实习的同学圈子里算是一张有分量的卷子。一想到PayPal大多数人第一反应是支付老牌、跨境收款、风控体系这些标签所以它的笔试并不会只是单纯刷LeetCode就能应付——它更想看到的是你解决实际工程问题的能力。这篇复盘不会给你贴所谓“原题”网上流传的版本基本都是碎片化回忆整理但卷子背后的筛选逻辑、出题倾向和踩坑点放到今天依然有参考价值。不管你是准备外企实习还是想练一练算法和工程基本功都可以读一读。1. 先弄清PayPal笔试在筛选什么样的人很多人拿到笔试链接后的第一反应是“我LeetCode刷了300题稳了。”我当年也有类似的心态但复盘下来会发现PayPal这类做支付业务的外企笔试思路和国内互联网公司有些不一样它更看重代码的工程感、边界条件的处理、以及对业务隐含需求的理解。1.1 笔试在筛选什么能力先从筛选目标说起。实习生进来之后大概率会被安排到一个真实业务模块里可能是支付回调、交易记录查询、对账系统、风控规则引擎也可能是内部工具链的某个环节。这些场景有几个共同特点数据量大、并发不低、逻辑链路长、出错代价高。所以笔试环节本质上是在问一个问题你在代码里遇到复杂情况时是靠直觉写逻辑还是靠结构化思考掌控全局。这决定了出题风格不会太偏竞赛。那些需要冷门算法技巧、纯数学推导的题目在PayPal笔试里出现概率很低反而是一些看起来基础但能挖出细节的题目更适合用来筛人。比如数组处理、环形链表、LRU缓存、字符串解析、简单并发计数题目本身不超纲但想写对、写稳、写出边界处理需要真功夫。1.2 考卷结构背后的信号从多个渠道反馈来看2019年那场笔试通常包含几个部分算法编程题、简单系统设计题或者场景题、以及少量的行为风格问题。算法题占大头但并不是唯一重点。有一个信号值得注意PayPal的笔试平台会要求你在线写代码而且有些题目会针对异常输入做测试用例极端情况完全不提示。这意味着你不能只写出“能跑”的代码还要写出“经得起输入轰炸”的代码。这一点和LeetCode上的传统判题不同。LeetCode一般只测正常输入和最明显的边界但PayPal这类公司会在判题用例里塞大量隐藏数据空数组、超大值、重复元素、数组越界、整数溢出甚至会检查你在多个测试用例之间是否复用静态变量。简单说它的判题器会偷偷测试“你的代码是否具备交付质量”。2. 题型与考察维度不止是写一道题我印象里2019年的笔试大致分为三个维度算法题、工程场景题、行为风格问题。下面逐个拆顺便分析每类题目背后的考察点。2.1 算法题核心考的是熟练度和边界感算法题是绝对主力但考察的不是“这道题你见没见过”而是“这道题你在压力下能不能一次写对”。具体来说高频方向集中在数组与字符串处理、哈希表计数、链表操作、栈和队列、二叉树的遍历、递归与动态规划的经典模型。举个例子类似“找两个数组的交集”输出包含重复元素这类题目正常思路是哈希表计数。但很多人一上来就写def intersect(nums1, nums2): res [] for x in nums1: if x in nums2: res.append(x) nums2.remove(x) return res这段代码在数据量小时没问题但时间复杂度是O(n×m)在大量数据时会超时。更关键的是nums2.remove(x)的副作用和重复元素处理都会让人踩坑。出题人并不会规定你用O(n)还是O(n²)但判题器会告诉你答案。我在复盘时发现PayPal这套卷子的算法题有个特点题目描述会故意绕几个弯把一个“哈希表就能解决”的问题包装成“需要两步预处理”的问题。所以读题时不能只看样例要先把题目里的业务背景剥掉还原成最核心的数据结构和算法原型再动手写代码。2.2 工程场景题模拟真实开发中的决策除了纯算法题2019年的笔试里还会出现一到两道工程倾向的题目比如设计一个简单接口、实现一套限流逻辑、处理一个分布式计数场景等。这类题目不会要求手写完整框架而是要看你的代码组织方式类结构是否清晰、状态管理是否正确、是否考虑并发安全。我记得有同学反馈过一道题多个线程同时追加日志到同一个文件要求实现一个线程安全的日志写入方法。这道题看起来简单但可以深挖的点非常多是每次写入都加锁还是用双缓冲区批量刷盘synchronized锁的是方法还是对象要不要考虑跨进程追加如果让你设计这个接口你会怎么设计它的参数和返回值这种题目其实没有标准答案考察的是设计决策的合理性。我看到有同学直接写一个void log(String msg)方法内部FileWriter加锁这种写法虽然能跑但忽略了性能问题更好的方案是维护一个同步队列由一个单线程消费者异步写入这样写入方不会阻塞。笔试不要求你写出完整的生产者消费者模式但你要能说出取舍。2.3 行为风格问题藏在最后但别忽略有些版本卷子最后还会放几个选择题或问答题比如“当你和同事意见不一致时怎么处理”“一个功能马上要上线但你发现代码有bug怎么办”。这种题目没有对错却会影响综合评分。PayPal是一家非常强调协作和安全文化的公司答题时踩到“我直接上线再说”这种极端个人英雄主义的表达可能会有减分。我建议这类问题不要空着。回答时给出“先控制风险再沟通方案最后推进解决”的结构比单纯表忠心更靠谱。可以写中文但关键词如果用英文表达更自然就直接用这不是外企特有的要求而是技术交流中的习惯。3. 几道典型题目复盘从思路到代码下面挑几道在当年笔试中被反复讨论的题目做一个思路复现。我不保证和原题一字不差但类型和考察点是一致的适合用来做实战演练。3.1 题目一找出字符串中第一个不重复的字符这道题难度不高但能看出代码风格。最直觉的方案是遍历字符串对每个字符计数然后再次遍历找第一个计数为1的字符。Java里常见的写法是public int firstUniqChar(String s) { int[] count new int[26]; for (char c : s.toCharArray()) { count[c - a]; } for (int i 0; i s.length(); i) { if (count[s.charAt(i) - a] 1) { return i; } } return -1; }这个解法是标准的O(n)时间和O(1)空间针对小写字母场景很合适。但如果字符串包含大写字母、数字、甚至Unicode字符count[26]就不够用了。更稳妥的做法是用HashMapCharacter, Integer代价是空间开销变大了一点但通用性更强。笔试时如果你能先问一句“字符串只包含小写字母吗”再选择合适的方案会留下很好的印象。3.2 题目二多线程并发计数这道题模拟了一个很常见的场景多个请求同时进来不加锁地更新一个计数变量最后结果会小于预期值。笔试会要求你实现一个线程安全的计数器。最常见的答案是在increment方法上加Synchronized这能保证正确性。但稍微有点并发意识的人会想到AtomicInteger它能做到无锁线程安全且性能更好public class Counter { private AtomicInteger count new AtomicInteger(0); public void increment() { count.incrementAndGet(); } public int getCount() { return count.get(); } }更进一步如果这是分布式环境多个进程各有一个计数器那么AtomicInteger就无能为力了需要引入Redis或数据库原子操作。这道题考的就是你能不能从单机并发跳到分布式并发的维度去思考。笔试时不需要写Redis代码但你可以在注释里注明“如果扩展到多实例部署可考虑Redis INCR”这行注释能体现你的全局视野。3.3 题目三实现一个固定容量的LRU缓存LRU是面试常客笔试里出现的概率也不小。很多同学直接写LinkedHashMap这确实能过但有一个细节LinkedHashMap默认的removeEldestEntry返回false你需要重写它否则缓存永远不会淘汰元素。class LRUCache extends LinkedHashMapInteger, Integer { private final int capacity; public LRUCache(int capacity) { super(capacity, 0.75f, true); this.capacity capacity; } Override protected boolean removeEldestEntry(Map.EntryInteger, Integer eldest) { return size() capacity; } }如果不想依赖库实现自己写双向链表加哈希表的版式也很常见。笔试时我建议先写LinkedHashMap版本拿下基础分如果时间充裕再补充手写双向链表的版本。两种做法的差异不在功能而在于你对数据结构底层的理解深度。3.4 题目四模拟支付回调的幂等校验这类题目已经不只是纯算法了。题目背景一般是第三方支付平台回调通知支付结果回调可能重复发送你需要设计一个接口来防止重复处理。考察的核心是幂等。最简单的实现是在处理回调前查询本地数据库是否已存在相同的transactionId如果存在直接返回成功如果不存在则处理并记录。但这里有一个并发隐患两条相同的回调同时到达同时查到不存在同时执行处理逻辑结果就重复处理了。常见的解法是在数据库层面加唯一约束这样第二个插入请求会失败捕获冲突异常后直接返回成功即可。伪代码如下public Result handleCallback(PayCallbackRequest request) { try { paymentRecordDao.insertUnique(request.getTransactionId(), request.getStatus()); // 执行后续业务处理 return Result.success(); } catch (DuplicateKeyException e) { // 已处理过直接返回成功 return Result.success(); } }这道题几乎就是真实业务场景的简化版。它考察的不只是某个API会不会用而是你有没有处理过重复请求、并发冲突、异常恢复这类问题。笔试时能想到唯一约束这一层基本已经达到及格线以上。4. 笔试现场的时间分配和答题策略笔试和面试最大的不同是你没有机会跟面试官澄清题意所有判断都只能在有限时间内完成。所以如何分配时间、如何组织代码会直接影响结果。我把自己的答题习惯整理成一套流程供你参考。4.1 时间分配前10分钟别急着写代码我一直觉得笔试的前10分钟应该用来做“读题笔记”而不是写代码。把每道题目的输入、输出、限制条件、可能的边界情况都写在草稿纸或注释里。特别是输入范围是整数还是字符串有没有空值数组长度是多少是否需要处理溢出这些信息直接决定你用int还是long用数组还是哈希表。整体时间上我倾向于把总时长的20%用来读题和理思路50%用来写主逻辑30%用来补边界用例和复查。如果一道题卡了15分钟没有进展果断跳到下一题保住基础分永远比死磕难题划算。4.2 边界情况从“能跑”到“能交付”的分水岭代码写完只是起点真正拉开差距的是边界情况的处理。我见过太多人写完主流程就交卷结果判题器一跑空数组、单元素数组、全是重复元素、负数、超大数、字符串为null这些用例全挂。有一个很笨但有效的办法在写题时把边界情况直接列在代码注释里比如“如果输入数组为空返回 -1”。写完之后照着注释逐条检查能救回不少分。PayPal这类外企笔试尤其看重这一点因为支付系统里一个空指针异常就可能造成订单状态不一致严谨的态度比炫技重要得多。4.3 代码风格让阅卷人一眼看懂你在干嘛笔试代码不需要追求极致的压缩或炫技但要有清晰的逻辑结构。变量命名、函数拆分、注释措辞都很重要。我看到过很多同学喜欢写i、j、temp这样没有意义的命名在刷题平台上没问题但在笔试场景里会让人觉得你的代码还不够“工程化”。我自己的习惯是核心变量用完整英文单词比如transactionId、frequencyMap、remainingCount逻辑分区块用注释分隔关键算法步骤简单说明为什么这么做。这样写出来的代码哪怕最后不是最优解阅卷人也更容易看到你的思路主观评分上会占便宜。5. 判断一段代码能不能过的几个雷区笔试复盘的价值不只是看自己哪里对了更要看别人在哪里翻车。下面这些雷区是我当时和周围同学一起踩过、或者亲眼看到的基本上属于“一碰就掉分”的类型。5.1 雷区清单速查雷区类型典型问题正确姿势全局状态污染在static变量里保存中间结果多个测试用例共享每次用例独立初始化不依赖全局状态整数溢出数组长度或计算值超出int范围提前判题范围必要时用long大小写敏感字符串处理没考虑大小写统一统一toLowerCase()或明确区分大小写输入为空没判断空数组、空字符串入口先做空值校验重复元素处理去重、交集、计数场景出错用哈希表确定“每个元素出现几次”死循环风险链表、指针操作没有终止条件仔细检查循环条件和指针移动代码无法编译少括号、漏分号、类名不对写完先自己看一遍编译错误这张表在笔试前五分钟扫一眼能提醒自己养成肌肉记忆。我后来带人面试时也会直接在评审标准里关注这几个维度正确性、边界处理、复杂度、代码风格、可维护性。5.2 遇到完全没思路的题怎么办笔试中最崩溃的瞬间不是题目难而是看了五分钟完全不知道在说什么。我的应对策略是先写一个暴力解保证结果正确然后再考虑优化。哪怕时间复杂度是O(n²)也比空着或交一个错误解强。PayPal的判题系统通常会按通过的比例给分部分通过比零分好得多。另外不要害怕在代码注释里写自己的思路。比如“我想到可以用双指针优化但暂时先实现暴力版本”这既是给自己留后路也能让阅卷人看到你“知道有优化空间”。在真实工作中你不可能每次都一次写对但你是不是知道下一步该怎么优化是很重要的信号。5.3 复盘时如何定位自己的薄弱项笔试结束后不管结果如何我建议做一个三列表格的复盘题目类型、我的得分点、我的失分点。重点看失分是集中在算法思路不知道怎么做还是边界处理想到了但没写全还是编码基本功能想明白但写不出来。这三类问题的补救方式完全不同前者刷题中者练测试用例设计后者需要手写代码训练。我在准备下一场面试时会专门针对上一场暴露的问题做“定向突破”。比如发现自己链表题总是丢指针就集中练两周链表专项发现并发题思路不清就去看JUC包的源码和示例。笔试从来不是目的它是你能力地图上的体检报告。6. 如何为这类外企实习笔试做准备到了这一部分你已经知道笔试考什么、怎么答、怎么避坑但还缺一个行动的框架。下面是我总结的准备节奏按时间线排列适合实习和校招通用。6.1 时间线建议提前三个月开始别信“裸考也能过”如果目标是外企实习我建议至少提前三个月准备。第一个月梳理数据结构和算法基础做到核心题型随手能写第二个月开始做混合题型训练把算法题、工程题、行为题放在一次模拟笔试中限时完成第三个月刷目标公司往年的面经和模拟题同时定期做Code Review演练锻炼代码风格。有一个动作我特别推荐找一两套在线的笔试模拟系统严格按照真实考试的时间和环境走一遍。很多人第一次挂笔试不是因为不会做题而是因为不习惯在线IDE、不习惯没有本地调试的环境、不习惯不能Google。提前适应这些“非技术因素”性价比很高。6.2 选对练习材料少走弯路刷题平台上的题目浩如烟海但和PayPal这类外企笔试最贴近的往往是中等偏简单的算法题加少量并发、设计和场景题。我不建议一上来就死磕压轴难题那是竞赛选手的训练方式不是工程岗位的准备方式。更实用的做法是每天固定做2道中等难度题1道简单题每周末做一次限时模拟卷把“做完”变成“做对”“做稳”。我身边拿到外企实习offer的同学普遍不是刷题量最大的而是每日复盘最扎实的。错题本的价值远大于题量这一点几乎所有过来人都会同意。6.3 学有余力时补充一点系统视角如果时间充裕我建议了解一下分布式系统的基本概念比如幂等、一致性、限流、熔断、异步消息。不需要你达到架构师水平但至少要能说出“为什么支付回调要幂等”“为什么不能用简单的Thread.sleep做限流”。PayPal的业务属性决定了它对可靠性和可恢复性要求极高哪怕是实习生也要具备这种系统思维。很多同学在准备笔试时只盯着算法题忽略了这类“业务性技术题”。但实际上这类题目在笔试和面试中的出现频率越来越高。尤其对于支付、金融科技类公司让你设计一个接口或排查一个数据不一致问题比背一百道算法题更能看出真实水平。6.4 最后一点实际操作上的提醒根据我个人经验考试当天一定提前测试好电脑、摄像头、网络和IDE环境。很多在线笔试系统需要浏览器权限如果卡在环境检查环节非常影响心态。另外正式开考前通常有模拟题先花三五分钟把模拟题做一遍熟悉输入输出格式再开始正题。还有一个小技巧在代码开头写清楚import语句。在线判题环境里有些平台不会自动补全常用的包如果你写的是Java、C这类需要手动引包的语言漏掉import会导致编译失败。这类问题极其无聊但极其致命每年都有不少人都栽在这里。养成“先写import再写主类”的习惯能帮你避免一两次完全不应该的失误。实际上我在自己准备笔试时吃过最大的亏就是忽略环境模拟。总觉得题目会做就行结果第一次正式限时笔试时因为不熟悉在线编辑器的自动缩进整个代码排版乱成一团后来自己都看不下去。从那以后我每周都用在线平台做两场模拟练到手不抖真正开考时的感觉和平时练习就几乎一样了。准备这张卷子本质上是在训练一种“在限定时间内交付高质量代码”的能力这个能力在后续实习和正式工作中也一直用得上。希望你下次面对类似的笔试时能少一点临场慌乱多一点“这道题我见过”的从容。