首页 / 暑期实习
#

暑期实习

#
7097768次浏览 93068人互动
此刻你想和大家分享什么
热门 最新
2024-03-21 10:58
企业号
实习还能这么薅?
置顶
02:57
汤君:oppo的颜值都挺高啊
点赞 评论 收藏
分享
05-05 15:58
已编辑
门头沟学院 Java
本科四段大厂实习,暑期五个offer,我的暑期结束了,秋招前集邮atmd、上海四毒
随着上午最后一个pdd的信息确认,我的暑期之旅结束了,投了20家,面了5家,拿了5家offer,分别是字节、淘天、美团、蚂蚁、拼多多,算上日常的offer,在秋招前就已经把阿里、腾讯、美团、字节、拼多多、小红书、得物的offer全集邮了,刚好是我们所谓的“atmd”、“上海四毒”(图2-图9)。暑期总共面了20场面试,挂了3场,另外拒面了6场,时间线见图1,基本上是3.7开始投递,最早的是3.25的美团oc,最晚的是5.5的pdd,期间一路长虹过,也挂过打复活赛一雪前耻,也有公司杳无音讯,我是带着三段大厂实习面暑期的,除去我拒面的几家,投了20家也只有5家约面了。所以我想告诉大家的是,没有约面很正常,运气、大环境这些因素也影响非常大,但同时,我又想告诉大家的是,大家没有面试就好好沉淀,不要懈怠气馁,沉淀技术到位,面试机会来了,就精确打击,一举成功,主打的是面试通过率,而不是靠面试场次去堆。就我个人而言,一直走的是精确打击的路线,面试通过率还算是比较高,日常面过5家,拿了4个offer,暑期面了5家,拿了5个offer,我的面试机会其实并不算多,但事实证明,offer是和你能力挂钩的,不和面试机会次数直接挂钩,技术没沉淀到位,给你0次面试机会和给你100次面试机会没有区别,所以希望大家不要焦虑面试机会少,而是要好好沉淀技术,争取一鸣惊人。学习方面,我推荐大家一定要有一段时间自己去深入学习+整理自己所学的所有技术栈,这样融会贯通后,面对同一个问题,你的回答就能和别人不一样,才能脱颖而出,因为现在大环境就是要这样,不这样没机会,选了这条路就得冲出这个大环境的包围。当然,如何深度学,这里面门道非常多,一时半会说不完,我以后有时间再跟大家扯扯。项目方面,我推荐大家不要把经典项目写简历,诚然,经典项目带给我们的成长很大, 比如黑马点评等等,我至今仍然觉得黑马点评是最好的Java入门项目,但是人人都黑马点评,人人都苍穹外卖,对HR和面试官而言,从简历上看,没有区分度,即使你有自己的理解,即使你对黑马点评改良了很多,有非常非常独特的自己的理解,但从简历而言,HR看到“点评”、“生活社区”等等字眼,已经懒得看你下面介绍,直接给你Pass了,所以项目无罪,但用的人多了,就有罪了。所以大家首先需要用的少的项目、其次需要对项目有自己的理解,我这里不推荐项目,我已经很久没关注市面上的项目了,因为实习远大于项目,有实习后项目已经可有可无了,但是因为我现在用的是一个自研的轮子项目,所以面试官让我挑一个介绍时,我仍然会吹我的项目而不是实习。但是大家有实习优先吹实习,其次是做个好项目。算法方面,熟刷hot100,至少刷三四遍,必须达到默写的程度,是必须!!!因为面试基本上就是从hot100出原题,是原题!等于事先就把题库告诉你了,熟刷hot100后,再随便刷刷其它题单,比如剑指offer等等,总题量刷个两百来题,就足够应对面试算法了,那么笔试算法呢?无所谓,能a出第一道签到题,就够了,因为笔试就是走个过场,只要不拿0分,给对面个台阶,最终还是看简历来筛选的,再说一遍,笔试就是走个过程,能a出一道签到题,第二题随便骗点分,就足够了,根本没有所谓的笔试挂,只有简历挂。至于那些什么场景题,我觉得本质其实就是灵活运用八股,一方面需要看你知识的广度,另一方面是看你能否把知识串起来,比如设计一个点赞系统,你需要把RPC、服务解耦、Redis、MySQL表设计、MQ、JUC、架构、集群等等知识全部串起来,这可能比较看重你的知识面的摄取,包括像是技术文章书籍的阅读等等。随便聊聊,不成体系,但我觉得能把我上面的话听进去的话,还是大有脾益的,每个人吸收的程度可能不同,后面有机会再把这些系统整理起来,出一期完整的路线讲解。
巨宇:优雅✌、詹姆斯·高斯林、约书亚·布洛克、道格·利亞,Java界四大天王!
点赞 评论 收藏
分享
03-29 19:44
已编辑
广东药科大学 后端
分库分表常见问题参考答案(收录25年至今的牛客面经)
分库分表的常用中间件有哪些?有哪些问题中间件无法提供帮助、只能改写业务代码的场景?使用了什么中间件?分库分表的实现场景和方式有哪些?分表之后,要查询两个表的数据要怎么查?分库分表的优缺点是什么?分库分表业界有哪些替代方案?(提示:分布式文件系统,因为分库分表会出现降低QPS,比如range查询失效)为什么做了分库分表后分页比较困难了?如果10亿数据要分表,要怎么分?业务怎么切?分库分表怎么保证数据一致性?选的什么分片键?什么分片算法?分库分表后的分布式ID怎么做?(2025年目前为止的牛客面经关于分库分表的问题收集)总结:分布式事务一致性问题跨节点关联查询JOIN问题(解决方案:1.全局表 2.冗余字段 3.建立1:1的ER实体关系分片)非分片键的查询问题(1.创建映射表 2.  前缀分片法  3.使用ES搜索引擎(最后才说要抬高立意)全局分布式ID问题(1.UUID 2.雪花算法 3.mysql/Redis 4.美团Leaf(1.Leaf-segment 2.Leaf-snowflake)跨库跨节点分页查询问题(不会)与朋友合作的开源Go KV项目路过可以的话帮我们点个star✨🌟https://github.com/FinnTew/FincasKV参考面试回答:(吟唱)<strong>面试官:分库分表后、如何解决跨节点JOIN查询问题</strong><span> <code><参考回答:></code></span>分库分表后、跨节点 JOIN 查询会带来性能问题。 为了解决这个问题主要有以下几种方案:1. 全局表: 如果是一些数据量小、变动不频繁的基础数据(比如权限表、配置表、商品分类表)可以将它们复制到每个数据库节点。 这样查询时可以直接在本地 JOIN、避免跨库。 但需要保证全局表的数据同步。2. 冗余字段: 如果经常需要 JOIN 某些字段、可以将这些字段冗余存储到需要查询的表中。 比如在订单表中冗余存储用户的姓名和地址。 这样查询订单信息时、就不用 JOIN 用户表了。 但需要保证冗余字段的数据一致性。3. ER 分片: 如果表之间存在很强的关联关系、比如订单表和订单详情表、可以按照相同的规则进行分片、保证它们在同一个数据库节点上。 这样就可以避免跨库 JOIN。(ER: 例如将订单表 和订单详情表按照 订单ID进行分片)使用一致性哈希算法、将 订单ID映射到不同的数据库节点上。关键: 保证具有相同 订单ID 的订单表记录和订单详情表记录、始终被分配到同一个数据库节点上。)<strong>面试官:非分片键的字段如何查询问题</strong><span> <code><参考回答:></code></span>问题背景:我们选择分片键的时候都是选用查询场景最多的字段来做分片键、但是可能需要查询非分片键下的所有所有数据。例如电商用(订单ID) 做分片但是我们可能会查询订单类型、这些数据可能被分到了不同的库、我们需要聚合所有库的查询、然后返回给前端。导致效率低下回答参考方案:<strong>1.关系映射表:映射关系表就是存储待查询字段和分片键映射关系的一张表、当要使用非分片键查询的时候、先到映射关系表中查询字段所对应的所有分片键、再根据分片键查询所有信息。</strong>(例如创建一个额外的映射表Map、包含 订单ID 和 订单类型 的对应关系。当插入新订单时、同时更新这个映射表。查询时先查映射表获取所有的 订单ID、再根据 订单ID列表查询分片表。总结一下就是用映射去查询我们就可以得到了 缺点是要维护新的Map 适用于对实时性要求不高的情况)<strong>2.  前缀分片法:利用(订单ID)的某些特征来决定数据存储在哪个分片上,并将这个嵌入到主键中。 这样既可以通过主键进行分片、又可以通过UID进行分片。</strong>(例如在生成 订单时,嵌入 用户ID 的某些特征 例如 用户ID的最后一位。然后使用包含这个 订单ID进行分片。这样既可以通过 订单分片,也可以通过 用户ID的特征进行路由。优点不需要额外的存储空间 缺点是可能会产生如果 用户ID分布不均匀、可能会导致数据倾斜)<strong>3.ES: 将所有订单数据同步到ES中、利用 ES 的全文检索和聚合分析能力、进行多条件查询</strong><strong>面试官:分库分表后的分布式ID怎么做?</strong><span> <code><参考回答:></code></span>问题背景:分库分表后需要一个唯一ID来标识一条数据或消息。回答参考方案:说一下各大方案及优缺点就行。1. UUID(优点本地生成、缺点是16字节128位存储成本高以及会产生页分裂问题2.雪花算法(优点生成性能高、可以根据业务特征分配Bit位、缺点是依赖强时间回钟)3.MySQL自增主键和Redis的Incr命令(不做探讨)3. 分布式ID生成服务、如美团的leaf算法(Leaf-segment和Leaf-snowflake)大家这里可以去看美团技术文章 这里引导一下思路就好<strong>面试官:如果要你选择一个分布式ID生成方案你会选什么</strong><span> <code><参考回答:></code></span>1.如果 对 ID 的有序性有要求、且需要高性能的 ID 生成服务、我会优先选择雪花或者 Leaf-snowflake 。 雪花的优点是生成速度快、ID 趋势递增、有利于数据库索引的性能优化。Leaf-snowflake 在雪花的基础上、对时钟回拨问题进行了优化2.如果 对 ID 的有序性没有要求、且可以容忍一定的存储空间浪费、我会选择 UUID。 优点是本地生成、不需要依赖外部服务、生成速度快。3.如果 业务规模较大、对 ID 的全局唯一性、高性能和可扩展性有较高要求、我会选择构建一个专门的分布式 ID 生成服、例如使用 Leaf-segment 算法。 的优点是统一管理、方便维护和扩展、可以根据业务需求定制 ID 生成规则。更新一下CSDN: https://blog.csdn.net/wy990880?type=blog大家copy内容背诵就好了在我看来这个就是点到为止说出自己能知道多少就说多少 不要一点不知道 说多少都是缘分而且我觉得面试官自己也没做过分库分表具体的技术深度大家看看别的
huangyong:分库分表总结得很全面
点赞 评论 收藏
分享
玩命加载中
牛客网
牛客网在线编程
牛客网题解
牛客企业服务