有一次嵌入式面试，面试官没有问太多八股文，直接给了一道现场手撕题。背景是设备需要统计状态寄存器中异常位的数量，本质就是统计一个 32 位寄存器里有多少个 bit 为 1。题目不难，但面试官强调两点：这是跑在单片机上的代码，效率要高，不能浪费算力。如果只会一位一位右移去数，很容易被追问有没有更优解。这道题考的不是能不能写出来，而是你平时有没有真正写过底层代码，是否对位运算和性能敏感。写完代码后，面试官还会继续追问在中断里用、在低功耗场景下用，有没有需要注意的地方。这种题目，很贴近真实嵌入式开发，也最容易拉开水平差距。

面试战绩： 字节 二面挂美团 一面挂携程 池子已一个月 大概率泡死wps 二面挂深信服 预二面其实还有几家给了面试机会但是眼高手低推掉了😭真的很后悔其余的全笔试挂了我笔试真真真真真的好烂啊，平常没积累实习结束的晚投递得晚没太多时间准备😭，导致根本没有几次面试机会，很多实际场景和项目拷打接的也不是很好只能看后续如果有面试机会再加把劲，多练算法准备春招不要重蹈覆辙了

秋招圆满结束啦，成功以本科学历进入字节算法岗。你可以永远相信ACM竞赛的力量！upd：投简历的时候只有银牌，金牌是投简历后才拿到的。

三、核心技术场景考察及候选人表现（一）考察场景高并发秒杀场景：1 万人同时抢购 100 个库存的商品，要求保证用户体验、系统稳定性与扩展性（二）候选人方案及面试官质疑候选人核心方案：前端先获取 token（通过 Lua 脚本实现锁机制），再凭 token 下单；后续考虑通过 MQ 异步处理、库存分片等方式优化面试官核心质疑点超卖与少卖风险：Lua 脚本仅解决锁竞争问题，下单环节的复杂逻辑（风控等）可能导致下单失败，已分发 token 会造成少卖；锁机制无法完全避免超卖系统扩展性不足：面对 1000 万人抢 1 万个商品的场景，数据库难以承载高并发读写，token 机制与数据库扛压能力不匹配异步...