思特威 嵌入式Linux 笔试+一面8.17投递 岗位叫BSP工程师-SOC方向8.30笔试：一共九道题，有八股文简答题，有编程题和逻辑题。八股文包括：指针各种定义，进程线程，死锁，volatile；编程：冒泡，判断素数，指定位置翻转链表；逻辑题：经典的真话假话判断。后续，邮件通知笔试通过，进入面试，一面9.4：1. 自我介绍2. static关键字（存的地方搞错了，说了跟全局一样但是记不清了，有扯皮全局变量存在data、bss段）3. Linux用过吗4. 锁的应用5. 内存分配函数，kmalloc和vmalloc，地址连续吗（vmalloc大内存分配，虚拟地址连续，比较慢，同样不初始化）（...

鼠鼠我呀，究竟是怎样的结果，才配得上这一路的颠沛流离啊啊啊，原来是字节呀。从此化身节孝子，我的心只为你跳动

今天起因是11.1我投了深圳一个岗位，今天中午收到面试通知，我就和我一个舍友说，我之前秋招投递的时候也经常和同学分享投递情况结果他直接阴阳我是学人精。说他去投什么我就投什么。我昨天才知道他投了这个岗位，想和他说一下岗位情况什么的。唉，结果被骂一顿，我实在是不懂。鼠鼠我太委屈了

背景与闯祸实习期间承接需求时，我发现很多系统的业务逻辑盘根错节，上下文关联极深。有时需求本身涉及的代码改动明明很简单，可要是不把背后的业务脉络和代码逻辑摸透，就根本没法理解修改的初衷。最开始我接手需求，往往只盯着技术需求文档（TRD）里的修改要求，照着文档改完代码、做完自测，就觉得万事大吉了。到了代码评审环节，大家都要逐一讲解自己负责的需求和对应的代码改动。我负责的部分改动点很简单，无非是删几行冗余代码、调整一点参数配置，所以准备得很仓促，没多琢磨背后的逻辑。评审时，同事们针对这些修改提出了不少问题，比如 “为什么要删掉这段代码？会不会影响下游接口的调用？”“这里的参数调整有没有考虑到历史数据...