山西晋中某小厂

最近刚刚换了工作，但是我工作年限真的很短很短，和新的mt去吃饭的时候，她跟我讲了一些她的意见，对于我来说是非常有用的，我来分享给大家，针对工作的年限如果自身不够硬的话就要在一个阶段足够的淬炼自己，方可进化成为职场no.1一个人的事业发展一般可以分几个阶段：第一阶段： 干活小弟（1-3年）干活小弟主要承接老板交代的工作，工作不需要承担太多责任，为老板打杂打下手，没有什么话语权，是学习技能的阶段第二阶段：大头兵（3-5年）这个时候你从一个执行小弟，变成一个可以独当一面的骨干专家。可以从执行者变成一个决策者，自己承担项目的闭环，需要拥有一些全局观和推动力。第三阶段：小组长（4-8年）从一个个人贡献者...

一面一面没什么好说的，在面试前半个小时会给你三道题，很好做，基本都是牛客中等难度。正是面试自我介绍等等，题目记不清了，基本就是数据库，Go的基础，还有一些架构方向的知识，比如分布式什么的，基本上基础知识扎实就能过二面二面开始上强度了，HR人很好，和我说二面会有场景题，上来就场景题，难度非常大，而且很开放1.问：假如某某模块的api访问耗时突然上涨，你应该如何排查答：从系统架构出发，排查调用路径上可能存在的每个服务节点的耗时情况，定位到关键节点后通过time计时器查看高耗时位置代码，再逐一排查问题情况面：可以但不对，应当要保证客户的api调用时长不能再恶化，你应该避免使用可能会增加调用耗时的方式deepseek:立即验证问题并检查现有监控（非侵入性，耗时接近0）· 为什么做：确认问题是否真实，并快速定位大致方向（如资源瓶颈或错误激增），避免误判。· 操作步骤：    · 访问已有的监控系统（如Prometheus、Grafana、CloudWatch、APM工具如New Relic或ELK），查看API响应时间的趋势图。重点关注异常点发生的时间段。    · 检查关键资源指标：CPU使用率、内存占用、磁盘I/O、网络延迟。如果资源利用率突然饱和（如CPU峰值或内存OOM），可能指向代码问题或外部依赖。    · 查看错误率和请求量：API 4xx/5xx错误是否增加？如果有高错误率，可能上游服务故障或传入参数问题导致重试和延迟。· 保证不增加耗时：监控数据通常是预聚合和缓存的，查询操作是只读且轻量，对系统性能影响可忽略。2.分析现有日志（低风险，耗时微增但可控）· 为什么做：日志中可能记录慢查询、异常堆栈或超时信息，帮助定位具体模块。· 操作步骤：    · 使用日志查询工具（如Kibana、Splunk或grep命令）搜索模块的访问日志，过滤耗时超过阈值（如 >500ms）的请求。关键词：slow request、timeout或错误码。    · 聚焦时间范围：匹配监控中的异常时段，分析请求路径、参数和响应状态。    · 检查依赖日志：如果模块依赖数据库或缓存（如MySQL慢查询日志、Redis监控），查询这些日志看是否有超时或锁争用。· 保证不增加耗时：    · 使用日志采样（如只查询1%的请求）减少开销，如果系统支持，直接读取已缓存的日志索引。    · 避免启用debug级别日志或添加新日志输出，以免增加I/O压力。3.检查外部依赖和第三方服务（只读查询）· 为什么做：API耗时上涨常由下游服务（如数据库、缓存、RPC调用）变慢引起，排查时应优先排除外部因素。· 操作步骤：    · 查询依赖监控：检查数据库（如MySQL SHOW PROCESSLIST，但避免在高峰期运行）、缓存（如Redis INFO命令）或外部API（如第三方服务状态页）的性能指标。关注响应时间、连接池使用率和错误率。    · 网络诊断：使用ping或traceroute（但需谨慎）到依赖服务端点，检测延迟或丢包。优先依赖网络监控工具（如Cloud Provider VPC流日志）的数据，避免主动探测生产环境。    · 关键问题源：数据库慢查询（如缺少索引）、缓存击穿或限流、第三方服务降级。· 保证不增加耗时：所有命令基于只读查询（如SHOW PROCESSLIST非阻塞），或在备机执行。若需网络探测，使用监控历史数据而非实时工具。4.审查近期变更（无需运行时代码修改）· 为什么做：50%的故障由部署或配置变更引起。排查时检查变更记录，而非直接回滚（回滚可能增加风险）。· 操作步骤：    · 检查发布系统（如GitLab、Jenkins）的部署记录：是否有新版本、配置更新（如超时时间调整）或功能开关启用？重点关注变更时间和API耗时上涨的相关性。    · 对比环境：如果有预发布环境，验证相同请求是否耗时正常，但不在生产复制测试。    · 依赖变更：外部服务或SDK版本升级是否发生？· 保证不增加耗时：操作仅涉及元数据查询，不影响运行时性能。5.临时控制影响（预防恶化，但不直接减少耗时）· 虽然排查时不修复问题，但可采取措施防止耗时进一步上升：    · 限流降级：如果API网关支持（如Nginx、Spring Cloud Gateway），调整现有限流规则（如降低QPS阈值），但避免新增规则导致额外计算。    · 流量采样：在负载均衡层（如HAProxy）启用请求采样，减少低优先级请求的影响。    · 回滚决策：如果变更审查指向特定部署，考虑在低峰期回滚，但回滚操作本身可能短暂增加负载，需评估风险。6.关键原则和注意事项· 不增加耗时的核心策略：    · 只读优先：所有操作只查询现有数据（监控、日志、配置），不写入或修改系统。    · 避免高开销工具：禁用profiler（如Java Flight Recorder）、调试器或tracing工具（如Jaeger），它们可能增加CPU开销。    · 资源约束：在容器化环境（如K8s），查询日志和监控不消耗额外资源；物理机避免运行top或vmstat，而是看历史数据。    · 团队协作：优先询问SRE或监控团队获取数据，减少直接登录服务器。· 如果问题根源不明：收集必要信息后（如日志片段和监控截图），在测试环境复现问题，避免在生产深入诊断。· 后续修复：定位原因后（如数据库索引缺失），修复应在低峰期进行，并添加监控告警以防复发。2.面：假如现在有类似抢购之类的情况发生，怎样保证系统稳定性（这个网上答案很多，去找一下看吧，关键在于我只考虑了数据库的使用和配置，不够全面，面试官强调了还可以使用服务器的内存结构提供多级缓冲）3.这里记不太清了，大概是如果系统出现宕机之类的情况怎么办，我的回答是通过htop，日志查询定位时间等方式解决，面试觉得还可以HRD面一般来说不用写这个的，但是这家公司的HRD面比较难，HR和我说通过率大概在20%左右，主要考查你对他们公司业务的掌握情况，性格和学习热情等，所以大家要注意一下，多问问HR关于这方面可能会考察的知识，最好去他们官网，看一下他们业务的api手册（里面有这个api需要的参数），还有一些不常见业务的理解、面试方式是做题，会给你三道业务题，让你口述或者直接写，会有语文的概括信息题，异常数值的敏感性，常见业务的理解等，最后HR给的review大概是拿了70-80分，主要是语文不太好，概括了两次才过....

（在本帖评论+点赞+关注的小伙伴，今日可得好运相随，会有好事发生，不信试试看～） 🔥 知路后台管理 - 通过 AI 驱动的新一代前后端脚手架 知路是一个原生集成 AI 并通过 AI 驱动的重新构思、重新设计、重新开发的 Vue3.5 Java21 前后端脚手架。 本项目特点简略说明如下（下面有详细说明）  国内首个原生集成 AI，并通过 AI 驱动的后台管理 原生集成 Docker 只需一台装了操作系统的电脑即可部署（不装 java，不装 js，不装数据库） 高质量的代码 正确的业务建模  项目演示地址（请大家爱护公共数据喔） https://github.com/ccmjga/zhilu-...

头一次见到要求毕业于某个学校的