安克hr面

很多后端的日志要么全是info，要么全是debug，出事了根本筛不出重点。本地调试用debug，关键状态变化用info，异常用error，但还有一个很少人用的——trace，专门用来打印“请求入口和出口”的耗时和参数。这样线上出问题时，我可以只grep trace，三秒钟定位到是哪个环节慢了。

1、基本情况：是否在学校、家乡、目标城市2、学业安排：课程情况、能否离校实习、是否与学院/导员沟通3、自我介绍：个人情况、技术、项目、竞赛介绍4、学习背景：Java学习途径、投入时间、开始时间、为何选Java5、岗位认知：是否了解岗位工作内容、业务方向6、工作接受度：对开发30%-50%+实施/测试/运维/需求分析的看法7、技能掌握：前端（Vue等）了解程度8、在校情况：成绩、挂科、四六级9、行业认知：如何看IT行业节奏与强度、能接受怎样的加班10、性别观点：如何看女生做开发的优劣势11、职业规划：3-5年规划，坚持开发还是转管理/产品12、到岗与稳定性：一周内到岗？实习6个月以上？13、设备...

主要是不想花钱，kimi用来给我做项目规划，策划很好用，能把方案都分条列举出来，最后可以一句话总结。trae就更不用说了，自动解析项目，修改项目也很方便。缺点就是有时大脑会短路，导致代码需要重新审查。

第一次被拉进技术评审会时，我以为自己只是去旁听。结果会开到一半，大家盯着一段异常波动的调用链，讨论一个老问题: 流量上来以后，某个核心模块偶发超时，重试一多，后面的服务压力也跟着抬起来。 当时没有谁直接把答案告诉我。导师只说了一句：“你先别急着改代码，先判断问题到底出在哪一层。”这句话我记了很久。因为真正有挑战的技术工作，第一步往往不是写，而是判断。 接下来几天，我补链路、看日志、对照监控，把请求路径一点点拆开。最开始我也怀疑过是不是单点性能问题，但越看越发现，问题没那么简单。它不是某一行代码突然变慢，而是高并发下，上下游配合方式开始变得脆弱：重试策略叠加、依赖调用放大、部分节点抖动后缺少足够...