仍旧零面试，记录一下暑期实习投递进度

我想和大家分享一下我大三暑假找第一份实习的经历。虽然现在回过头来看有些仓促，但也正是这段经历让我真正踏入了职场，积累了非常宝贵的经验。全国可飞，哪里有机会就去哪里我当时的策略很简单粗暴：不挑城市，不看公司大小，只要岗位名称对口、要求不离谱，我就一律投。实话说，那时候没有什么清晰的职业规划，也没意识到实习的重要性，只觉得应该早点接触一下真实工作环境。很多简历投出后石沉大海，有的 HR 打来电话时我还一时想不起来自己投了他们公司。但就是在这种“撒网式投递”中，我收到了几个面试机会。最终入职的是一家在上海的公司最终让我下决定的是一家位于上海的公司，做的是我还算感兴趣的方向，关键是实习工资在当时看来挺...

一面 一面没什么好说的，在面试前半个小时会给你三道题，很好做，基本都是牛客中等难度。正是面试自我介绍等等，题目记不清了，基本就是数据库，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分，主要是语文不太好，概括了两次才过....

面试官先问我数学建模竞赛做了什么，使用了什么方法，面了这么多第一次遇到问竞赛的然后就是一些常规八股，问了我项目中遇到的最大的困难还问我java和python的区别，各有什么优缺点，说是他们部门主要写python，也有java另外还是两个面试官面的，一共面了半个小时，面完后马上发二面了

字节突然主动来找我发面试，完全没准备好，经过交流，面试安排到下周四。但是由于之前都在备战考研，没投过实习，这是我第一次面试🙊八股还没背，力扣hot100也没刷完，这一周不知道来不来得及补过。想问问我这种简历一般都会问啥问题啊😦项目都是自己做的，保真，但是实现上有很多润色的地方，有没有佬帮看看哪些地方容易被拷打，我去恶补下。求简历建议，不玻璃心，请佬狠狠喷🙃