DeepSeek：工科硕士校招，央国企就业价值排序

各位大佬们，这两个offer该怎么选呢，主要是做软硬件设计，应该都有户口。985研究生1.中车科创6所，主要是负责给中车长客提供技术支持，相当于长客的北京研究分部，总包23左右，在海淀东升科技园，双休不加班。听说里面都是年轻人，氛围很不错。主要就是看现在中车行业整体在低谷期，高铁也建的差不多了，不知道后续整体的行业以及职业的发展是什么样的。但是毕竟也花了不少钱建了这么一个园区，应该也还不错。2.中核原子能院设计所，听说今年有个项目扩招，正好赶上了，应该去软件室。主要做的应该是为各部门提供一些信息技术支持，软件开发这些，总包大概在20左右，给所谓的事业编，地点在房山良乡大学城，相比原子能院其他所的位置要好不少，也基本是双休不加班。考虑到也是军工单位，现在也不是特别好做，民用的方向和其他研究所的竞争也不小。请问大家这两个工作该怎么抉择呢，从未来职业晋升发展，职位和行业的稳定性的角度来看看，如果大佬们如果有这两个单位的详细信息也可以分享分享，感谢#offer##offer帮选#

#春招进度记录# 👋个人背景：北方某双非本科☎️意向和oc：深圳派克斯pqe助理，美的佛山机械研发岗，深圳航空飞机维修，京东方设备(倒班太久已拒)👨‍💻面试：暂无进度📚笔试：中建(二测已过)，长安，东风，华为精密制造工艺(笔试都过了也没面试通知，可能已经进池)，中车，晟通📑简历：中天科技，和辉光电，北京现代，中铁，长虹，东航等等等有没有有没有大有没有大佬讲有没有大佬讲一讲有没有大佬讲一讲这些oc怎么样#机械制造投递记录# #机械人，秋招第一次笔试的企业是哪家？# #机械校招之路总结# #机械人与华为的爱恨情仇#

昨天oppo突然发了笔试(多媒体cpp岗，B卷)，刚刚做完1 0.67 0.325(好像是这个数字)第一题有点绷不住，第二题不知道哪里出错，没有全a，第三题总感觉答案不对，感觉题目写的是不是有点太简单了？有点模糊，不知道是不是我算错了(瘫倒)灵犀互娱我印象中笔试蛮简单的，我这种算法菜鸟都能a几道(印象中总共5道)网易互娱简直难晕我了，股票我只会做力扣上的那几道，多加了几股就不会了，2048只有0.909，说我数组越界😢，最后一个没印象了，好像很长很难

上来先手撕lru , si完 问优化 ● 1. 如何实现一个lockfree 的 并发控制的缓存  ○ 问ringbuffer的优点?  无锁并发 ● 2. lru结合lfu 实现兼顾折中, 结合优点的算法实现● 也可以使用结构体记录, 在数据存储 基本单元上● 面试官给的思路: 设计多个lruclass, 或者多个队列, hot, warm, cold 队列  ○ 访问频率高的就放入hot里边( 比如多少次以上评价为高  ○ 那么可以使用结构体, 记录每一个访问的次数  ○ 那如何解决这个过期呢? 还能设计一个过期时间, 每次要检索这个数据的时候, 获取这个过期时间,看是否过期, 过期就直接丢掉,  不能访问了 ● 另一个思路 :  整体还是按照lru来，替换之前检查一下，前三个即将被替换的里面选择频率最低的删除，但是每个最多连续比较三次（我瞎说的）  ○ 避免某些短时间频繁访问的节点被删除    ■ 防止抖动现象产生 布隆过滤器+ redis bitmap 的原理● 自己的思路, 使用一个散列函数, 根据你当前的访问频率(设计一个struct node ), 去决定你随机的在list里边的插入位置  ○ 如果频率比较高, 就将其在get 的时候放到靠近队头的位置  ○ 频率比较低, 将其get 的时候放在队尾的位置(反正你短期大量访问, 后续频率上来了也会 逐渐的放到队头的  ○ 并且反正插入和查询都是O1     ■ 如果是伪高频,  插入位置比较低, 后续也会直接被淘汰, 说明你根本不是真正的短期热数据● 如果再问频率优化?  ○ CMS, caffeine 的本地淘汰策略算法● lru和lfu 的区别, lfu适合短期高频, 而lfu适合长期高频 数据paxos和raft 的区别● paxos 对比raft 的优点?● raft 为啥容易实现? 和paxos对比? 不允许空洞->强leader->容易实现● 选主的时候有没有 可能设计一个方案, 无锁选主?   ○ 1. 回答哨兵机制, 交给另一个集群哨兵去做选举这件事( 从而让数据节点专心做数据  ○ 2. 问其他思路, 我说不锁不行, 不锁的话可能导致选票许诺给多个人->整个集群的逻辑总票数增加 -> 脑裂问题均摊分析, 插入1e数据 ,扩容因子为4的 hash插入 的复杂度( 不会● 两阶段提交的缺点   ○ 全局阻塞, io次数多( 根据mysql 的两阶段提交谈了谈, 三级队列优化思路  ○ 没有事先通知 参与者, 不知道他可不可达, 宕机没 就直接提交了( 浪费网络带宽  ○ 协调者比重太大,  一旦故障, 其他参与者也会跟着阻塞  ○ 可能导致的数据库不一致, 比如commit阶段 ,参与者并没有收到提交请求, 导致落后 ( 可以引入mq解决消息消费问题    ■ 回答 数据同步机制, 结合项目增量和全量, 以及mysql 的集群组提交策略(半数以上● 解决,引入tcc,  不过侵入性较大, 并且实际效率也不一定高 (