飞鱼科技内推-飞鱼科技内推码

给点经验 印象中的进度：6.14夜里投递 6.15中午电话沟通约面6.16面试（一个小时收到口头offer电话）6.20正式发offer 6.21入职 得物面经（其实没什么面经）因为得物岗位很多： 1.自我介绍的时候在在jd上贴合匹配度 2.表示出自信和想去的态度（因为毕竟现在实习生鸽公司的现象也很多，你在用你摇摆的态度去面试，其实mentor也会用这种态度对你） 3.对自己的简历要熟悉（因为确实会深挖一下） 投递Tips： 1.今年暑假真的很卷。可以适当降低自己的预期 2.投递一定要看哪家公司最近在招人！看最近，而不是看到什么岗位投什么。这样查看率会比较高（我感觉基本在***我的简历被查看的...

开始每日刷题的第二天：今天是第二天做Mysql题 之前上课的时候集中写过一段时间 后来搁置了 昨天是比较基础的题目 由于有事、上课也没写多少 今天写了快两个小时 有好几个题都只有20% - 30%的通过率 也相当于是复习一下 limit、round、inner join之类的关键词 希望自己能坚持下去

我看到好多人都在说0offer好焦虑，结果一看是投了百度快手字节啥的。好像大家都是只想通过校招进大厂，对小公司是不考虑的吗😂可是能进大厂的难道不是只有少部分人吗，真心发问

字节搜索二面挂当天被捞1、自我介绍2、你提到了用户的关注与取关，你用户关系服务是怎么设计的？（定义了关注表与粉丝表，两个表内容一致）3、你怎么保证两个表内容一致的？（目前是通过事务保证的，后面其实还可以通过订阅 binlog 伪从来保证一致性）3、如果是大 V 的情况，你有考虑到吗，做了哪些处理应对这种高并发（Redis 缓存+二级缓存，冷热数据分离）4、分布式 ID 你都用来生成什么 ID 的？（笔记 ID，用户 ID，用户 ID 用的号段模式，笔记 ID 考虑到雪花算法自带的时间戳可以实现冷热数据分离，发布久远的笔记不缓存在 redis，后由于点赞系统采用咆哮位图高效判断，但咆哮位图基本只能存储 32 位，遂也改为号段模式生成，生成效率基本没差多少）5、那你说说点赞系统怎么设计的？为什么改为咆哮位图了？（先是采用 Set 数据结构判断，后因为满足高并发需求，Set 模式占用内存太多，又改用布隆过滤器实现，大大降低内存占用。但布隆过滤器在判断存在时存在误判，需要从数据库进行二次校验。后改用咆哮位图，既能高效判断点赞与否，内存占用也大大降低）6、那你讲一下咆哮位图的机制，为什么有你说的这些优点？7、MySQL 了解吧，你讲一下 MySQL 的索引（一顿吟唱）8、说一下聚簇索引和非聚簇索引的区别9、联合索引再说一下，如何定义联合索引最好？（设计成覆盖索引）10、联合索引的顺序重要吗？（顺便再说一下索引下推）11、算法1：二叉树展开为链表12、算法2：根据层序遍历建树反问