拼多多数据开发面试复盘一本3年经验聊点面试官真正会问的前段时间去拼多多面了数据开发岗岗位描述写的是“资深数据开发工程师”要求本科以上、3年以上大数据相关经验。我是一本学历做数开刚好三年简历过了初筛面了三轮技术加一轮HR总体感受是拼多多的面试风格非常务实不绕弯子但挖得很深尤其喜欢把你放在真实的电商业务场景里去问方案设计。这篇复盘我不会去罗列那种“背诵版八股文”而是结合我自己的面试经历把面试官在拼多多数开岗上真正关注的技术点、场景题、追问逻辑以及我踩过的坑一次性说清楚。内容偏数开方向涉及离线和实时两条链路适合正在准备大数据开发面试、尤其是想冲电商大厂的朋友参考。1. 岗位画像与面试前的准备思路1.1 拼多多数开岗到底在招什么人先说结论拼多多招数开要的不是“只会写SQL取数”的工具人而是能搞定数据链路、懂业务指标、遇到数据问题能独立排查的人。岗位名称虽然叫数据开发但实际工作会横跨离线数仓、实时计算、数据同步、数据服务几个模块偶尔还要接业务方的临时取数和报表需求脏活累活不少但确实能练人。面试的时候面试官会围绕几个维度来评估你基础硬实力Java、SQL、Linux、数据结构和算法这些是敲门砖过不了基本没得聊。大数据组件原理Hadoop、Hive、Spark、Flink、Kafka、HBase、Redis这些核心组件的原理和适用场景不能只停留在“会用”层面。业务理解能力面试官会丢一个拼多多实际的业务场景比如“多多买菜某个大区的销量波动怎么排查”“百亿补贴商品的价格变化怎么监控”看你能不能把技术方案落到业务上。项目深挖简历上的每个项目都会被反复追问从架构设计到细节实现再到你个人在项目中的角色和贡献一段不确定的细节都可能被揪出来。我这次面的岗位偏“实时数仓”方向所以Flink和Kafka被问得非常细。如果你面的是偏离线的岗位Hive SQL优化和数据仓库分层设计会是重头戏但Flink基础也不会跳过。1.2 三年经验的核心竞争点应该放在哪三年经验的数开既不是应届生也不是资深专家处于“能独立扛事但还需要人把关”的阶段。这个阶段面试最怕的就是简历上全是项目名但问到底层原理就含糊其辞。我自己在准备时复盘了一下三年经验应该重点展示这几个信号独立负责过完整的数据链路从数据接入、清洗加工、模型设计到下游应用你至少有一个项目是全程跟下来的知道其中每个环节的坑。踩过坑并且能总结出方法论比如数据倾斜、Kafka消费积压、Flink状态过期、HBase热点问题这些是面试官最感兴趣的实战经验比背一百道面试题都管用。有技术选型的判断力什么时候用Spark、什么时候用Flink什么时候用Hive、什么时候用ClickHouse能说出选择依据和权衡而不是“公司用什么我就用什么”。拼多多的面试官特别吃“你说细节”这一套。你说你做过实时大屏他会追问Flink的checkpoint间隔怎么设的barrier对齐机制了解吗状态后端用的什么背压从哪一层开始处理。这些细节问题刷掉很多人就是简历写得太花哨实际落地经验撑不住。2. 拼多多业务场景下的技术栈全景2.1 电商数据链路从商品到订单再到报表拼多多的业务链路和其他电商平台大同小异但有其特殊性SKU数量级巨大、商家自运营占比高、大促流量峰值凶猛、百亿补贴和秒杀这类活动对实时性要求极高。整个数据链路大致可以拆成几个环节数据源层MySQL订单、商品、商家、用户行为日志埋点上报、服务端日志Nginx、Java应用日志、第三方数据商品评论、竞对监控等拿到的形式可能是爬虫采集或API对接。数据同步层离线用DataX或Sqoop做批量同步实时用Canal监听MySQL binlog配合Kafka做消息管道。数仓分层ODS原始数据层、DWD明细层、DWS汇总层、ADS应用层拼多多很多数仓团队也把这套模型贯彻得很彻底。计算引擎离线以Hive/Spark为主实时以Flink为主大促期间实时计算的任务量会飙得很高。存储与服务明细和汇总结果常用Hive表、HBase、Redis、ClickHouseADS层结果通过接口服务或报表工具暴露给运营、产品和商家后台。面试官在聊项目时最常干的事情就是把你简历里的某个环节丢回这套链路里问如果某一步出问题了你怎么排查。比如“订单同步延迟了你怎么定位是binlog消费慢了还是下游写HBase出问题了”这种问题没有真实的链路排查经验很难答得漂亮。2.2 离线数仓和实时数仓在面试中的考察权重拼多多数据开发岗的面试离线数仓和实时数仓都会考但侧重点不同。离线侧准备的时候重点看Hive SQL优化、数据倾斜处理、分区表设计、小文件治理另外数仓规范命名规范、分层规范、指标一致性也要能聊出几条来。实时侧则重点看Flink的窗口计算、状态管理、精确一次语义、背压处理、Kafka的消费模型和消息保障。我当时面的岗位更偏实时所以面试官在聊完项目后直接给了一道实时计算场景题商品维表变化怎么和订单流关联要求用Flink实现并说明为什么这么选。这就是典型的“业务技术”融合题目光会API调用是不行的得理解维表关联的几种方式广播流、异步IO、Lookup Join以及各自的性能代价。还有一个值得注意的趋势拼多多内部对数据API、数据服务这块的需求很大因为商家后台、运营后台都要实时查数据。面试时可能会问你怎么设计一个高并发的数据查询服务这就要求你对Redis缓存、ClickHouse查询性能调优、甚至简单的索引原理都有了解。热词里反复出现的“拼多多api”“拼多多爬虫商品数据”也侧面反映外部对拼多多的商品数据获取和接口对接有大量需求如果你做过这类数据采集或开放平台对接项目面试时可以拿出来讲这是个不错的加分项。3. 高频面试题拆解离线与实时方向3.1 SQL与离线数仓拼多多风格的热身题第一轮技术面通常从SQL开始但拼多多的SQL题绝对不是leetcode那种“写出来就过”的难度。它喜欢把业务背景揉进去比如“统计拼多多每个大区近30天销售额Top10的商品并给出销售额贡献占比”这题表面看是窗口函数实际上还考察了去重策略、分区裁剪、数据倾斜规避。类似的高频SQL题大概有这几类分组TopN问题每个类目下销量最高的3个商品典型解法是ROW_NUMBER() OVER(PARTITION BY category_id ORDER BY sales DESC)。留存率计算给了用户登录表算次日留存、7日留存。重点在于去重逻辑和日期差计算的写法。连续N天问题找出连续3天都有购买行为的用户。解法套路是用日期减去行号得到分组标识再按组聚合这个必须熟练。中位数问题求每个店铺订单金额的中位数用PERCENTILE_CONT窗口函数或近似算法。面试官会在你写完SQL后追问如果这张表有上亿条数据你的写法还扛得住吗分区怎么设计数据倾斜怎么办这些问题比SQL本身更能看出你的实战水平。我自己在回答这类问题时都会先说出一个正确解法再主动补一句“如果数据量特别大我会考虑加过滤条件减少扫描行数或者把热点key单独拆分处理”面试官对此普遍比较认可。3.2 实时链路Flink和Kafka是绕不开的重头戏拼多多对实时计算能力的要求很高原因很简单大促期间活动效果、订单量、直播带货数据都需要秒级或分钟级刷新离线数仓根本满足不了业务方“实时要看数据”的诉求。Flink相关的高频考点我总结下来有这些窗口计算滚动窗口、滑动窗口、会话窗口各自适用什么场景窗口内数据乱序怎么处理允许乱序的延迟时间设多少合适。状态管理Flink的状态存在哪里状态后端MemoryStateBackend、FsStateBackend、RocksDBStateBackend怎么选状态过大怎么办。Checkpoint机制什么是barrier对齐为什么Flink能实现精确一次语义checkpoint间隔设置的原则。背压问题什么是背压如何定位背压源头背压时应该扩并行度还是优化算子链路。Kafka相关的考察主要集中在消息不丢失怎么保证生产者端ack机制broker端副本机制消费者端手动提交offset。重复消费和消息乱序怎么办为什么会重复消费业务侧怎么做幂等单分区保证有序但多分区怎么处理。消费积压怎么处理先定位是生产快还是消费慢再考虑扩容消费者实例、增加分区、优化下游写入性能。我当时被问了一个比较刁钻的组合题如果Flink任务消费Kafka下游写到HBaseHBase出现RegionServer热点导致写入超时Flink任务开始出现反压最终消费延迟越来越大。问我要怎么排查和处理。这题就是把Kafka消费、Flink背压、HBase性能问题串在一起考考察你对整条链路排错的能力。我的回答思路是先通过Flink UI看背压线程定位是不是HBase写入算子瓶颈然后查HBase的Region分布看是不是rowkey设计不合理导致热点再做双管齐下的处理一方面临时增加HBase的预分区或调整写入策略另一方面降低Flink写入并发或者开启批量写先把消费延迟降下来再说。面试官反馈说思路是对的但还追问了“为什么批量写能缓解热点”——这就是提醒我要理解批量写减少了RPC次数实际上降低了HBase服务端的压力。3.3 数据采集与“爬虫系”场景题充电宝数据、商品数据类的打开方式热词里有一大堆“拼多多充电宝数据”“拼多多抓取充电宝”“拼多多爬虫商品数据”这样的关键词说明很多人对拼多多相关的数据采集、商品监控场景很感兴趣。这类问题在面试里也有可能出现只是问法更干净比如“如果你需要监控竞品平台上某类商品比如充电宝的价格和销量变化你会怎么设计数据采集方案”。我当时确实被问到了类似的问题原题大意是业务方想做充电宝品类的市场分析需要你从公开渠道获取商品的价格、评价数、销量等数据落到数仓后做多维分析。面试官说他并不限定获取方式让我完全开放地聊方案。我当时的回答思路大致是这样的盘点数据来源优先看有没有开放API如果有就申请接口对接合规又稳定没有API的情况下再考虑爬虫方案。爬虫方案的核心设计请求调度模块负责按一定频率抓取商品列表页和详情页要做好请求头伪装、访问频率控制、代理IP池解析模块把HTML或JSON格式的商品数据抽出来映射成结构化字段清洗模块做去重、异常值过滤、价格单位归一化最后落到数仓ODS层再按业务需求加工成DWD和ADS。数据质量保障要设计定时校验任务比如每天比对抓取到的商品总数和历史数据出现断崖式下跌要告警价格字段要做环比波动监控避免解析逻辑改版导致数据大面积异常。合规和安全意识要遵守平台规则控制抓取频率不触碰用户隐私数据只获取公开的商品信息用于分析。面试官接着追问了一个细节如果你抓取的商品详情页里销量不是直接展示的数值而是“10万”这种模糊表达你怎么处理。这个问题比较有意思我当时回答的是用上下限区间来存储同时结合评价数、收藏数这些字段做一个销量估算模型给业务方输出一个估算区间而不是一个伪精确的数值。面试官对这题比较满意说很多候选人会直接答“取不到就置空”没有考虑到业务分析的实际需求。3.4 Java与中间件数开岗位的第二道门槛很多做数开的朋友容易忽略Java基础觉得能写Flink任务和Hive SQL就行。但拼多多对Java基础是有要求的尤其是你简历里写了“基于Flink开发实时任务”面试官默认你Java是能写明白的。我遇到的高频Java问题包括HashMap的底层原理put操作发生了什么什么时候扩容为什么要用红黑树。JVM内存模型堆和栈的区别垃圾回收算法年轻代和老年代怎么划分Flink任务经常出现Full GC怎么排查。并发编程synchronized和ReentrantLock的区别 volatile的作用线程池的参数和拒绝策略。分布式锁Redis实现分布式锁的setnx命令死锁怎么避免Redisson的原理以及ZooKeeper实现分布式锁的思路。这其中的分布式锁面试题在热词里出现频率很高拼多多这类大厂也确实爱考。常见的追问链条是先让你说Redis分布式锁的实现方式你答了setnx加过期时间面试官会追问“过期时间设多少合适”“业务没执行完锁过期了怎么办”“怎么实现可重入”每一个都是坑。我的建议是不要只背Redisson的实现细节还要理解看门狗机制的本质是“用定时续期来对抗业务执行时间的不确定性”这个思想在Flink的checkpoint超时处理上其实也是相通的能跨技术栈找到共性会让面试官印象更深。Redis和Kafka在数开岗面试里出现的频率也很高。Redis除了分布式锁还会考缓存穿透、缓存击穿、缓存雪崩以及数据一致性这些场景在电商大促期间全是真实存在的。我当时被问到一个实际业务题百亿补贴商品的价格变化很快但数据库读写压力很大怎么保证前端展示的价格不出现长时间的不一致。我给出的方案是缓存设置短过期时间比如30秒同时数据库变更后通过binlog异步刷新缓存在极端情况下允许短时间不一致但要通过监控告警尽快恢复。面试官说这个方案在工程上是可行的还补了一句“关键是定义好可接受的不一致窗口”这句话我觉得很值得记下来设计任何缓存方案前先想清楚业务能容忍多脏的数据。4. 系统设计类场景题实录4.1 设计一个商品销量实时看板这题是拼多多面试里的常客因为拼多多的运营后台确实到处是实时看板大促实时成交额、品类实时销量排行、直播带货实时GMV。面试官给的需求描述通常很简单“业务方需要一个实时看板展示全站Top100商品的实时销量和销售额更新频率要求秒级。”这题考察的是端到端设计能力我建议从数据接入、实时计算、结果存储、前端查询四条线来答。数据接入线商品订单数据在MySQL里通过Canal监听binlog把订单变更事件发到Kafka。之所以不用订单表全量扫描是因为大促期间订单量爆炸全量扫描对业务库是灾难。行为日志类数据则通过埋点SDK直接上报Kafka。实时计算线Flink消费Kafka里的订单事件按商品ID维度做累计窗口聚合。这里要说明选择滚动窗口还是会话窗口以及状态存储的设计。如果要做到秒级更新通常用ProcessingTime加滚动窗口窗口大小可以设成5秒或10秒避免窗口太短导致输出过于频繁。结果存储线聚合结果写入Redis用ZSET存储商品ID到销量的映射方便做TopN排序。为什么用Redis因为看板查询QPS很高走HBase或ClickHouse虽然也能扛但Redis的响应延迟最低而且ZSET天然支持TopN运算。前端查询线前端接口直接查Redis ZSET用ZREVRANGE取Top100再用商品维表补充商品名称、类目、价格等信息。这里要提一下维表关联的几种方案最简单的是启动时全量加载商品数量不庞大时完全够用。面试官会在你答完这套方案后加追问如果某台Flink TaskManager宕机了怎么保证状态不丢、结果不丢这时候就要把checkpoint机制和Kafka offset提交策略讲清楚同时说明重建后Redis里的数据是用增量累计方式恢复的不需要全量重算。另外一个常见追问是如果恢复期间看板数据出现回退比如少了最近几秒的数据业务上能不能接受——这时候要给出一个可接受的数据延迟标准并说明在最终一致性模型下看板秒级延迟内的回退是可以接受的但要通过监控尽快追上。4.2 订单数据从MySQL到数仓的同步链路设计这题考察的是数据接入和链路稳定性。拼多多的订单量峰值极高MySQL主库扛不住大量查询分库分表是常态所以数据同步方案要考虑多分片的情况。我当时的回答分了几层选择Canal作为binlog采集工具部署在MySQL从库上对主库无侵入。Canal将binlog变更事件转成JSON格式发送到Kafka按订单ID或分库分表键做分区保证同一个订单的变更事件进同一个分区这样Flink或Hive消费时能保证顺序。离线链路中Kafka里的数据通过Flink或DataX定期落到Hive ODS表按天做分区实时链路中Flink直接消费Kafka做实时计算。需要考虑全量加增量的初始化过程首次建仓时用DataX做全量同步之后用Canal做增量同步两条链路的数据通过业务主键做合并。面试官比较在意的点是“怎么保证不丢数据”“怎么保证不重复”以及“binlog里如果包含DDL怎么办”。不丢数据要靠Canal本地持久化和Kafka的ack机制保障不重复则要靠下游的幂等写入比如Hive表按主键去重、HBase采用put覆盖写入、Redis采用set覆盖写入DDL的话一般需要专门的DDL同步机制或者定期做一次元数据对比校验确保表结构变更不会把同步链路打断。4.3 数据质量和血缘管理容易被忽略但常考的加分项拼多多业务迭代快数据需求的变更也快数据质量问题是数开最头疼的事之一。面试里出现数据质量问题也很常见比如“运营反馈报表数据和昨天对不上你怎么排查”。这类问题考察的不是某个具体工具而是你的排查思路和工程习惯。我建议按以下顺序来排查先确认数据口径有没有变化是不是同一个指标定义改了比如“GMV”从“支付成功金额”变成了“下单金额”导致数据对不上。再查上游数据有没有异常比如埋点日志缺失、binlog消费延迟、同步任务失败这会导致ODS层数据不完整。然后看加工逻辑SQL里是不是出现了非确定性函数是不是join导致数据膨胀是不是过滤条件被人改动过。最后对比历史数据看波动发生在哪个层级哪个任务节点缩小范围后修复并补数。血缘管理也是一个高频软考点。拼多多集团内部有比较完善的血缘系统面试官可能会问你怎么设计一张指标的血缘图谱。回答思路是采集任务解析SQL抽取表和字段的依赖关系存入血缘图数据库提供字段级的上游追溯和下游影响分析。这套东西说起来简单但做起来工作量很大面试时能讲清楚字段级血缘分析怎么做就比一般的候选人强不少。5. 常见问题与排查技巧实录5.1 我踩过的坑和现场答不上来的瞬间我在准备过程中踩了不少坑挑几个典型的说希望对你有帮助。第一个坑是简历里写了“精通Flink”结果面试官问Flink的checkpoint和savepoint的区别时我第一反应答的是“一个是自动的一个是手动的”。这个回答太浅了。面试官真正想听的是savepoint是用户手动触发的需要指定路径常用于停机升级或版本迁移checkpoint是Flink自动周期性触发的用于故障恢复而且checkpoint可以配置增量或全量。这个问题暴露了我“会用框架但不深究原理”的毛病后来我把Flink核心概念全部过了一遍源码级别的原理再面就顺很多。第二个坑是场景题一开始想得太复杂。有一道题是“如何统计拼多多某一天的新增用户数”我上来就准备答一套复杂的位图法、HyperLogLog方案结果面试官说你要不要先说说什么是“新增用户”的定义。我一下子意识到自己把简单问题复杂化了新增用户可以在ODS层用用户首次下单或首次访问日志来确定然后按天去重计数即可根本不需要那么高级的算法。这个教训是先确认口径再谈方案方案永远跟着口径走而不是一上来就堆技术。第三个坑是SQL题里写了一个大JOIN结果当场被要求优化。面试官给了一张用户表和一张订单表要计算每个用户近30天的订单总额。我一开始用了LEFT JOIN加GROUP BY面试官说订单表有几十亿行你这么做会死。后来改成先在订单表按用户ID和日期做子查询聚合再和用户表关联大大减少了JOIN的输入数据量。这种优化在离线数仓中非常基础但面试高压环境下容易脑子短路建议平时多练习。5.2 面试官追问的底层原理怎么接拼多多的面试官非常喜欢追问底层原理基本每个问题的第一层回答之后都会被继续追问。总结下来有两个规律第一个规律是“你说了什么他就揪什么”。你如果提到“Hive on Spark比MapReduce快”他一定追问为什么快所以你要能说出Spark的DAG调度、内存计算、避免了MapReduce频繁落盘这些关键点。如果你提到“HBase适合随机读写”他一定追问为什么适合这时候要答出LSM树和有序存储。因此不会的不说说了的一定要能讲透。第二个规律是“类比追问”。比如你讲了Redis分布式锁的过期时间问题他可能话锋一转问你Flink里有没有类似的问题。这时候要能联想到Flink的checkpoint超时和状态过期清理本质上都是“时间边界和业务不确定性的对抗”。能跨技术领域找到共性的候选人面试官会觉得你有架构思维而不是只会背API。关于如何回答不会的问题我踩过几次坑之后总结出来的策略是先坦诚说“这个细节我没深入研究过”然后给出自己的推理过程比如“但根据我对XX的理解它应该是通过XX机制来解决的”最后再补一句“我回去会看一下这块”。不要乱编不要沉默这样反而能给面试官留下诚实且具备排查能力的印象。5.3 简历准备和自我检查清单最后聊聊简历虽然标题是面试题但简历决定了面试官会问什么重要程度不亚于刷题。简历上每个项目建议都按这个模板来写项目背景为什么做— 技术架构怎么做— 数据规模多大— 个人职责你做了什么— 难点和解决方案最有价值的部分— 项目成果量化指标。尤其要注意数据规模拼多多面试官很看重你对数据量级的感知。你说“实时计算订单数据”没人会觉得厉害但你说“高峰期QPS 5万日订单量千万级Flink任务并行度48单任务吞吐每秒10万条”面试官立刻对你的项目规模有了概念。另外简历里提到的每一个组件都要准备“为什么用它”的回答。写了ClickHouse就准备好回答“为什么不用Doris或StarRocks”写了Canal就准备好回答“为什么不用Maxwell或Flink CDC”。技术选型问题没有标准答案但必须体现出你做过功课和权衡。我建议在面试前一周系统梳理一遍自己的项目把每个项目可能被追问的问题列出来并写下回答。尤其是关键参数比如Flink窗口大小、checkpoint时间间隔、Kafka分区数、Redis缓存过期时间、HBase预分区策略这些细节最容易被追问也最能体现项目的真实性。6. 实时计算场景题专项大促血拼下的数据洪流拼多多面试中还有一个专项方向很多人容易忽略就是“大促场景”。双十一、618这类大促在拼多多叫“百亿补贴”“周年庆”对数据链路的核心挑战是瞬间流量洪峰。面试时如果聊到大促面试官通常会问你怎么保障实时任务的稳定性。大促保障方案我建议从三个层面来答资源层面要提前扩容Flink并行度、Kafka分区数、HBase Region数都要按预估峰值做准备最好做一次全链路的压测任务层面要给核心实时任务设置独立的Slot和优先级避免非核心任务抢占资源同时关闭一些不重要的实时任务比如一些低优先级报表的实时计算降级层面要提前设计开关比如大促期间不再做精确一次语义改用至少一次语义换取更低的延迟这在业务上是可以接受的。还有一个常见追问是“大促期间Flink任务状态太大怎么办”。这里需要先分析状态从哪里来如果是窗口聚合产生的临时状态可以通过减小窗口大小、增加清理频率来优化如果是维表关联产生的缓存状态可以对缓存加TTL如果状态实在太大就要考虑改用外部存储比如HBase保存状态虽然牺牲了一些性能但能避免频繁Full GC和checkpoint超时。大促场景题在拼多多面试中出现频率很高因为拼多多的业务形态就是大促密集、活动密集。我建议把所有实时计算的问题都往“大促时会出现什么情况”这个方向去延伸思考这样回答出来的方案会更有电商特色也更能打动面试官。7. 最后的实操建议关于拼多多面试的几点体会面试拼多多数开岗最大的感受是它不太看证书和名头也不怎么问那种“背诵型”的八股题更看重你“有没有真实扛过数据链路”。如果让我给准备面试的朋友提几条可落地的建议我会说这些第一把SQL练到肌肉记忆。Hive SQL和Spark SQL的窗口函数、聚合优化、数据倾斜处理要能做到看到题就有思路写出来不出大错。这是第一轮最容易挂的地方。第二Flink和Kafka不要只停留在会用。把checkpoint机制、状态管理、背压处理、exactly-once原理搞清楚最好能画得出它们之间的协作流程。面试官深挖这些细节时你如果答得出来会直接和“只会调API”的候选人拉开差距。第三准备几个“带有排查过程”的项目故事。面试官问我最多的不是“你这个项目做了什么”而是“这个项目上线后出过什么问题你怎么解决的”。一定要准备两个真实出现过的故障案例把排查过程讲得特别细包括你怎么看监控、怎么定位、怎么修复、后续怎么防范这种故事比任何技术点更能体现你的能力。第四对拼多多的业务场景要有所了解。面试前花点时间看下拼多多的主要业务板块比如百亿补贴、多多买菜、拼小圈、多多视频每个业务的数据特点都要能说出一二。比如多多买菜的时效性要求很高因为涉及生鲜和同城配送所以实时数据链路要尽量缩短延迟百亿补贴的商品价格波动频繁价格变化监控就需要秒级或分钟级的检测。这些业务理解会让面试官觉得你不是一个纯粹的技术执行者而是能用技术解决业务问题的人。第五不要忽视算法题。虽然数开岗的算法题没有后端岗那么难但拼多多还是会出LeetCode中等偏简单的题我这次就遇到了一道数组相关的题目要求用O(n)复杂度解决。所以每天保持刷一两道题的手感还是很有必要的算法挂了前面的技术面全部白费。最后说点掏心窝的话3年经验去拼多多其实是一个很好的节点。这个时候你的技术基础已经稳固又有一定的项目经验可以深入聊面试官不会拿应届生的标准要求你也不会拿专家岗的标准卡你只要展现出扎实的链路能力和解决问题的思路拿到Offer的概率是很大的。希望这篇复盘对你有用也能让你在准备面试时少走一些弯路。