以前觉得风评不好只是个别现象，没想到真是这样，两轮面试，还有线下面试，大老远跑去，后来说面试过了，谈好薪资，定好入职日期，结果前一天，告诉我，领导最后审核offer没通过，真的是醉了。太坑人了，之前有个offer给拒了，现在告诉我这个也凉了，真是无敌了，这家公司。

这个它石是真的恶心，一天就给我结束了。看了一下JD，估计就是卡学历，非要985/211吐了。。。。

差点把线上搞崩那次，到现在想起来手心还会出汗。实习第六周，我改了一个配置参数。自测过了，跑了几个case没问题，心想这么小的改动走什么灰度啊，直接上呗。提交MR的时候mentor拦住了我，说走灰度。我当时内心是翻白眼的——至于吗？灰度放了1%的量，五分钟之后监控开始报警。我改的那个阈值，影响了下游一个缓存服务的淘汰策略。我看着监控面板上那条飞起来的红线，感觉自己的血也凉了。mentor倒是很淡定，一键回滚，然后跟我说：这个接口日调用量几千万。如果刚才全量上了，你今天就可以体验什么叫P0事故复盘了。那一刻我是真的怕了。不是怕被骂，是怕影响真实的用户。之前在小厂实习，出了bug重启一下就好了，DAU才几千，没人在意。但大厂不一样，你敲的每一行代码背后都是真实的人在用。从那以后我再也没有跳过任何一个流程。你说大厂的流程烦不烦？烦。但被流程保护过一次之后，你会真心感激这份烦。感谢我师，就我🐶命

Nginx 是七层代理还是四层代理？你用过 LVS 吗？你的后端跑了两个 Tomcat 服务，在分布式架构下，Session 的会话保持（一致性）是怎么做的？什么是缓存穿透？简单讲一下你的项目中是如何用布隆过滤器解决缓存穿透问题的？场景设计题：如何设计一个海量日志采集系统（要求：日志尽量不丢、中间需拦截并添加流量/用户特征等处理、未来支持动态扩容）？谈谈你的技术架构设计思考。在业务代码中通过 AOP 记录完日志后，具体该如何将这些日志传输并提交到那个独立的日志服务上？如果该日志系统要求对接全集团的服务，日志量极大且 QPS 极高，应该如何设计高吞吐架构？如果在日志系统引入 Redis 缓存“热...