普通面经（中）：从算法手撕到HR面的避坑指南
作为一个写过“普通面经（上）”的求职者，我原本以为面试这件事的焦虑峰值会在投简历阶段结束。真正走到“中”这个环节——算法手撕、项目拷问、系统设计、HR面——我才发现，最耗神的不是知识储备不够，而是“明明准备了，临场却用不出来”。这篇就接着上一篇，把面试进行中的完整过程、被追问的细节、以及我踩过的坑原原本本写出来。
这篇面经不带任何“逆袭”“大厂”“OFFER收割”之类的光环，就是一场普通得不能再普通的求职面试记录。但它可能比那些晒package的帖子更贴近大多数人的真实处境：技术栈不深、项目不亮眼、刷题量一般，却依然想通过认真准备拿下一个不错的机会。如果你也处于“简历已经投出去、面试通知陆续开始到”这个阶段，本文的每个环节、每道题、每句追问，你大概率都会遇到。
1. 面试前的准备思路：我把时间花在了这三件事上
面试这件事，准备的方向比时长重要得多。我见过刷了三周题结果连自我介绍都卡壳的人，也见过简历平平但每次面试都能把话题引到自己擅长领域的人。我这个阶段不算优秀，也没法跟ACM大佬比，但我尽量把时间花在“能直接转化为面试输出”的地方。
1.1 先把目标岗位的JD拆开看，而不是看个大概
拿到面试通知后，我第一件事不是打开LeetCode，而是把岗位上写的每条职责要求重新读了一遍，并且做了个很土的表格：左边是JD里的关键词，右边是我能对应的真实经验。比如JD写“熟悉分布式缓存应用”，我就写“项目里用Redis做过热点商品缓存，遇到过缓存穿透，最后用布隆过滤器+空值缓存解决”。
这个动作看起来简单，但作用非常大。因为大部分面试官的习惯，是照着岗位要求从你的简历里找“可问的点”。你提前把这些点标出来，等于给面试官画了一条他大概率会走的提问路径。我后来复盘发现，三轮技术面里约七成的问题，都落在我这张表格提前画好的范围内。
1.2 简历上每一条项目经验，都提前准备好“十连问”
面到中途才发现，简历不是写出来的，是答辩用的。我有个很深刻的教训：“负责订单模块开发”这句话，在面试现场会被拆成十几个子问题——订单状态怎么设计的、超时未支付怎么处理、库存扣减怎么保证一致性、如果并发高怎么办。
所以准备阶段，我给自己定了一条规矩：简历上每一句项目描述，都要能往下接至少十个问题。接不出来的那部分，要么是想办法补课搞懂，要么就改简历说得保守一点，不要给自己埋雷。尤其要注意，“用过Redis”跟“聊得明白Redis”是两回事，不能存侥幸心理。
1.3 刷题和八股的投入配比，我选择了七三开
网上很多声音说“算法是核心，八股不重要”，我自己的感受是：对不同level的面试，配比应该不一样。我面的岗位偏业务后端，面试流程下来，算法题占比大概三成，剩下七成都是项目、基础知识和场景题。所以我准备时间的分配是：七分放在项目和综合知识梳理，三分刷高频算法题。
这样的分配让我在面试时不至于出现“算法全对、项目一问三不知”的尴尬局面。而且说实话，面试官问到项目的时候，那种你能流畅讲出细节、逻辑闭环的状态，比手撕出一道Hard题更让他放心。
2. 算法手撕环节：从“会做”到“能讲清楚”的落差
算法题这里我不想贴太多原题，因为每家公司题库都不一样，但我想聊一个所有面过试的人都会有共鸣的点：在本地编辑器里安静刷题，和面试现场白板写代码，完全是两种状态。我第一场技术面就因此吃了大亏。
2.1 第一场面试的第一道题：我栽在了一个变形的二分查找
题目本身不难，是“在一个有序数组里查找第一个大于等于目标值的位置”，也就是标准的lower_bound。我在LeetCode上做过类似题，当时觉得轻轻松松。但在面试环境里，我犯了两个错：第一，没有先跟面试官确认边界条件就开始写；第二，写完之后没有主动举例子验证。
面试官看了一眼我的代码，问我：“如果数组里所有元素都小于target，你的代码会返回什么？”我愣了几秒才意识到，我的初始化值有问题。这道题最终磕磕绊绊改对了，但整个过程暴露出来一个问题：我只会“闷头写”，不会“边写边说思路”。面试官在算法环节其实不只想看结果，他更想看你是怎么思考的。
后来我把手撕题的节奏固定成四步：先跟面试官确认输入输出和边界，再讲思路和复杂度，然后动手写，最后举一两个用例手动跑一遍。这个习惯帮我后面几场面试避免了好几次翻车。
2.2 第二道题：二叉树层序遍历，面试官追问的三连
这道题是中规中矩的BFS模板题，我顺利写完了，但面试官开始连环追问：如果要求按层输出二维数组怎么办？如果要用DFS实现怎么做？如果树特别宽，内存有什么风险？
前两个问题我答上来了，第三个问题让我愣了一下。我从来没考虑过BFS队列的空间复杂度在极端情况下的表现。面试官没等我完整回答就笑了笑说“这个回去可以查查”，这就是一个非常明显的信号——他对你的考察其实已经超出了“能不能写出代码”，而是“你对这个代码的理解深度”。
所以我的建议是：刷题的时候别只追求“AC”，一定要问自己三个问题——这个解法为什么正确？复杂度是多少？如果换一种思路还能不能解？面试官问的很多“为什么”，都藏在这三个问题里。
2.3 手撕题中一个很容易被忽略的细节：命名和结构
面试官看代码的时候，不会像机器那样只关心逻辑。给变量起名、把判断条件的结构写清晰，这些都会影响他对你代码素质的判断。我第一次写出的代码里变量名全是a、b、tmp，面试官当时没直接批评，但从他的神情能看出来，这印象分已经扣了。
后来我刻意在面试前提醒自己：变量名用有含义的单词，循环里的临时变量也用cur、prev这类可读名；多写几个helper函数，别把所有逻辑堆在main函数里。代码整洁这个习惯，不是面试官要求的，而是你自己职业素养的体现，什么时候都加分。
3. 项目深挖：面试官真正想从你的项目里听到什么
算法题只是开胃菜，我面的几家公司，技术面一半时间都在聊项目。没有大厂高并发背景的普通人，最容易在这个环节失去自信——但我的体验是，项目本身不出彩没关系，讲项目的方式和逻辑，才是面试官真正在意的。
3.1 被追问得最狠的一轮：我的项目复盘全过程
有一场面试，面试官对着我简历上一个很小的模块“短链接转换服务”问了整整四十分钟。一开始我很奇怪：这个项目难度不高，也没多少用户，值得问这么久吗？后来我才反应过来，他是在故意锚定一个具体场景，看我能挖多深。
他先问我：短链接的key怎么生成的？我答了哈希后转Base62。他接着问：哈希冲突怎么办？我说加随机盐重试。他又问：如果并发同时生成同一个原始URL，你怎么保证不会生成重复的短链？到这里我有点卡壳，最后只能答出“在数据库加唯一索引，让数据库帮我们拦截”。然后他笑了，说“可以，这就是一种方案”。
那一轮下来我最大的感受是：面试官问项目，其实并不指望你有惊天动地的架构，他是在看你在真实工程约束下能不能做合理的取舍。哪怕你的答案不完美，只要逻辑自洽、能自圆其说，他反而会认可。最怕的是简历上写了“用了Redis”，结果被问“那为什么用Redis不用本地缓存”这种问题时，只有一句“因为大家都这么用”。
3.2 “你们项目的QPS是多少”——这个问题的真实意图
每个做业务项目的求职者应该都被问过：“你这个项目并发量有多大？QPS多少？”我当时的真实情况是：根本没有线上流量，只是自己搭的Demo项目。第一次被问到的时候，我含糊其辞，场面一度很尴尬。
后来我学到的说法是：主动说明项目的性质，然后给自己预设一个合理的假设场景。比如“这是一个个人项目，没有真实线上流量，但如果要做的话，我会按每秒几百次的读请求来设计，用Redis做缓存、异步写库，并思考极端情况下的降级方案”。这种回答反而能让面试官看到你主动思考系统设计的意识。
别为了显得厉害去编一个“我们是千万级QPS系统”，那是给自己挖坑。懂行的人三句话就能问穿你的数据，不如坦诚项目的定位，然后把重点放到设计思路和取舍上。
3.3 STAR法则被低估的地方：不是用来背稿，是用来防追问
大家应该都听说过用STAR法则（情境、任务、行动、结果）来描述项目，但绝大多数人只是把它当成“写简历的格式”。对我来说，STAR法则真正值钱的地方是：它天然帮你准备好了一整套故事逻辑，当面试官随机切入“你当时怎么做的？”“遇到了什么难点？”“最后效果怎么衡量？”这些问题时，你不需要现场编，只要顺着结构把对应段落拿出来就行。
我在准备的时候，给每个项目写了三四段STAR结构的话术，并且针对每段话术预演了面试官可能会追问的3个问题。这个“预演追问”的动作很费时间，但面试现场的回报极高。
4. 系统设计与场景题：普通开发者的突围办法
没有了海量数据背景，也没有大厂高并发经验，听到“系统设计”这四个字的时候，第一反应就是虚。但面到了第三轮，我发现面试官出的场景题其实还在一个“普通后端工程师应该掌握”的范围内，并没有让我设计一套秒杀系统或者全球分布式存储。
4.1 有一道题让我对系统设计彻底改观：“设计一个点赞功能”
当时听到这题我差点笑出声，觉得这也太简单了。但面试官接下来五分钟的提问，让我意识到“赞功能”这四个字背后可以铺开多少内容：点赞关系怎么存？用什么数据结构？用户点完赞之后，如何保证幂等？如果用户量大，一个用户给多个内容点赞，数据量涨得很快，怎么分表？点赞数需要实时的吗？能不能用缓存？缓存和数据库不一致怎么办？
他才问了四五个问题，我就已经觉得自己的脑子里只有一个“表结构”的雏形。但这场面试反而给我最大的启发：系统设计题不是让你凭空设计一个完美架构，而是考察你在被一个接一个的问题推着走的时候，能不能稳住节奏、分点拆解。
4.2 我后来总结的一套“普通人友好版”设计思路
这里直接分享一套我在后面几场面试里反复使用的思考框架，不一定最优，但对没搞过系统设计的普通后端足够用了：
- 第一步，先问清楚需求。这个功能谁在用？是C端还是后台？读写比例大概什么样？数据量预估有多大？
- 第二步，给一个最简模型。先画表结构、定义接口，把逻辑跑通，不引入任何中间件。
- 第三步，找到瓶颈点。在读多写少的地方加缓存，在写频繁的地方考虑异步和削峰。
- 第四步，说清楚取舍。为什么这里用Redis不用Kafka？为什么这个场景可以接受最终一致性？面试官在乎的不是方案多高级，而是你有没有在权衡。
按这个框架走，哪怕你和面试官的预期有差距，也能展现出“知道从哪下手”的工程思维。
4.3 一定要主动说出来的一句话：我的方案可能不完善，但我先讲思路
很多人在场景题里卡住，不是因为不会，而是因为太想给出“完美答案”导致迟迟不敢开口。我前两场面试就是这样，憋了两分钟没说话，场面极其尴尬。后来我学会了一个技巧——不管想没想完整，先把“我的理解是……”那个开头说出来，然后边想边补。
面试官其实很愿意听到你边说边修正思路的过程，这比沉默思考几分钟后给一个表面完整的答案要更让他放心。因为真实开发中，没人能在不沟通的情况下直接交付一个完美设计，沟通本身就是能力的一部分。
5. 反问环节与HR面：容易翻车的几个细节
技术面聊完，面试官一般会给我几分钟反问时间。第一次遇到这个环节时我只说了一句“没有问题”，后来被朋友点醒才知道，这句话等于拱手放弃了最后一次展示自己的机会。而HR面看起来随意，其实坑也不少。
5.1 反问环节怎么问才不踩雷
我后来的稳定句式分三类：问团队技术栈和业务方向，表现你对具体工作的兴趣；问团队当前挑战或规划，显得你思考过如何加入；问面试官个人感受，比如“您在团队里最有成就感的事是什么”，让对话自然起来。
要避免的问题也很简单：不要一上来就问加班时间和薪资范围，不是不能问，而是这个场合不合适，会显得你关注点只有回报。也别问那种网上能查到答案的问题，面试官会怀疑你做功课的能力。我自己最常用的是这句：“如果我有幸入职，前三个月您觉得我最应该提升的能力是什么？”——既能了解团队预期，又传达出自己愿意成长的信号。
5.2 HR面里的“期望薪资”怎么谈
这一步很多人特别紧张，生怕报高了直接出局，报低了又觉得自己亏。我的教训是：不要只报一个数字，要报一个有理有据的区间，并且把区间范围控制在合理的1.2-1.3倍以内。
说理由的时候，别只说“我觉得我值这个价”，而是把上一份薪资、行业普遍范围、以及自己跟岗位的匹配点讲出来。不管HR怎么压，都别急着当场做决定，说“我要考虑一下”不丢人，反而更容易谈出一个双方舒服的结果。
5.3 HR面最容易被低估的问题：“你遇到过的最大的困难是什么”
这是一个特别经典的行为面试题，但太多人把它答成了“项目的技术难点”。HR其实不关心你的Redis集群怎么高可用，她更想通过你的叙述，了解你遇到困难时的思维方式、情绪管理能力，以及解决问题的能力。
我准备这个问题的时候，用了“事实-行动-反思-改变”的结构：先讲清楚当时是什么境况，再讲我具体做了什么，接着讲事后我复盘出了什么，最后讲我现在做事方法和之前有什么不一样。这套结构帮我答了很多变体问题，比如“你最大的缺点是什么”“你跟上司意见不合会怎么办”，效果都很稳。
6. 面完当天的复盘清单：这个动作比继续刷题更重要
每次面完试，我回家的路上都会经历一个“无论结果如何都不想再看书”的疲惫期。但我强制自己当天就做一套复盘流程，因为这时候对整场面试的记忆还处于最清晰的状态，等到第二天就只剩零散印象了。
6.1 我用来记录面试过程的复盘模板
我给自己建了一个文档，每次面试后按固定格式记录：面试公司、岗位、面试轮次、被问到的所有问题、我的回答要点、答得不好的点、下次需要补的知识点。看起来是个笨功夫，但坚持三五场之后，你会非常清晰地看到自己的知识短板和表达弱点分布在哪些方向。
这张表最重要的一列是“答得不好的点”，因为我发现很多问题会在不同公司的面试里反复出现。第一次没答好是正常的，但如果同一类问题第二次还没答好，那就说明复盘没有真正闭环。
6.2 把“没答上来”变成“知识盲区清单”，而不是羞耻记录
有一场面试，我被问到“数据库的隔离级别分别解决什么问题”，我脑子里一团浆糊，只答上了“可重复读”，其他全乱了。晚上复盘的时候，我把“隔离级别”列进盲区清单，第二天直接用一篇博客和两个视频把这块补了一遍。
几周后再面另一家公司，完全一样的问题，我不仅把隔离级别列全了，还能顺带讲清楚MVCC的大致原理。那一刻我才理解，面试的价值不在于当场把所有问题都答对，而在于它精准暴露你还没掌握的内容。把每次“不会”都当成一次免费的知识体检，心态会好很多。
6.3 根据复盘结果调整接下来的投递策略
复盘还有一个作用，就是帮你判断自己目前的能力处在什么水平，应该投什么梯队的公司。比如我发现动态规划题每次都卡，那这个阶段硬投算法要求特别高的团队大概率陪跑，不如先把那些更看重工程能力和项目深度的岗位排前面。
我的策略是：把自己想去的公司按“梦司-匹配-练手”分成三档，每次面试顺序尽量从“练手”开始，等把自己暴露出的问题修掉一批之后，再集中面“匹配”档，最后把状态最好的时候留给最想去的梦司。这个顺序很多时候比盲目海投二十家更有效。
写到这里，“普通面经（中）”差不多也就该收尾了。没有惊天逆转，也没有一轮轮全家桶的宏大叙事，有的只是普通求职者在面试中途一次次摔倒再爬起来的过程。回头再看，面试这件事最磨人的不是某个知识点不会，而是在连续几次的受挫中保持稳定的心态。我个人的体会是：把每一场面试都当成一次信息收集，把答不上的问题当成免费的学习路径，状态反而会一天天变好。剩下的，就交给下一场去验证吧。