看到这个图片的时候我真的笑了，资本真的是有一手，4块一天的暑假工去哪里找我要顺着网线去和他对线37度的嘴是怎么说出这么冰冷的话还很确定的说是4块一天捡几个垃圾都不止服了

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

1、项目介绍2、实习拷打3、go的map并发会有什么问题4、redis设计过程中会考虑哪些问题5、热key6、系统稳定性保障应该考虑哪些方面7、熔断、限流、降级8、分布式场景下的数据一致性问题8、本地消息表的实现形式9、工作中如何处理好沟通协作的问题10、日常怎么解决生活中遇到的压力问题11、反问

正式工作可能考虑稳定性和薪资更多一点，但是实习主要是为了积累经验和丰富简历。我认为title>业务>>>其他吧，有些同学可能觉得实习薪资也比较重要，但是对于实习来说，能做到不倒贴就已经很棒了还有就是业务，实习生可能接触不到什么核心内容，那就要看部门的面向用户，个人觉得toc>tob>内部