本来笔者将淘天春招的全流程安排在最后一篇文章中是因为打算最后接受这个 offer 的，但当钉钉-套件技术和淘天-淘宝买菜这两份 offer 摆在我面前后，哪怕我明确知道两者待遇有差，还是在深思熟虑和咨询老师后选择了钉钉。
但这不影响淘天作为笔者收到的第一个大厂 offer 可以得到最后书写的殊荣（多少有点倒反天罡了）。
简历面（电话面） 链接到标题
这是阿里系特有的一轮面试，在技术组觉得你简历有意思的时候会向你约这次面试，基本上都是八股文吟唱，加上一点简单的对项目和实习经验的了解，只是对简历上内容真实性的一轮考察，所以其实难度不大。
笔者在此之前连吃两厂的一面挂，所以面对这次是抱着破釜沉舟的心态准备的，狠狠的背了四天八股材料，内心给自己下了只许成功的死命令，最终也如愿过关，打破焦虑，重拾信心。
时隔一个月让笔者回忆这次面试的内容其实笔者脑中就只有很模糊的概念了，当然这和面试结束后笔者沉浸在成功的喜悦中没有及时记录也有关系。是的，笔者的每次面试都是结束后内心就有大致预判，且正确率 100%，因此笔者在前段时间跟学弟分享经验时提到自己的优点是清楚自己有几斤几两，会选择做自己能完成的事。
技术初面 链接到标题
本轮面试就是单纯的了解项目和实习了，比简历面聊的更深，在项目的架构、方案选择、最终效果这三个方面进行了深入了解，面试官还问了是否了解业界常用的解决方案、为什么最终还是选择了自己的这一套。
技术终面 链接到标题
这是一轮压力巨大的面试，面试官一开始给了一个场景题：
- 现有一个小商家，他只售卖两种商品，且销量有限，订单都存在文件之中，现在打算开发一个功能使商家可以查询到销量最高的三个省级行政区。
这题的解法其实很简单，把文件中的内容读到内存里，建立一个 行政区名称 映射 订单数量 的 map，统计结束后排序即可。
- 现在有一个大商家，还是售卖两种商品，销量巨大，订单还是存在文件中，现在的功能是需要查询销量最高的三个县级行政区。
这题是上一题的扩展，虽然笔者临场的回答差强人意，但复盘时还是想到了正解。
正解：流式读取订单文件，每次读取 100 条，按省级来将它们分配到不同的文件中，作为数据初始化。然后每个省级内依次建立一个 县级行政区名称 映射 订单数量 的 map，流式读取该省的订单文件，统计结果，将前三名保存到最终文件中，作为中期处理。最后只需要对最终文件进行排序即可。
本题是经典场景题大文件单词统计的一个变种，本质就是分治，大文件拆分，小文件处理，最终汇总。
- 引入数据库后第二题的场景应该怎样设计数据表，怎样设计 SQL 语句进行查询。
这就是一个送分题了，正解略。
结束场景题后面试官开始拷打框架，询问在框架使用过程中遇到的觉得它该有所改进的地方，还有框架的优势是什么，其实本质还是对框架源码与思想的掌握，也算是一种八股。
最后到了对项目的究极深入拷打，在这轮面试中我明白了高并发场景最重要的两个指标：qpt 和 rt。还被询问了是否考虑过 Redis 击穿这个问题，感受到了八股与项目的连接。
HR 面 链接到标题
这部分其实没啥好说的，就是聊聊成长的经历，影响最大的人，学习的方法，职业规划什么的。因为没有技术内容，其实对笔者来说就是很轻松的聊天。
总结 链接到标题
春招两个月下来，笔者对校招有了一个全面的了解，也整理出来了一套属于自己的面试内容，感慨万千啊，前大半个月的焦虑和自责，四天闭关的自我修炼，中间半个月逐渐找回自信，到后面大半个月的松弛，最终拿到了两个之前不敢想象的 offer，感谢一路上帮助笔者的各位，请等待笔者夏天转正成功的好消息。