求职经验分享（9）：已经实习了，要注意什么？（一）

绝命Coding

已于 2024-06-18 11:15:47 修改

阅读量1k

点赞数 41

分类专栏：就业经验分享文章标签：经验分享后端职场和发展面试

于 2024-06-16 10:56:12 首次发布

本文链接：https://blog.csdn.net/qq_33445788/article/details/139716921

版权

就业经验分享专栏收录该内容

14 篇文章 0 订阅

订阅专栏

从三月初至今，许多公司开启了实习生招聘工作，但是不少第一次实习的同学有着各种各样的疑问，

同学甲：“目前在小厂实习，工作内容只有CRUD怎么办？要跑路吗？”

同学乙：“目前在小厂实习，工作内容非常繁杂琐碎，觉得没有含金量怎么办？”

同学丙：“目前在大厂实习，工作内容只有CRUD怎么办？”

同学丁：“目前在大厂实习，实习期间做的内容太难了，感觉自己能力跟不上怎么办？”

其实上面的几个问题非常具有代表性，不过在回答这些问题之前，老白需要说明一下，大厂和非大厂的实习同学遇到这种问题的解决办法是不一样的，主要原因还是大厂的技术积累比较深厚（包括技术文档、同事水平等），所以后面会围绕是不是大厂实习进行具体的情况分析~

接下来老白针对这几个问题的共性，和大家分享一些个人的看法和建议，为了防止太抽象，主要都是基于理论+举例子，本篇内容非常值得即将实习或正在实习中的同学三连~（在看+点赞+收藏）

问题一：实习期间做的内容太简单，只有增删改查（CRUD）怎么办？

这个问题首先要按照时间点来说，如果是实习入职第一个月，无论是不是大厂，实习生熟悉了解项目的应该都是从简单的模块做起，比如某个模块的查询接口等等，但如果实习两三个月都一直是重复的CRUD的工作，这时候就需要注意了。

对于大厂同学来说：

如果做了一个月CRUD后还没有做其他的内容，第二个月开始应该有意识的主动询问导师或主管是否有复杂一些的业务或者技术的需求；

如果仍然只能分配到一些比较简单的需求，那么就启动我们的大厂最终方案：

1.看懂同事做的就是自己做的！2.看公司的技术文档（如中间件设计、**问题的解决方案）

听起来很简单，但是这也需要很多技巧，里面的细节很多！下面详细分析一下，都是干货~

1.看懂同事做的就是自己做的

看同事代码，始终牢记一点，这是基于怎样的业务场景去解决怎样的问题？为了解决这个问题用了什么技术？之前是否做过优化？有没有设计模式的良好实践？

然后去看需求的评审文档，看看有没有系统的架构设计、概要设计、详细设计等等，对着业务场景去思考如果自己来写这个需求要如何做？然后再去看同事如何设计方案的。

接下来是非常重点的内容！要将自己想象成面试官，问自己几个问题：这个需求的技术难点是什么？解决***问题，你为什么要这样做？还有优化的方案吗？要知道，即使是同事写的代码，也不一定是最优的方案，这些问题都要学会去思考！

说起来还是比较抽象，举两个简单的例子：

例①：假设同事的功能涉及到多张数据库表的插入操作，比如数据表A的status字段，从状态1变为状态2，然后需要我们同步去更新数据表B的type字段，从true变为false，这时就会涉及到事务的内容。

以Spring的事务为例，那么面试官可能就会问数据库事务和Spring事务的八股文，再深入点就会问事务加在什么位置对性能更好，使用@Transactional注解？使用事务模板？类上？方法上？

例②：假设同事的功能涉及到上下游的交互，即同事负责上游的A业务，A业务会通过消息队列去通知B业务进行某些操作，这种时候很明显就涉及到消息队列的内容，比如如何保证消息可靠？如何保证A业务请求B业务时候的幂等性？如果发生消息堆积你会怎么做？

2.看公司的技术文档

技术文档通常分了两种，一种是框架/中间件的设计文档，一种是部门或小组的技术文档，设计文档也可以结合市面上的开源的框架/中间件的博客文章一起看。

这里老白主要讲讲后者，首先大家一定要了解上下游和系统全链路这个概念，我们看看简单的定义：

假设我们的小组负责A业务，另一个小组负责B业务，还有小组负责C业务，可能就会存在A是B的上游，B是C的上游，即B业务很多编码是为A业务服务的，C业务则是为B服务。这种时候站在面试官的角度，就会考察候选人是否对自己实习的内容有一个整体的宏观理解，即全链路的考察。

模拟几个面试问题，比如：

A业务是如何去调用B业务的内容的，RPC还是HTTP？
你是否了解B业务是怎么做的呢？如果让你来设计B的那个功能模块，你会怎么做？

如果我们事先对全链路研究过，回答出不错的方案，相信一定能给面试官一个不错的印象！

即使我们不负责B和C业务，没有写过或看过里面的代码，但是同一个部门的不同组，都会有技术设计文档，这就为我们去了解系统全链路提供很大的便利，里面的技术内容和设计就不只是简单的CRUD了，如果感兴趣自然可以深入了解，提高自己的技术理解。

这里还可以扩展到很经典的八股文：用户（客户端）发起请求，你们的浏览器（公司的系统服务端）是如何处理的？假如我们对系统的全链路不熟悉，这里显然无法结合八股回答好这个问题。

大厂技术文档建议观看学习并写进简历的内容：

小组线上bug的问题与排查思路
sql优化或其他性能优化相关的处理
项目架构的设计或重构方案

对于非大厂同学来说：

上面大厂同学的很多内容其实也适用于非大厂的同学，如果技术文档不错，就参考上面大厂实习的方式。

当然如果公司的技术文档不好，框架用的也是开源框架，而不像大厂自研框架，遇到这种情况咱们也别怕，我们同样启动我们的非大厂最终方案：

1.看懂同事做的就是自己做的！2.尽量吃透项目 3.利用空余时间看开源框架的技术设计

下面详细分析一下，都是干货~

1.看懂同事做的就是自己做的

参考大厂的最终方案~

2.尽量吃透项目

如果公司项目比较小型，那就把公司整个项目的运行流程了解清楚，包括业务需求等等；如果公司项目也比较大，那么我们也需要了解清楚上下游和全链路（参考大厂的最终方案~）

3.利用空余时间看开源框架的技术设计

如果公司技术文档很少很乱，那么这个时候最好的方式就是查看开源的技术文档，通常网上会有很多博客解析。

举个例子：如果公司采用RocketMQ，那么我们就需要去了解项目哪部分用到了它，首先去了解清楚RocketMQ的用法，其次再去了解对应的设计原理。很多时候大厂的自研框架其实都是基于开源的框架做一层封装或解决某些不好用的bug，所以会存在很大的相通性，因此学习开源框架的设计可以等价于在大厂看自研框架的设计。