无手撕，毫无疑问kpi面，我估计没hc，项目什么都没怎么问，光速解决1.实习经历，项目经历，以及项目亮点2.项目里的缓存策略删除，比如有一个步骤失败了怎么解决3.MVCC4.Bean创建过程5.springMVC反问

突然就收到了库洛的oc，很快的谈薪，很快的逼签，好像自己的去向突然就决定了，确实是自己很喜欢的方向，但当突然做决定的时候还是患得患失的。无法评判，选择无关绝对的好坏，只是在不同赛道里，偏向了更贴合自己的那一个。滴滴美团固然是不错的选择，但二次元领域的适配感，是自己更看重的。毕竟谁也没法预判未来，与其顾虑三五年后可能在互联网面对枯燥业务、深夜加班时的遗憾，不如遵从当下的心意——至少这份对领域的喜欢，是此刻最确定的东西。这种患得患失大概就是成长里的选择题后遗症吧。毕竟没有哪条路能提前看到终点，本就没有标准答案。但反过来想，能在年轻的时候选择一份“提起就会眼睛发亮”的工作，已经比很多在迷茫中打转的人幸运多了。就算以后真的会有遗憾，至少此刻的热情是真的，为热爱拼一次的勇气，也绝不会是白费的。最后祝大家都能签到理想的工作，爽拿offer！

阿里hr面真的给我面一身汗

背景与闯祸实习期间承接需求时，我发现很多系统的业务逻辑盘根错节，上下文关联极深。有时需求本身涉及的代码改动明明很简单，可要是不把背后的业务脉络和代码逻辑摸透，就根本没法理解修改的初衷。最开始我接手需求，往往只盯着技术需求文档（TRD）里的修改要求，照着文档改完代码、做完自测，就觉得万事大吉了。到了代码评审环节，大家都要逐一讲解自己负责的需求和对应的代码改动。我负责的部分改动点很简单，无非是删几行冗余代码、调整一点参数配置，所以准备得很仓促，没多琢磨背后的逻辑。评审时，同事们针对这些修改提出了不少问题，比如 “为什么要删掉这段代码？会不会影响下游接口的调用？”“这里的参数调整有没有考虑到历史数据...