安全岗面经第三波

在1.对于发布商品和交易的总数的时候，数据库的设计：因为对于发布者发布的总商品和交易的总数，这部分不仅仅只是涉及到用户表，同时也涉及到商品表，那么在我的二手闲置商城中，为了确保系统的性能以及可扩展性，不应该盲目尊崇数据库设计的范式，而是实现数据库表的yonyu字段，使其反范式化 那么分析一下，第一版我对于商品与用户的表设计时，考虑的是在商品与交易表中实时的通过count去计算我们的商品数，这样在用户界面时查看自己的交易与发布的商品的时候，能够实时的去计算和查看我们的发布的商品总数和交易总数，但是这样也带来了一系列问题，如，当我们用户不断的去发布商品和交易的时候，对于我们的数据库带来的性能压力是极大的，可以想象，当用户的商品积累至万级时，所损耗的性能了，每次访问都需要计算对于初期是可以的，但是并不优雅​那么我的第二版解决方案是什么呢？ 即在用户表中实现插入yonyu字段，将用户发布的商品使用计数器的形式去写入数据表中，这样，我们就可以通过查询用户的字段即可实现读取交易总数和发布商品的总数，但是会出现什么问题呢？每当用户发布一个商品或完成一笔交易，都需要更新 `users` 表中的这个计数字段。这会导致对用户表的高频写入，在高并发下容易产生行锁竞争，影响核心用户服务的性能。​但是对于我的这个小平台而言，这已经是比较好的一个设计方式了，对于业务增长没有怎么大的情况下，这可以应对1000-2000人的使用。但是，作为一个优雅的程序员，我已经在这部分埋点了，这部分后期我需要去实现第三版优化。具体的优化方式为：​在深入了解了EDA，RabbitMQ的底层原理，我可以确定的是，我们完全可以去是实现一种读写分离，并且考虑最终一致性的一个设计模式，对于微服务而言，我们并不需要去对商品，用户，订单服务进行额外的增加yonyu字段，而是可以去考虑在用户行为模块中，实现DDD架构中的聚合模式，想象一下，目前我的商品模块在发布商品的时候，已经实现了RabbitMQ的异步发布机制，当然，这部分的商品发布机制对应的只是个性化推荐系统的商品推荐，那么我能不能在用户行为模块中实现一种消费机制，实现用户的发布商品与交易商品的回显呢？当然可以，用户的行为模块是关于收藏，点赞发布评论，这些都是可以实现异步机制的，我们不需要实时的去显示，而是为了考虑最终一致性而设计的。

5.23 投递简历，随后发测评6.3 hr电话约一面6.4 一面。主要介绍了论文和项目，深挖了第二篇论文和项目，中间夹杂着考了一些八股（介绍metrics、介绍最熟悉的一种GNN等）。问对推荐系统有没有了解（回答不了解，鼠鼠是做图的呜呜呜）。然后面试官介绍了一下召回和排序，说召回目前也有图的场景。然后问了一道场景题，大致意思是排序需要很快的得到结果，如果用图有没有什么思路。最后手撕打家劫舍和打家劫舍2，秒了。一面面试官巨好，不得不感叹快手的面试真的做的好好，鼠鼠很菜但是至少不紧张。半小时后hr电话约了第二天二面。6.5 二面。这个面试官看着有点不苟言笑的样子，当时就开始紧张了。主要深挖了第一篇...

楼主bg：某c9ai专业大二在读，一段中小厂开发岗实习，参与了一段科研（是跟研究生做的，只负责了一部分模型的训练）这个暑假想找一段偏算法或者后端的大厂实习，但是首先自己并没有确定下来一个深挖的方向（比如nlp/cv/多模态等等），对这些领域都没有深入的了解所以也没法草率决定自己到底朝着哪个方向去努力，前期应该怎么样确定一个合适的方向呢[哭惹R]其次投了几个大厂，八股和一些笔试题也不会[哭惹R]感觉自己项目经历也相对比较薄弱，有没有合适的开源项目可以上手去做呢？[哭惹R]怎么样才能拿下大厂的实习呀TAT

前言：结合我自己的测开准备流程，和面试这几场实习后的经验，写一篇文章给想转测试开发岗位的同学一点入坑的指南吧。因为本人非科班出身，是临时转岗，面试的次数也不多，可能很多地方说的不全面不太对，有差错的地方，请各位大佬在评论区指正，大家一起讨论进步。从面试流程来看，我个人觉得测开主要准备的内容可以分为以下几个方面：项目、八股文、测开场景专题、力扣算法一、项目项目这个不用多说，作为研发岗，你的简历上的项目肯定要体现你自身的技术栈和专业性。但是这里可能有些同学会有疑问：1、项目多少个好？是不是我写的越多越好？找实习阶段，项目两三个足够。一个项目应该写上以下几个内容：项目名称、项目时间、你在这个项目负责...