蔚来汽车2024年秋招后端岗我投的是上海的团队简历筛选过了之后收到了笔试链接。整个笔试做下来感觉和互联网大厂的风格不太一样更偏业务落地和工程实践这里把整套题的考察思路和一些印象深刻的题目复盘一下给后面准备新能源车企方向的同学做个参考。1. 笔试全流程与题型分布速览1.1 投递背景与笔试平台蔚来的秋招后端岗主要面向2025届毕业生投递渠道是官网校招系统选择岗位的时候可以填意向城市和意向部门。我当时选了上海后面听说北京、合肥、南京也有不少后端hc。简历通过筛选之后HR邮箱会收到一封笔试邀请邮件里面附了笔试链接和注意事项用的是第三方在线笔试平台支持代码自动判题。整个笔试时长120分钟题量适中但信息密度很大。我印象里是四个部分单选题、多选题、问答题、编程题。单选多选覆盖的知识面非常广从Java基础、Spring框架到分布式中间件都有涉及问答题更像是简短的系统设计题需要你用文字把思路写清楚编程题有三道难度分布在LeetCode中等偏上的水平其中有一道明显贴合新能源汽车的业务场景。1.2 各部分的分值与时间分配建议从我自己的答题节奏来看选择题部分我花了大概40分钟问答题花了30分钟剩下50分钟全部留给编程题。这个时间分配比实际情况要紧张因为编程题里有一道我用了将近25分钟才完全调通最后一道题几乎是压线提交的。具体分值分布如下题型题目数量估算分值占比建议用时单选题15题30%20分钟多选题10题20%20分钟问答题2题20%30分钟编程题3题30%50分钟这里想提示一下多选题的评分规则是多选、错选不得分漏选得一半分所以拿不准的选项宁可不选也别乱选。我认识的一个同学就是多选里手一抖多勾了一个选项直接丢了整道题的分。1.3 整体难度判断说实话蔚来笔试的整体难度在秋招里属于中等偏上。选择题的深度不算太深但广度确实大比如有几道题考到了序列化框架的底层实现细节和分布式事务的隔离级别选择这些如果平时只背八股不深入理解原理很容易在两个相似选项之间犹豫。编程题的难度比字节、拼多多略低但比传统车企的信息化部门要高不少而且题目场景和车联网业务结合得很紧密这是很多同学容易忽略的地方。2. 选择题里的高频考点与几道印象深刻的题目2.1 Java基础与并发题目蔚来的Java基础题考察得很细有一道关于HashMap在JDK 8中的put流程选项里混入了先判断红黑树再判断链表长度这种顺序颠倒的干扰项如果你只是背结论而没有理清源码的执行顺序很容易踩坑。另外一道关于线程池的题也比较有代表性考察的是当核心线程数已满、阻塞队列已满、最大线程数也已满时拒绝策略的执行逻辑。这里不光是问默认的AbortPolicy行为还涉及CallerRunsPolicy在什么条件下会由提交任务的线程自己执行需要你对四种拒绝策略的触发条件和实际效果有清晰的理解。并发部分还有一道题问到了synchronized和ReentrantLock的区别但选项设置得比较刁钻比如两者都支持非公平锁这个选项其实是对的但很多人会被synchronized在JDK 6优化之后的性能表现迷惑住选了性能一定低于ReentrantLock。这说明蔚来出题是默认你了解锁优化的基本结论的不会在入门级别反复纠缠。2.2 Spring框架与微服务方向Spring相关的题占了选择题大概四分之一的比例。有一道题考的是Transactional注解在不同传播行为下的事务边界具体场景是A方法调用B方法B的方法上标注了REQUIRES_NEW然后B抛出异常问A方法的事务是否回滚。这个题如果你只是知道REQUIRES_NEW会挂起当前事务是不够的还得结合Spring AOP的代理机制来理解——只有通过代理对象调用B方法时事务增强才会生效。微服务方向考了一道服务熔断降级的题目给了一个调用链A - B - C当C服务响应超时拖垮了B的线程池之后应该从哪一层做熔断。正确的思路是B侧需要对C做熔断防止资源被持续占用而不是在A侧直接熔断整个调用链。这类题在新能源车企的后端笔试里出现频率不低因为车联网业务本身就是一堆微服务互相调用的场景。2.3 数据库与缓存结合场景有一道数据库题给了个SQL问的是联合索引(a, b, c)在where条件为b 1 and a 2 and c 3的情况下能否走索引。很多人一看到b在最前面就觉得索引失效了但MySQL优化器会做条件重排实际查询时会把a2放到最前面匹配联合索引的最左前缀原则所以是可以走索引的。这个考点属于典型的看着简单、错的人不少。Redis考了一道缓存穿透和缓存击穿的场景区分题。场景描述是某个热点车辆的实时位置key刚好在过期时间点失效瞬间涌入大量查询请求这种属于缓存击穿。很多人会混淆查询一个一定不存在的key穿透和热点key过期击穿这两个概念对应完全不同的解决方案。3. 问答题从业务场景拆解系统设计方案3.1 问答题一充电桩状态上报系统蔚来问答题第一道是典型的车联网场景题描述大概是全国有数千个充电桩每隔几秒会上报一次运行状态数据包括是否空闲、当前功率、故障码等需要设计一个后端服务来接收和处理这些状态数据并保证数据最终能可靠地展示给用户App端。这道题的考察点很清晰首先是接入层的设计充电桩通过MQTT协议上报数据后端如何承载高并发连接、如何处理协议解析。然后是数据链路上报数据需要经过消息队列削峰再异步写入时序数据库用于趋势分析同时实时状态需要同步到Redis供用户端查询。最后是可靠性如果某个充电桩上报中断怎么判断它是离线了还是只是网络抖动。我当时答的时候先画了一个数据流转的链路然后分模块说明每个环节的选型理由和可能遇到的问题。这里特别注意体现了消息队列为什么是必要的——如果充电桩直接写数据库一方面高并发写入会打满连接池另一方面业务高峰期和不高峰期的写入量差异巨大没有缓冲直接拖垮下游存储。3.2 问答题二车辆远程控制指令的可靠性第二道问答题更有意思场景是用户通过手机App远程控制自己的车辆比如远程开启空调、远程解锁要求设计一个保证指令可靠送达并执行的方案。这道题的难点在于用户发起的控制指令不能丢、不能乱序、也不能被重复执行。我当时的思路是先通过接口层做幂等控制用请求ID做去重然后把指令持久化到消息队列里下发链路要做消息确认机制ACK消息在车端执行成功之后回传结果给服务端。这里核心要答出幂等性设计的几种方案数据库唯一索引去重、Redis SETNX分布式锁、状态机标记以及消息队列QoS级别的选择。这道题直接决定了后面面试环节可能会深挖的方向。我后来在二面的时候就被问到Redis分布式锁在车控场景下的超时问题——如果车端执行指令的时间超过了锁的过期时间锁自动释放了另一个重试请求进来了指令就被执行了两次这种问题怎么解决。所以笔试里答到的方案面试环节一定要准备好对应的延伸追问。3.3 答题技巧画图与分点问答题在在线笔试平台里一般只支持纯文本作答不支持画图所以建议用文字描述清楚每个模块的边界和职责。我当时用接入层 - 处理层 - 存储层 - 通知层这样的分层结构来描述系统每一层单独起一行说明核心逻辑和选型理由最后补充了一个异常处理的小节说明如果消息投递失败会走什么补偿流程。一个好用的小技巧是在回答里主动指出某个环节存在什么潜在问题然后说明你如何规避。比如Redis缓存实时状态虽然快但需要处理数据一致性问题所以这里增加了版本号机制。这样的表达会让阅卷人觉得你不是在背方案而是真的思考过工程落地。4. 编程题结合车联网业务的算法实战4.1 第一题车辆路径的最近距离查询第一道编程题相对友好本质上是一道图论题。题面大致是给定一组充电桩的坐标和一辆车的当前坐标找到距离车辆最近的充电站并输出距离和充电站编号。这个题如果只是按最基础的思路做就是遍历所有充电站计算欧氏距离时间复杂度O(n)性能上完全可以接受。但题里给了一些附加条件比如充电站坐标很多且会有更新操作需要用一种数据结构来动态维护最近邻查询。看到这里就应该反应过来这道题的进阶解法是最小堆或KD树但实际笔试场景下用遍历就够了除非数据量达到百万级别。我提交的是排序解法读取所有充电站坐标计算与车辆的距离排序后取第一条记录。这道题核心是想看你的编码基本功和边界处理能力比如坐标负值、距离相等时的输出规则、输入格式的解析等。4.2 第二题用户行驶里程的并发累加问题第二道题开始带并发场景了。题面简化之后大概是一辆车每天会产生多条行驶记录每条记录包含行驶里程需要统计同一辆车在当天的累计行驶里程。由于多条记录可能同时上报要求最终统计结果准确无误。如果只是串行累加这就是一道水题但它明显在考察并发安全。我在答题时用了ConcurrentHashMap加AtomicLong的写法同时把每条上报记录先按照车辆ID分组再累加不同车辆之间的统计互不影响。这道题其实对应着真实业务中车辆数据上报的并发写入场景出题人很了解后端工程中常见的坑。4.3 第三题换电站电池调度的最短时间规划第三道题是压轴题题意大致是有多个换电站每个换电站里有一定数量的满电电池每辆车到换电站换电池需要花费固定的时间不同车辆到不同换电站的行驶时间不同问如何为N辆车分配换电站使得所有车完成换电的总时间最短。这是一道典型的分配优化问题最朴素的思路是贪心但贪心只在单维度目标下才最优这里其实需要用到二分答案加贪心验证判断给定时间T内能否给所有车完成换电。如果平时没刷过这种类型的题很容易卡住。我当时用的是优先队列加贪心策略把每辆车选择换电站看作一个任务分配每次让当前总耗时最小的换电站接收下一辆车但这种策略只保证局部最优。如果时间充裕更好的解法可以参考最小化最大完工时间的经典调度问题用二分猜答案然后验证在给定时间限制下每个换电站最多能服务多少辆车如果总数能覆盖N辆车则说明时间可行。这道题直接拉开了区分度。我估计很多人前两道题AC了第三道题测试用例过了一半不到但整体来看蔚来笔试还是更看重基础和是否能应对业务性较强的算法场景。5. 从笔试反推蔚来后端技术栈与岗位画像5.1 考点反映出的核心技术栈把整套笔试题拆开看蔚来后端岗的技术栈画像其实非常清晰Java是绝对的主流语言Spring Boot是基础框架Spring Cloud相关的微服务组件是加分项数据库方面MySQL是基本功但如果你对时序数据库有了解会是明显的简历亮点Redis缓存是标配分布式场景下还会延伸出分布式锁、分布式ID等考点消息队列Kafka、RocketMQ或MQTT几乎是必考的车联网场景下大量设备数据上报离不开消息队列车联网协议MQTT、HTTP/2等有了解会加分笔试虽然没有直接考协议细节但问答题里处处都有这些协议的存在感5.2 新能源车企后端和互联网后端的要求差异对比我之前做过的几家互联网大厂笔试蔚来的题目有几个明显差异第一业务场景驱动力强。不是纯考你数据结构或操作系统原理而是把一个真实的业务问题充电桩状态上报、车辆指令下发包装成题目让你在解题的同时感受到实际业务中的工程约束。第二对系统设计能力的考察比重更高。两道问答题都在考架构思路甚至编程题也在往调度优化的方向靠这种出题风格说明蔚来的后端团队确实需要具备全局视角的人。第三对可靠性、一致性这类工程问题的关注度更高。反复出现的幂等、消息确认、并发累加这些问题都是车联网场景下绕不开的核心痛点。5.3 笔试之后面试可能会深挖的方向笔试只是第一关考完之后大概一周内会收到面试邀约。从我后来面试的经历来看笔试里涉及的考点基本决定了面试问题的走向笔试里你提到用消息队列处理充电桩数据面试官就会追问消息队列的堆积问题怎么处理笔试里你提到用Redis缓存用户实时状态面试官就会追问缓存一致性怎么保证笔试里你提到幂等设计面试官就会追问分布式锁的过期时间问题。所以这里建议所有准备笔试的同学笔试做完后一定要留一个心眼把你答过的每道题都当作一个面试考点来准备。我就是在等面试通知的那几天把笔试里涉及的所有方案的优缺点、替代方案、极端情况都过了一遍后面面试的时候确实大部分问题都在射程范围内。6. 备考蔚来笔试的实用建议与踩坑复盘6.1 复习优先级排序如果你是准备投蔚来后端岗的同学我建议按照这个优先级来复习第一优先Java基础和Spring框架。这是选择题占比最高、最拉分的地方集合源码、并发工具、事务传播机制、Spring Bean生命周期都是高频考点。第二优先MySQL和Redis。事务隔离级别、索引失效场景、缓存穿透/击穿/雪崩的解决方式这些都是被反复考察的内容。第三优先分布式和消息队列。至少把Kafka/RocketMQ的基本架构、消息可靠性保障、顺序消费原理过一遍车联网的场景题离不开这些东西。第四优先算法题。蔚来的算法题不算最难的但是业务场景结合度很高平时刷题的时候多想想题目能不能对应到真实业务里会更有帮助。6.2 我踩过的坑复盘这套笔试我有几个比较后悔的地方多选题漏选扣分规则我一开始没注意有几道题为了求稳少选了选项但后来看正确选项其实是我本来就在犹豫的那个这直接丢了分数。编程题第二道并发累加题我一开始用了普通的HashMap提交之后发现并发测试用例没过才换成ConcurrentHashMap白白浪费了一次提交机会。问答题答第二题的时候我没有把补偿机制写清楚只写了正常链路后来复盘发现如果能把消息重试、对账补偿、失败告警这三个环节都加上答案就会完整很多。6.3 最后想说的秋招笔试本质上是一场技术积累 场景还原能力的综合测试。蔚来的题目给我的感觉是它不是在找刷题机器而是在找能理解车联网业务、能设计可靠系统、能把方案落地成代码的人。如果你能把每一道题都还原到一个真实的业务场景里去理解备考的效率和深度都会完全不同。