第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...

现在27届还没实习的我是不是废了

😢 飞书电话会议。我真的搞不懂，那些问题我基本上都回答出来了，咋回事呢。

一面，有点偏综合面吧。首先自我介绍。问项目，介绍一下项目，项目几个人参与了，你负责什么模块。项目中有没有遇到过很紧急的状况？怎么解决的？主要的编程语言。八股进程和线程的区别以及通信方式，进程和线程如何解决并发。网络通讯当中，了解哪些通讯方式。知道哪些调试的方法？平时用哪些？运行期有没有遇到过问题，怎么定位问题的原因和位置？（这方面问的比较细，我答得一般般，说的不太好）有没有遇到过内存泄漏的问题，有什么定位的方法。（这里答得也不太好，说只会看代码，工具不会用）了解的锁。问一些场景题。项目开发的过程中，有没有遇到过问题，怎么解决的？对自己未来的规划？反问。感觉不是一般的技术面，更多的是一些处理问题...