途虎hr面

公务员其实就是稳定，规律的生活，工作内容相对固定，岗位变动啥的频率低。收入也很稳定，主要就是以 “基本工资 + 福利补贴” 为主，涨幅平缓但抗风险能力强，除了你主动离职或者犯错误了，基本不会出现失业什么的情况，大部分公务员一辈子顶多升到处级吧，甚至原地踏步，所以作为公务员基本就是一眼望到头的生活，这辈子做的工作生活基本就确定下来了。相反在大厂呢，工作内容随行业、公司需求动态调整，随时变化的。收入与个人能力、业绩直接挂钩，高薪机会多但波动大，行业下行或公司经营不善时，可能面临裁员、降薪这些风险。我记得张雪峰相关评价的一句话，大概意思就是你接受高薪资的同时，也要承担巨大的变动风险。在大部分公司里，...

1、自我介绍2、手撕：有n个数，随机排列成一个最大的数，输出一个字符串，例：[3,10,24,25]，输出："3252410"3、优化一个SQL语句：SELECT \* FROM ordersWHERE user_id=123AND status='PAID'ORDER BY create_time DESCLIMIT 10;表中字段：id, user_id, status, amount, create_time数据量：1亿条记录4、联合索引为什么按user_id、status、create_time这个顺序呢，你怎么知道数据库引擎就是按这个顺序去检索的呢，对数据库索引底层是如何做的有了解吗5、除了索引和select \*，还会有什么问题吗，你会怎么去解决呢6、你说到了根据user_id分表，那具体用什么策略去分表呢7、为什么选择user_id，而不用主键id，或者其他呢8、给了一段代码，用来在秒杀场景中进行减库存操作，一个stock表示库存量，一个减库存的方法，在单服务器部署场景下，代码会有什么问题吗（没加锁），怎么解决呢9、synchronized和ReentrantLock实现机制清楚吗10、下面考虑分布式部署的情况，只加上面的锁，会有什么问题吗11、那这里的取值操作需要加锁吗，还是说只有减库存需要加锁12、如果让你设计一个分布式锁，你会考虑哪些方面13、场景：设计一个类似微薄的点赞和取消点赞功能，需要设计一个api的接口实现这个功能，给出他的请求方法和URL，同时设计表，来存储点赞数据。主要实现三个业务功能：存储点赞信息，对这些信息做统计，让用户能看到自己的点赞14、如果需要考虑一些特殊场景，保证这个接口的安全，比如用户身份鉴权，恶意的流量攻击等待15、统计点赞数的逻辑如何实现，什么时候去统计比较合适16、反问聊天

1.A项目当时设计的时候，你有定一些目标吗？针对缓存，定一些目标2.核心的系统为什么会让你们这个实习生来做？3.为什么设计了这个四套缓存啊？4.缓存淘汰策略是什么呢？缓存淘汰策略5.你缓存的容量是多大呀？6.为什么设计这么大的缓存？7.怎么算出来这个，比如说缓存应该有多大呢？8.为啥预留这 30% 到 50% 啊？9.还有哪些点需要考虑的？这是一个上线到实际线上的一个缓存系统的话。10.还有哪些场景考虑11.数据一致性的问题，你们这个是具体是怎么做的？12.你觉得就能解决这个数据不一致的问题吗？13.你们这种设计对用户会有什么影响？14.如果说某一个时间或者某一个场景，你的这个缓存都失效了，会...

有点夸张了，50K😥